Hi! I understand now that this feature, although interesting, is already covered by Dialog mechanism.
I will try it deeply, before continuing this thread. Thanks, Vladimir. --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 11/23/06, Alarcón Vladimir > <[EMAIL PROTECTED]> wrote: > > > > Hi, I was thinking about what you said, but I > disagree > > (perhaps I am missing something). > > > > If I am not wrong, the init() and destroy() > methods > > are "request-oriented", so they will be called > each > > time I interact with the page, not each time I > enter > > the page. > > > > The navigateIn() (and navigateOut) method should > be > > called only once as long I stay in the same page. > If I > > enter invalid form data several times the > navigateIn() > > will just be called once, when I first entered the > > page (for example, pre-filling the form should be > done > > just the first time). Instead, the init() method > will > > be called each time I interact with the page. > > > > Analogously, the same is valid for navigateOut() > vs > > destroy(): the first one should be called only > once > > (when I finally exit the page; for example to > clean up > > controlling flags or variables), but destroy() is > > different because it's called every time I submit > the > > form. > > > > Am I right :) , or wrong :( ? > > > The init() method will definitely be called every > request, but that doesn't > mean it has to do the same thing on every request. > > If we're planning on saving state information across > requests (so that you > can tell the difference between "first time in" and > "subsequent time in", > then you'll need some information that is stored in > session scope the first > time in, and then check for it on subsequent calls. > Since this is so easy > (one or two lines of code in the init() method), it > seems hard to justify > adding callbacks at the framework level (although > nothing stops someone from > using a phase listener to create such callbacks, of > course. > > For both the "navigate in" and "navigate out" cases, > however, I think the > focus on a single page is *way* too confining ... > the interesting > interactions in web applications are where you need > to maintain state across > multiple requests and multiple pages, but then get > rid of it when you're > done with a particular conversation. The dialog > mechanism deals with that > issue quite elegantly -- for a single page or multi > page interaction, > without the artificial limitation of only supporting > a conversation on a > single page. > > By the way, this is exactly the kind of conversation > that should really be > happening on the developer list (send mail to < > [EMAIL PROTECTED]> to subscribe), so > that the user list can > focus on people using the existing product. > > Craig > > > Regards, Vladimir. > > > > --- Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > > On 11/18/06, Alarcón Vladimir > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > Feature 1: Navigate-In & Navigate-Out for each > > > page. > > > > > > > > I understand that Shale uses a bean for each > page, > > > > that's called "backing bean". A lot of times I > > > have > > > > found that I need some code to "set-up" and > for > > > > "tear-down" the page. Typically for loading > values > > > > from DB in the form of the page, setting > session > > > > variables or removing these session variables > when > > > > exiting the page. > > > > > > > > So, what do you think of having a couple of > > > optional > > > > methods named "navigateIn()" and > "navigateOut()" > > > in > > > > each backing bean that are called by Shale > every > > > time > > > > that the application enter or exit each page? > > > > > > > > > I think the use cases you describe are > adequately > > > addressed with the current > > > APIs ... see below for more. > > > > > > For example, if I am in page A and I press a > command > > > > that decides to go to page B, Shale would > execute > > > > "navigateOut()" on page A and then > "navigateIn()" > > > on > > > > page B. On the contrary, if the command > decides to > > > > stay in the page A, Shale doesn't execute any > of > > > them. > > > > > > > > I know that Shale already uses "init()" and > > > > "destroy()" but I think these methods do not > > > address > > > > very well the problems mentioned above. > > > > > > > > > > > > > > > > > > Another though: It's not uncommon that the > > > > "navigateIn()" method can go bad. For example > if > > > it > > > > tries to fill in the form, retrieving from the > DB > > > the > > > > details of customer that doesn't exist > anymore. It > > > > would be good to have a simple way to redirect > the > > > > processing returning some value (or throwing > an > > > > exception) that represents the new page that I > > > would > > > > like to go, if that happens. > > > > > > > > That's it. Any comments? > > > > > > > > > For setup actions, I'd suggest using > > > ViewController.prerender(). It is > > > called *only* on the backing bean whose view is > > > actually going to be > > > rendered, so it covers both the case where you > > > navigate elsewhere (prerender > > > gets called on *that* view's bean) or if you > stay > > > here (prerender will be > > > called on your own page bean). > > > > > > Given that, I think your navigateOut > requirements > > > are covered by destroy() > > > ... destroy() will get called on both beans if > you > > > did navigate, but you > > > won't have set anything up on the "from" bean. > Note > > > also that destroy() is > > > called *after* rendering is complete, so you can > > > clean up resources that you > > > needed for rendering. > > > > > > Vladimir. > > > > > > > > > Craig > > > > > > > > > --- Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > > > === message truncated === ____________________________________________________________________________________ Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
