This content has been marked as final. Show 8 replies
"vikbar" <firstname.lastname@example.org> wrote in message
> My whole application is written in JSF. I am using SWFobject to embed Flex
> component in a JSF page[which just contains Flex swf only]. Now the user
> click a button on JSF application and can navigate to this JSF page[with
> application embedded], and he can again click a button on the Flex
> and move back to original JSF application.Now the issue is when the user
> from original JSF page to Flex embedded JSF page he looses the old state
> of the
> Flex application.
> So My question is, is there a way that old state of the flex application
> saved.this different then caching swf, which I am already doing, But I do
> want the SystemManager the create a new instance of application object
> then I loose all the components and there previous states, but instead use
> last saved application instance[bypassing all the lifecycle of application
> object and adding the existing application instance to the display list
Isnt the HistoryManager approach more specific to Flex application i.e if user is just navigating with in the flex application? In my case the user will navigate between a JSF page which does not have any SWF file and the another one which has swf file embedded. Now everytime when the suer moves to the flex embedded JSF page from the Non Flex JSF page these are the steps which are always going to happen :
1.) System Manager will get initialized and will create PreLoader instance.
2.) The preLoader will then try to download the swf file. Now since this is the second time the user is coming back to the flex page so the broswer would have already cached this swf, so Preloader will skip the downloading swf/RSl step and hence you wont see any initialization progress bar.
3.) New Application object will get instantiated and will go through its whole lifecycle.
So, I guess historyManager approach will work only if the user stays on the flex application only and navigates with in flex application itself(so in that case if the user clicks back then it knows which flex component or view to display), but in my case user will completely move away from flex page to a JSF page and then will try to come back.
Does that makes sense?
"vikbar" <email@example.com> wrote in message
> Hi Amy,
> Isnt the HistoryManager approach more specific to Flex application i.e if
> is just navigating with in the flex application? In my case the user will
> navigate between a JSF page which does not have any SWF file and the
> one which has swf file embedded. Now everytime when the suer moves to the
> embedded JSF page from the Non Flex JSF page these are the steps which are
> always going to happen :
> 1.) System Manager will get initialized and will create PreLoader
> 2.) The preLoader will then try to download the swf file. Now since this
> the second time the user is coming back to the flex page so the broswer
> have already cached this swf, so Preloader will skip the downloading
> step and hence you wont see any initialization progress bar.
> 3.) New Application object will get instantiated and will go through its
> So, I guess historyManager approach will work only if the user stays on
> flex application only and navigates with in flex application itself(so in
> case if the user clicks back then it knows which flex component or view to
> display), but in my case user will completely move away from flex page to
> JSF page and then will try to come back.
You'd need to put the right stuff in the url to make it work, just like if
you were calling a page that's expecting GET params. I don't really use the
HistoryManager, so you'll need to either look into this yourself or ask
someone who knows more about it.
Hm... I hate to say this, but unless you have a really really really good reason, I'd have done one "page" with a single swf that contains all the different views you need. If it's too big and you need to break it up, you usually use modules to defer loading of certain parts. :-(
It may even be easier to forget about saving the app's state using this technically possible, but arguably 'hackish' solution, and just re-engineer the client in a single swf. Manually saving your application's state may work out for you if you try it... if it's fairly simple, but once it gets complex I suspect you'd have regrets.
The good news is that if you decided to use modules, since you already designed in a very modular way, it'd be relatively easy to create a bare-bones master loader that goes and fetches each required module as needed. It would be alot easier for the modules to talk to one another (generally through events within this master SWF or even a ModelLocator if you use Cairngorm), and you wouldn't have to worry about them losing state since they don't get refreshed.
IMO I just don't think it's worth the effort making these pieces talk via url parameters, unless were talking some very basic comminications that are guaranteed not to get complex. Plus it's ugly in the browser bar.
And, another thing (I confess I didn't read your entire first post until now but that changes nothing) - if you want to retain the state of something as complicated as a Tree control, so that the same nodes are expanded, etc. -- ack. That sounds like alot of extra work you'd be doing.
BTW in case you don't know - to implement this "master swf" you'd probably use a ViewStack. You also should look into a TabNavigator if you prefer that instead.
This should also simplify your server code greatly since the server won't need to worry about your client's view state, like an old school web application. That's the old way of thinking - with RIAs that responsibility is delegated to the client, and the server gets to just "serve" data, like it's supposed to. =)
First of all thanks a lot for all your time and responses.
May be I did not explain it very well.
Heres brief history..
We already have a complete JSF application[3 releases are already in production]. With our new release we have a requirement where we need to support highly interactive vector graphics, for which we are using flex. So basically we have to provide a hook into our existing application[so we can not re-engineer]. If everything would have been flex then yeah we would have used one Master SWF with modules. But we are in a stituation where we need to redirect the user from this pure JSF application to this Flex page[which is again a JSF page with flex components embedded] and back again to the JSF application. Now as I said earlier the issue is, if the user does something on the flex page, and goes back to pure JSF application to lookup something and then tries to come back to the Flex page we wanted to retain the old flex application state[so that user does not loose his old data/state].
Now the functionality in Flex is big enough that it needs to be in its own separate page.
We looked at may be opening a new pop-up browser window for flex[rather than redirecting back and forth in same window], but that leads the traditional web applications issue where managing these multiple broswer window becomes a nightmare[session corruption can happen...session time-out creates issue for cleaning up child windows etc], so we did not use that.
Thats why we decided to use one window and use redirect mechanism, and thats where we ran into issue where whole flex application gets reinitialized each time a redirect happens to this page. So we are lookign for ways where based on some url parameter passed from Pure JSF application, the flex application will either reinitialize or
display the old cached state.
Still stuck... Any ideas...
Ahh, that is clearer now.
This is gonna be tough I think. Other than passing a ton of parameters back and forth (that's really going to be a ton of work if you're using something as complex as trees)... a possibly crazy idea does come to mind.
Other than this muppetry I don't think I have anything else to offer here. Good luck if you try it, I'd be interested in hearing what happens, heh.