This content has been marked as final. Show 8 replies
"ProjectedSurplus" <email@example.com> wrote in message
> K, I'm a newbie and my colleague is much more experienced but . . . .
> I've built an HTML mockup in which I've eliminated a whole set of IF
> isSignedIn='true' conditions by making every new site visitor a defacto
> Then where OwnerID=1 is shown "components A, B, C" (as specified from a
> array), upon signIn (as OwnerID=238) the user is shown "components A,
> D, E, F".
> But my colleague suggests the complete page redraws in HTML are very much
> different from the display list in Flash/Flex -- and thus he is adamant
> retaining "states" of visible/hidden for say component B (as well as
> essentially for D, E, F so they are "hidden" upon signOut).
> However, I in my "a little knowledge is a dangerous thing" newbie glory,
> get my head around it not being a much more straightforward coding effort
> eliminate these states in favour of I guess an "exists" or "null"
> Frankly I don't even know if I am playing semantic games, way out in left
> or maybe just not explaining myself well but if you have
> thoughts/feedback it
> would be sincerely welcomed.
I would say the latter is true (you're not explaining yourself well).
I'll take a stab at trying to understand your situation and also try to understand your question.
So you have components A, B, C, D, E, F, and prior to login, A, B, and C display, but upon login, B is hidden, and D, E, F display, so at login A, C, D, E, F are displaying. Is this a correct description of the display situation?
In Flex, the best way to address this situation would probably be to use states, and then switch to the "logged in" state or the "logged out" state depending on the situation.
Usually, states are best limited to smaller components that change based on situations, but in your case, even though ABCDEF may be complex, you use of states with them (which should be displayed before/after login) is fairly simple.
Thanks for the comments, and to extrapolate what I tried to simplify for the initial post, upon SignIn I envision querying the database and returning to flex an array of "components" to display.
Thus rather than having the flex app initialize with a set of A,B,C,D,E,F components and flip them visible or hidden depending on isSignedIn state, I envision potentially hundreds of different components which each OwnerID can choose to "load".
As such, using the states 'ON/OFF' model for each component, if for example:
1) the flex app loads (not signedIn) it loads A,B,C in the display list
2) I (OwnerID=2) sign in then A,C,D,E,F load in the display list (and B switches to hidden)
3) I signout (D,E,F switch to hidden, B flips back to visible)
4) Someone else (OwnerID=3) signs in (using same browser, admittedly not a widespread occurrence but still) and X,Y,Z components load (A,B,C flip to hidden).
I guess the point is that to me it seems detrimental (memory? security?) to have at this point in the case above now A,B,C,D,E,F all "hidden". Again, in HTML each refresh constructs the page from scratch with only the needed components and I understand flash/flex is a different model entirely.
Yet in principle I (probably misguidedly) want to eliminate the "hidden/visible" state in favour of I guess an "exists (in the display list) or not exists" (which I admit is maybe just "state" in a different semantic).
Maybe that answers my own question but comments welcome and thanks for "indulging" my perhaps peculiar concerns if nothing else ;)
Well for different users, you don't want to retain the states of components, so that doesn't sound like a great argument.
But-- honestly I don't think it's going to make any difference if I understand you correctly. I'm a little confused about what you mean by "returning to flex an array of components to display" and the earlier page refresh comment.
If you're concerned about swf size variation (some users downloading components they won't be seeing), it's probably not a concern since swf size grows slowly. (The initial minimum size may start out larger but it won't grow quickly as you add functionality.) But you could try using Flex modules if this is an issue.
If you're concerned about the time and resources needed to initialize all the "unused" components, unless you are using creationPolicy="all" somewhere, this shouldn't be a problem either. Most components aren't created/initialized at startup* (if no creationPolicy="all"), but rather get created later just before they're displayed for the first time.
*Component creation could vary based on your design, though, so that may not always be the case.
If it sounds like I understood your question well enough, I'd probably just go with whatever seems like the simpler solution that is easier to maintain.
...my 2 cents...
You should use modules. The return array can list a series of modules to load. They are loaded at runtime so they were not there until login and can be easily removed at logout. This will allow the number of available modules to be "as many as you can build" without impacting the applications load time. And of all the modules the available, user may only see a few, depending on their login.
"*gsb*" <firstname.lastname@example.org> wrote in message
> ...my 2 cents...
> You should use modules. The return array can list a series of modules to
> load. They are loaded at runtime so they were not there until login and
> can be
> easily removed at logout. This will allow the number of available modules
> be "as many as you can build" without impacting the applications load
> And of all the modules the available, user may only see a few, depending
> their login.
However, Modules are heavier than just regular components, so you may find
that you can have 10 components for less size and memory use than, say, two
Note that you can dynamically instantiate classes at runtime, but you don't
save size, only memory, by doing that
You can load Classes acting as 'modules' without impacting the initial load size by dynamically loading a Class Library .swf to define the loadable classes, sometime after the initial application load.
"*gsb*" <email@example.com> wrote in message
> You can load Classes acting as 'modules' without impacting the initial
> size by dynamically loading a Class Library .swf to define the loadable
> classes, sometime after the initial application load.
The whole issue I have with loading swfs, whether they're Modules or not, is
that you then get to fight with the application domain issues, which adds a
whole other level of complexity that is often overkill for the type of
problems most users are trying to solve by doing this, especially since one
of the fixes is to make sure that the classes you're using in your swfs or
Modules or whatever are compiled into the main application.