flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cortlandt Winters <c...@cortwinters.net>
Subject Re: Flex Portal considerations
Date Thu, 26 Jan 2012 17:18:44 GMT
I think there are two different use cases here

I think there is a common use case where you have a flexible ui that needs
to save the positions of hdividedbox and vdividedbox positions and the
column widths of datagrids,  stuff like that, so that users can customize a
flexible view to their tastes or screen size and have it stay that way per
machine. You access the app on your netbook and you get one layout, you
access the app from your desktop, you get another, even though your data is
the same on both.

In this case you're staving state that is important, but not so important
that you want to save it in a database and which is dependent on the client
anyway. 100kb is a lot of space for stuff like that and for pure flex apps
it would be good to just have a localpersistent metadata tag that you can
apply to properties of a component and have it be managed with a global
manager to deal with size limitations and to make it easier to manage and
less error prone. I think that something like that make a lot of sense for
the framework to handle and would be pretty easy to do.

I think the core problem Nick is dealing with is much different, since
what's really creating the problem is the page refreshes that are forcing
the components to reload the actual data as well as any semi-ephemeral view
state information. In this case I think it's the portal frameworks
responsibility to reduce the page refreshes by, say, hiding and showing the
elements that house the flex components rather than refreshing that part of
the page.

And yet after doing the first part, it obviously wouldn't be difficult to
also allow the components to cache their actual data providers as well and
to compress them, as a second, though less frequently used option, and one
that might eventually force folk to bump up their local shared object store
for a large app like Nicks. This would also enable offline use of apps and
potentially even the saving of changes when offline to make when the user
comes online again. Once again it would be easy to do and in this case it
might be too easy to do, because it might get overused, but by implementing
this it would even make the development of serverless apps very easy and
radically reduce bandwidth use in cases like Nicks, though I don't see any
way around bumping up the local shared object storage long term, unless
everything is going to be saved and maintained at the server level.

On Thu, Jan 26, 2012 at 7:23 AM, Nick Collins <ndcollins@gmail.com> wrote:

> In that case you are talking about AIR, though, which is a different beast
> from the Flash Player in terms of sandbox limitations. Within the browser
> player you have limitations on how much data you can store in a shared
> object before it prompts the user ( if I recall correctly it is 100kb) to
> ask if it can use more. The ideal user experience would be that it happens
> completely transparently to the user. In essence, it "just works".
> On Wed, Jan 25, 2012 at 10:32 AM, Frank Altomare <lostirc@gmail.com>
> wrote:
> > It seems like this may be pretty well handled in Flex Mobile with View
> > states. Flex gives you some options for how to cash the current view
> state
> > as well as to write anything you need to a SharedObject.
> >
> > I'm not sure how much of this is handled by the OS but in my experience
> it
> > has worked pretty well
> >
> > On Wed, Jan 25, 2012 at 11:26 AM, Alex Harui <aharui@adobe.com> wrote:
> >
> > >
> > >
> > >
> > > On 1/25/12 8:14 AM, "Nick Collins" <ndcollins@gmail.com> wrote:
> > >
> > >
> > > >
> > > > One of the major issues is that of persisting the state of the Flex
> > > > application. In a portal environment, one of the core concepts is the
> > > idea
> > > > of being able to bounce around between pages and having your portlets
> > > hold
> > > > their state so that when you go back to them, you can pick up right
> > where
> > > > you left off. With a large Flex application, this is nay to
> impossible.
> > > > Sure there are all kinds of tricks you can do with LSO's,
> deep-linking,
> > > > etc. to simulate it, but I would like to see some of the more
> > enterprise
> > > > focused functionality like this be brought into the framework, or at
> > > least
> > > > taken into consideration so that it is not quite so cumbersome.
> > > > Unfortunately, I also realize that in order to accomplish this in the
> > > most
> > > > elegant manner, we would likely need changes to the runtime itself.
> :-(
> > > How is this done in the HTML/JS/CSS stack?
> > > --
> > > Alex Harui
> > > Flex SDK Team
> > > Adobe Systems, Inc.
> > > http://blogs.adobe.com/aharui
> > >
> > >
> >
> >
> > --
> > Francis Altomare,
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message