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: > > > > > On 11/18/06, Alarcón Vladimir > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Hi, I am interested to discuss new features to > a > > > > future version of Shale and I would like to > know > > > if > > > > there is interest on discussing them; if so, > > > please > > > > reply. > > > > > > Sure! The best way would be to start a new > thread > > > on the mailing list > > > and use a descriptive subject line. (Here, > you've > > > replied to an > > > unrelated thread about Tiles.) > > > > > > And your English is fine. :) > > > > > > -- > > > Wendy > > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Sponsored Link > > > > $420k for $1,399/mo. > > Think You Pay Too Much For Your Mortgage? > > Find Out! www.LowerMyBills.com/lre > > > ____________________________________________________________________________________ Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
