On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:
Thanks Michael. I'm just picking my way through your answer ...
Ok, the <jsp:include> bit is interesting ... and I'm going to consume
that in detail later, that's a lesser case at present.
One question on the non-include side ... ->
Michael Jouravlev wrote:
> On 5/3/06, Rob Manthey <[EMAIL PROTECTED]> wrote:
>
>> ... action knowing dynamically what jsp it's called from ...
>
> Unless it is the case of <jsp:include>, I personally believe that
> action should not know or care to know where the request came from.
I'm anticipating that this is on the back of an MVC axiom that the
action updates the model and then the jsp just fetches the assets it
wants from the model, so the "which assets does the action need to
populate" is catered for by not anticipating which page you are heading
for, just update all assets that the action has tainted. (I'm probably
still missing the finer points, as this seems not to be as "lightweight"
an approach as updating the assets that were tainted by the action *and*
are going to be wanted in the next jsp, but ok it would solve the asset
selection problem.) However (correct me please), surely *something*
needs to know which jsp to fetch to return to the user ... ? If this is
removed from the action's responsibility, how do I configure the Struts1
framework to dynamically route back to the right page when an action can
be called from multiple jsps ... ? struts-config.xml seems to only
allow one page for an action to anonymously default back to after
completion ... <action input="pagename">.
First, about input="pagename" bit. I personally believe that
* "input" property should be deprecated
* if it is not deprecated, then it should be at least renamed to
"error", because "input" is a misleading name
"input" property is not an input page, it is the location where
control is forwarded in case of error. I think that "input page that
preceds an action" and "the target location for situation when error
occurred" are totally different concepts.
The request always comes to an action class, not to some related page
like "input". Well, except the situation when you have
validate="true", your request data does not validate, and control goes
to "input" page without your action class being called at all. This
sucks if you ask me.
Now, try to abstract from input pages and such. You have HTTP
protocol, client on this side and an application on the server side.
The request is just a call from client to server. Forget about pages,
think in terms of web services, for example. Why would the server care
where there request came from? What it should care is the request
data. Despite that HTTP is stateless, the application has its state,
which is defined by
* state stored on the server, like session-scoped data
* input data that was submitted with request
Based on this information, application updates the Model (and its
state) if needed (that is, updates session objects or writes to a
database, database being a part of server state), and displays a view.
It may choose a view out of several possible views based on current
state (again, if you do not use session-scoped objects, current state
is completely defined by input data and maybe by some stuff that you
pulled from the database).
I believe that this concept provides more freedom and less
dependencies between actions.
If you care about where your action is called from, just pass this
info along as request parameter, this is the easiest thing. Or,
instead of passing something like "calledFrom=SearchPage" you can pass
something like "searchCriteria=...". The action would know that it
needs to perform a search and to return found.
Try this as well: http://wiki.apache.org/struts/DataEntryForm
The above link needs some polishing, but it already has some usable
ideas. Write (or curse) back if my babbling was not clear ;-)
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
