Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Hi,
I have some actions that I have decoupled from their jsps, so that I can
use the corresponding html components on various pages and move them
around as the client changes their mind about requirements.
I have implemented a programmatic mechanism for the action to know which
assets to populate and which jsp to render after the action has
completed, but it's getting a little tricky with some boundary fault
cases, as I've also implemented a window uniquifier to permit multiple
browser windows being acted in without session collisions.
Anyway, can someone point out what I've overlooked?  Is there a simpler
(framework) way of a loosely coupled action knowing dynamically what jsp
it's called from (esp: note the cases of the component being or not
being in a jsp:include) so that it can populate the right assets and
render the right jsp?  Using the struts-config.xml action input entry
only allows one point of origin, and using request.getRequestURI()
returns the last *action* not the originating jsp to forward back to
(not helpful when the last action is itself one of these decoupled
actions, as opposed to an inital jsp entry action).
Thanks in advance for any input.
 Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Dakota Jack <da...@gmail.com>]

Notes within:

<snip>
On 5/3/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
> > > If you care about where your action is called from,
> >
> > Only so much as to have a page for the server to send back to the user -
> > ie: the page that they were on - not some other interim page.

</snip>

I assume you are saying HTML page because that is what is displayed in the
browser.  However, it might be helpful to remember that what is being
returned is a response.

<snip>

> So we have two concepts:
>
> * A certain page sends request to the server; server does stuff; then
> it redisplays the page where it was called from

</snip>

Pages don't send anything of course.  Pages are displayed and interact with
the user.  The server does not display a thing.  I think if you start
talking more accurately and more precisely you might find many of your
problems will solve themselves.

<snip>

> * A request is sent to server from whoever it might be (aliens);
> server does stuff; then it selects a view according to its current
> state and displays it.

</snip>

The request is sent to the server and the server then responds with a
response.  The response wraps an HTML page.  The browser displays the HTML
page

<snip>

> The second approach is simpler and is more mainstream. The first
> approach is more service-oriented, where an action just does some job,
> but does not choose a view.
>
> On the other hand, when you display a page, you need to supply data
> for this page, right? Unless you stashed session-scoped data
> somewhere, your action has to prepare output data for your page. So,
> it has to know what page it was called from, and this page cannot be
> an arbitrary page, it should be one of the pages that the action can
> provide data for...
>
> Um, I see what you are saying. You call an action which has to support
> the page you call it from... Yes, this is another way of doing things,
> but I would say, not very popular.

</snip>

These discussions have some important facets.  Actions, of course, do not
"support" pages, whatever that means.  Actions can be related in some
fashtion to views.  Thinking about exactly how this is really done is
worthwhile if you are tring to build an intelligent back end.

The way forms and actions are related in Struts makes some of this harder.
The core to all this, in my view, is that there is a relationship between
the form which precedes ActionB and which follows ActionA in the following
picture: ActionA --> FORM --> ActionB.  Capturing this relationship in a
helpful way is a main task.





--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Loosely coupled pages and actions

[Dakota Jack <da...@gmail.com>]

Doing this with a link duplicates information and in its essence is not
robust.  You have your actions, your data, and your views.  In Struts, you
need to add forms.  So, you have your actions, your forms, your data, and
your views.  You need to sit down and decide what you need to build so that
your business logic flows easily and efficiently.

On 5/4/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
>
> Michael Jouravlev wrote:
>
> > On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
> >
> >> > If you care about where your action is called from,
> >>
> >> Only so much as to have a page for the server to send back to the user
> -
> >> ie: the page that they were on - not some other interim page.
> >
> >
> > So we have two concepts: [... etc etc ]
> > Um, I see what you are saying. You call an action which has to support
> > the page you call it from... Yes, this is another way of doing things,
> > but I would say, not very popular.
>
> "ah ... you speaka my language"
> mm. the key actions in question reside on 4 pages that contain a fair
> bit of data and provide the user with product-specific views of their
> data.  so I have to be able to undertake the action and return to the
> same page with an update with as little screen flicker as possible (it's
> a mimic screen for an industrial control system - scada via www).
>
> > Either you stick source page name into link parameters, or you set it
> > on the server during previous call. But then if a user goes back using
> > browser's Back button, your page on a browser and your remembered page
> > on the server won't match.
>
> ah, well, that's where my "stale-page trapping, multiple browser window
> tracing, self-inflicted framework" kicks in and solves a few problems
> for a change ...  :)  one for the boy ...
>
> > This is why sticking page name and other
> > related info into a link is more robust. A link by definition is
> > always in sync with the page it is defined in :-)
>
> buring that into my neuronal ROM at present ...
>
> > Michael.
>
> Thanks again
> Rob
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Michael Jouravlev wrote:

> On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
>
>> > If you care about where your action is called from,
>>
>> Only so much as to have a page for the server to send back to the user -
>> ie: the page that they were on - not some other interim page.
>
>
> So we have two concepts: [... etc etc ]
> Um, I see what you are saying. You call an action which has to support
> the page you call it from... Yes, this is another way of doing things,
> but I would say, not very popular.

"ah ... you speaka my language"
mm. the key actions in question reside on 4 pages that contain a fair
bit of data and provide the user with product-specific views of their
data.  so I have to be able to undertake the action and return to the
same page with an update with as little screen flicker as possible (it's
a mimic screen for an industrial control system - scada via www).

> Either you stick source page name into link parameters, or you set it
> on the server during previous call. But then if a user goes back using
> browser's Back button, your page on a browser and your remembered page
> on the server won't match. 

ah, well, that's where my "stale-page trapping, multiple browser window
tracing, self-inflicted framework" kicks in and solves a few problems
for a change ...  :)  one for the boy ...

> This is why sticking page name and other
> related info into a link is more robust. A link by definition is
> always in sync with the page it is defined in :-)

buring that into my neuronal ROM at present ...

> Michael.

Thanks again
 Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Michael Jouravlev <jm...@gmail.com>]

On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
> > If you care about where your action is called from,
>
> Only so much as to have a page for the server to send back to the user -
> ie: the page that they were on - not some other interim page.

So we have two concepts:

* A certain page sends request to the server; server does stuff; then
it redisplays the page where it was called from
* A request is sent to server from whoever it might be (aliens);
server does stuff; then it selects a view according to its current
state and displays it.

The second approach is simpler and is more mainstream. The first
approach is more service-oriented, where an action just does some job,
but does not choose a view.

On the other hand, when you display a page, you need to supply data
for this page, right? Unless you stashed session-scoped data
somewhere, your action has to prepare output data for your page. So,
it has to know what page it was called from, and this page cannot be
an arbitrary page, it should be one of the pages that the action can
provide data for...

Um, I see what you are saying. You call an action which has to support
the page you call it from... Yes, this is another way of doing things,
but I would say, not very popular.

Either you stick source page name into link parameters, or you set it
on the server during previous call. But then if a user goes back using
browser's Back button, your page on a browser and your remembered page
on the server won't match. This is why sticking page name and other
related info into a link is more robust. A link by definition is
always in sync with the page it is defined in :-)

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Michael Jouravlev wrote:

>> > On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
>> >> ... action knowing dynamically what jsp it's called from ... 
>
> 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).

Yep, this is currently what I understand and what my app does, so I'm
glad I'm not too far off-track so far!   :)

> If you care about where your action is called from, 

Only so much as to have a page for the server to send back to the user -
ie: the page that they were on - not some other interim page.

> 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.

... which is where I was heading, but thought I'd pull on the reins and
say "am I doing this right?  Is there a part of the framework that I'm
missing that does this for me".  (I suspect this'd be resolved outright
if my app was using AJAX for the shared actions ... ?)

> Try this as well: http://wiki.apache.org/struts/DataEntryForm

Had a peek - this looks like mandatory reading for me next up.

>
> The above link needs some polishing, but it already has some usable
> ideas. Write (or curse) back if my babbling was not clear ;-)
>
> Michael.

Thanks heaps
 Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Dakota Jack <da...@gmail.com>]

The input property is not necessarily or even ideally an error page output.
The input property can be used for a lot of things which are very
different.  The input property is the input property and you can do with it
whatever you like.  Most often this is used as a place to forward control,
but not necessarily because of an error.  If you want to have an intelligent
relation between forms and actions, input is essential and is not used for
errors.  Error pages should be used for errors.

<snip>
On 5/3/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
>
>
> * "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.


</input>




--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Michael Jouravlev wrote:

> 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.

Thanks ... I'm busily patting myself on the back at present for getting
that bit right, though I suspect others may inject differing opinions
and say that the error handling should be via an include in the input
page!  (ouch)  I currently just use it to link to a common self-standing
validation error handling jsp, as you said.
 Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Michael Jouravlev <jm...@gmail.com>]

On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> 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 <st...@rob.manthey.id.au> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

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 <st...@rob.manthey.id.au> 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">.
Your patience is appreciated.  If the answer is in a nuance of your
previous reply, feel free to textually slap me.
 Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Dakota Jack <da...@gmail.com>]

The JSP and the HTML do not appear and disappear.  After the appropriate
mechanisms read the JSP, the JSP is supplanted with a Servlet as well.
There is a triad of a Servlet, JSP and the HTML.  These three work in
concert.  They do not replace, etc., each other.  So, when you "click on the
link in the browser", there certainly is still a JSP.

On 5/3/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
>
> If you think of it, this is logical. When you click on the link in the
> browser, there is no JSP anymore, there is just an HTML page
> containing the location where the request is about to be sent. How
> browser would know about your last JSP?
>



--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Michael Jouravlev wrote:

> On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
>
>> ... action knowing dynamically what jsp it's called from ...
>
> [1] http://www.caucho.com/resin-3.0/webapp/faq.xtp

request attributes available in target.jsp

request.getAttribute("javax.servlet.forward.request_uri")       /testapp/index.jsp

I'm looking at testing some code around this ... let me know if I'm
definitely "barking up the wrong tree".
Thanks for the tips by the way.
 Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Rob Manthey <st...@rob.manthey.id.au>]

Michael Jouravlev wrote:

> On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
>
>> .... action knowing dynamically what jsp it's called from ...
>
> ... If you like, you can stick
> your last location into your HTML forms as a hidden field, or into all
> links as a parameter in a rewrite-URL manner.

Yuk.  Yes, I was deliberately avoiding that type of
bare-your-soul-to-the-user html programmatic stuff.  I'm acheiving a lot
with serverside programmatic side-steps at present, and was aware of
that possibility, but am trying to find any way to avoid adding another
"special" field in my url rewrites.
 Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Michael Jouravlev <jm...@gmail.com>]

On 5/3/06, Rob Manthey <st...@rob.manthey.id.au> wrote:
> Hi,
> I have some actions that I have decoupled from their jsps, so that I can
> use the corresponding html components on various pages and move them
> around as the client changes their mind about requirements.
> I have implemented a programmatic mechanism for the action to know which
> assets to populate and which jsp to render after the action has
> completed, but it's getting a little tricky with some boundary fault
> cases, as I've also implemented a window uniquifier to permit multiple
> browser windows being acted in without session collisions.
> Anyway, can someone point out what I've overlooked?  Is there a simpler
> (framework) way of a loosely coupled action knowing dynamically what jsp
> it's called from (esp: note the cases of the component being or not
> being in a jsp:include) so that it can populate the right assets and
> render the right jsp?

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.
Anyway. In case of <jsp:include>, you can either pass a request
parameter using <jsp:param>, or you can check for
"javax.servlet.include.request_uri" attribute of request object to see
if the action is included and what is the address of included fragment
as well as of parent page. See servlet spec or check out Caucho FAQ
[1].

> Using the struts-config.xml action input entry
> only allows one point of origin, and using request.getRequestURI()
> returns the last *action* not the originating jsp to forward back to
> (not helpful when the last action is itself one of these decoupled
> actions, as opposed to an inital jsp entry action).

If you think of it, this is logical. When you click on the link in the
browser, there is no JSP anymore, there is just an HTML page
containing the location where the request is about to be sent. How
browser would know about your last JSP? If you like, you can stick
your last location into your HTML forms as a hidden field, or into all
links as a parameter in a rewrite-URL manner.

[1] http://www.caucho.com/resin-3.0/webapp/faq.xtp

Michael.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Dakota Jack <da...@gmail.com>]

Rahul, you cannot just jump into a conversation with irrelevant comments.
Start your own thread.  Do you need help doing that?

On 5/4/06, Rahul Krishnarao Patil <Ra...@mindcraftsoftware.com>
wrote:
>
> Hi all ,
> I want to Configuring datasource with tomcat for oracle . But i am not
> able to find any proper document for this configuration. Can anybody help
> me out .
> I am using Tomcat 5.5.16 and oracle 9i.
>
>
> Thanks and Regards,
> Rahul Patil
>
>


--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

[OT] Re: Loosely coupled pages and actions

[Dave Newton <ne...@pingsite.com>]

Rahul Krishnarao Patil wrote:
> I want to Configuring datasource with tomcat for oracle . But i am not 
> able to find any proper document for this configuration.

Are  you serious?

http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html

< 15 seconds w/ Google.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Loosely coupled pages and actions

[Rahul Krishnarao Patil <Ra...@mindcraftsoftware.com>]

Hi all ,
I want to Configuring datasource with tomcat for oracle . But i am not 
able to find any proper document for this configuration. Can anybody help 
me out .
I am using Tomcat 5.5.16 and oracle 9i.


Thanks and Regards,
Rahul Patil