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
