Re: Feature 1: Navigate-In & Navigate-Out for each pag

[Craig McClanahan <cr...@apache.org>]

On 11/23/06, Alarcón Vladimir <vl...@yahoo.com> 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 <
dev-subscribe@shale.apache.org> to subscribe), so that the user list can
focus on people using the existing product.

Craig


Regards, Vladimir.
>
> --- Craig McClanahan <cr...@apache.org> wrote:
>
> > On 11/18/06, Alarcón Vladimir
> > <vl...@yahoo.com> 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 <ws...@gmail.com> wrote:
> > >
> > > > On 11/18/06, Alarcón Vladimir
> > > > <vl...@yahoo.com> 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
>

Re: Feature 1: Navigate-In & Navigate-Out for each pag

[Alarc�n Vladimir <vl...@yahoo.com>]

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 <cr...@apache.org> wrote:

> On 11/23/06, Alarcón Vladimir
> <vl...@yahoo.com> 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 <
> dev-subscribe@shale.apache.org> to subscribe), so
> that the user list can
> focus on people using the existing product.
> 
> Craig
> 
> 
> Regards, Vladimir.
> >
> > --- Craig McClanahan <cr...@apache.org> wrote:
> >
> > > On 11/18/06, Alarcón Vladimir
> > > <vl...@yahoo.com> 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 <ws...@gmail.com> wrote:
> > > >
> 
=== message truncated ===



 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited