On Thu, 2006-09-07 at 12:50 -0700, Craig McClanahan wrote: > On 9/7/06, Martin Grotzke <[EMAIL PROTECTED]> wrote: > 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. with restoring the right view i wanted to say that the uiViewRoot (the component tree structure) shall be restored as it was when you accessed this view the last time. I do not have a wizard in mind, but switching between application modules. E.g. when you're working with an application that allows to manage companies and users, say you have two modules: user management module and company management module. When you are on a certain user related view (let's call it user_view1.xhtml), switch to a company related view and then go back to user_view1.xhtml, the component tree structure shall be restored as it was when you accessed this view the last time.
When you're working with templates (jsp/xhtml) then this restoring
is not necessary as the component tree is created from the templates,
and data will be restored according to the current state of your backing
beans. When the backing bean is in session scope the view looks as it
looked when you accessed this view the last time. So when working with
templates everything is fine...
Only when you create your component tree in code, the question is how
to restore/recreate the component tree so that the structure is the
same as it was when you accessed the view the last time.
I hope this reveals a little bit what i wanted to say...
Cheers,
Martin
>
> 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
>
>
>
signature.asc
Description: This is a digitally signed message part
