On 9/7/06, Martin Grotzke <[EMAIL PROTECTED]> wrote:
If I understand what you're saying, this would indeed require a custom State Manager (which Shale doesn't have ... it assumes the JSF implementation will take care of that level of details).
That being said, let's see if we can drill down a little bit about what you mean by "restores the right view". If you have defined something like a wizard dialog with next and previous buttons, Shale will create a new view each time navigation occurs ... but the *data* on that view can easily be the same as it was the last time this same view was visited, if you bind the fields there to something stored in session scope, or in the data object associated with this particular dialog.
That seems like something much easier for an application developer to understand and take advantage of, rather than trying to define some sort of rule that says whether a new view should be created, or a previous historical view restored, when a particular transition happens.
Craig
On Tue, 2006-09-05 at 17:12 +0200, Ricardo Tercero Lozano wrote:
> Forgot to say than If you really want to complete restore a previous
> rendered view you must extend the NavigationHander functionality or
> use a 'dialog' functionality like Shale dialogs
> (http://shale.apache.org/features-dialog-manager.html) or sandbox
> conversation components.
Do you know if shale's dialog manager restores the right view when
you come back to a certain view? So when the navigation is like
view_a.xhtml -> view_b.xhtml -> view_a.xhtml, then would the dialog
manager restore the uiViewRoot from the first step in the last step?
AFAICS invokes the (myfaces) NavigationHandlerImpl a createView when
you navigate to another view. If would be good to have the possibility
to restore a view that previously was active. Probably this would
additionally require a custom StateManager...
If I understand what you're saying, this would indeed require a custom State Manager (which Shale doesn't have ... it assumes the JSF implementation will take care of that level of details).
That being said, let's see if we can drill down a little bit about what you mean by "restores the right view". If you have defined something like a wizard dialog with next and previous buttons, Shale will create a new view each time navigation occurs ... but the *data* on that view can easily be the same as it was the last time this same view was visited, if you bind the fields there to something stored in session scope, or in the data object associated with this particular dialog.
That seems like something much easier for an application developer to understand and take advantage of, rather than trying to define some sort of rule that says whether a new view should be created, or a previous historical view restored, when a particular transition happens.
Cheers,
Martin
Craig
>
> Ricardo.
>
>
> On 9/5/06, Ulrich Teichert <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Ulrich Teichert a écrit :
> > >
> > >
> > > Uh-oh. That's a bit hard - how do I know which property
> really is
> > required?
> > > I thought that when it's required and missing, I would get
> a "method not
> > > found" exception...
> > >
> > Sorry, was not clear. I meant, when you programmatically
> create a
> > Component X with application.createComponent("X"), ensure
> that all X
> > properties that are marked as required by the corresponding
> X taglib
> > have been set.
> > (for example, HtmlInputText as 2 required properties: id and
> value).
> > I never meant to add methods to your bean :) I just meant to
> ensure your
> > UIComponent getXXXX() {... } was doing all required
> initialisation steps
> > for every component it has created.
>
> I think that should be the case. Else, I would expect some
> sort of trouble
> during the initial display stage, which is OK in my case.
> Well, it doesn't
> hurt to double check, so I'll gonna do that anyway.
>
> > >> 4) it still fails with only 1 binding, and no nested
> panelGrid.
> > >>
> > >
> > > I've tried whithout the nested panelGrid, did not help
> either. I wasn't
> > > able to strip it down to one binding only and still
> perform something
> > > usefull. What did you wanted to test in that case?
> > >
> > Wanted to check there was no bug with embedded panelGrids
> and that there
> > was no problem with the fact your bean seems to have 2
> dependents on
> > each other components.
>
> OK, I'll see if I can strip one component for testing.
>
> > > CU,
> > > Uli
> > >
> > >
> > That's all i have in my mind as solution, quite poor :)
> Sorry!
>
> I'm happy for all feedback I can get and you have been very
> helpfull.
> I appreciate that you took the time to look into this. It
> seems to me
> that not many people are using myfaces this way.
>
> Not giving up yet,
> CU,
> Uli
> --
> Ulrich Teichert
> Stormweg 24
> 24539 Neumünster, Germany
>
>
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu
> sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
