Struts View

[Be...@aol.com]

Hi Guys,

I have written a proposed extension for the Struts 1.3 branch called Struts 
View. After months of examining how to solve the problem of retaining 
semi-temporary objects across HTTP requests (without going through awkward designs), I 
have come up with this solution. The problem, so eloquently stated by Rick 
Reumann, is stated in his first paragraph here: 
http://www.reumann.net/struts/articles/request_lists.jsp

Struts View is the token processor on steroids, so to speak, because it uses 
it underneath to allow multiple transactions to go on simultaneously inside of 
Struts. Furthermore, an action can create a "view" and populate the objects 
it wants to persist across requests, and then the ComposableRequestProcessor, 
with the help of a new chain command, will copy these objects into request 
scope (ala RestoreView state in JSF) each time the view is accessed. Subsequent 
actions can also validate the view's presence, retrieve the view, modify the 
view, and destroy it as necessary.

I've written a small test application with it too. I would like to donate 
this source code to ASF and hope it interests others -- there is minor work and 
improvements that can be done underneath the hood, but, by far, the input from 
the greater community would improve it beyond my feeble mind :) If people like 
it and feel it is ready, I would also like it to be nominated for inclusion 
in Struts 1.3... but that will be another discussion for the future.

If anyone can tell me where I can send the source code (ZIP file), I would 
greatly appreciate it.

PS: I have yet to subscribe to this mailing list, so if you respond to the 
entire list, please TO or CC me on the response as well.

Thanks,
Paul Benedict

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

Re: Struts View

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

<snip>
On Sun, 06 Feb 2005 19:14:14 -0800 (PST), BenedictPA@aol.com
<Be...@aol.com> wrote:
> Hi Guys,
> 
> I have written a proposed extension for the Struts 1.3 branch called Struts
> View. After months of examining how to solve the problem of retaining
> semi-temporary objects across HTTP requests (without going through awkward designs), I
> have come up with this solution. 
> If anyone can tell me where I can send the source code (ZIP file), I would
> greatly appreciate it.
> 
</snip>

Very interesting, Paul.  I would definitely like to have a copy of
this zip file, if you want to send that.  I cannot answer you more
helpfully about a standard place it would be good to send it: sorry!

Jack

-- 
"You can lead a horse to water but you cannot make it float on its back."
"Heaven has changed.  The Sky now goes all the way to our feet.

~Dakota Jack~

"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."

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

Re: Struts View

[Rick Reumann <r...@reumann.net>]

BenedictPA@aol.com wrote the following on 2/4/2005 9:59 PM:

> I've written a small test application with it too.  

Do you have a demo app somewhere that I could look at or something 
explaining in a more practical example of how it works? Thanks.

My only fear with these kind of proposed implementations is the time 
factor. In other words, does the cost in learning how the elequent 
solutions work pay off. For example, those comfortable with Struts could 
relate to a suggestion like I proposed "Validate in your Action class 
and make sure your view is always prepped there" vs possibly having to 
learn a whole new procedure within Struts. I'm not saying we shouldn't 
change Struts for the better to handle these sorts of problems, but the 
cost of how much change is implemented needs to be weighed out.

-- 
Rick

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