Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <477A5217.5090102@pontarelli.com>
Date: Tue, 01 Jan 2008 07:45:43 -0700
From: Brian Pontarelli <brian@pontarelli.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: invent way to get dropdown data in JSP not using actions or
 taglibs?
References: <47791BD2.6050108@cyberspaceroad.com>
 <64063.170.201.180.136.1199119912.squirrel@webmail.chiron.lunarpages.com>
In-Reply-To: 
 <64063.170.201.180.136.1199119912.squirrel@webmail.chiron.lunarpages.com>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It seems like this is a variation on the Preparable theme. I went 
through this decision process 9 months ago and decided to use the 
<s:action> tag to prepare my forms, mostly for lack of any other solution.

A few more things I ran into that I wanted and could only achieve with 
the <s:action>

- Share preparation between actions/forms without sub-classing. This 
occurs when you have two actions that share a form (add and edit for 
example) and both prepare the form in very similar ways, with some 
differences. The common preparation code should be written once and then 
accessible by both actions.

- The preparation logic should ONLY be called when the form is rendered. 
If I'm remembering correctly, any action that implements Preparable is 
called via the interceptor chain during all submissions, including a 
valid form submission where the form doesn't need to be prepared again. 
The solution should be capable of understanding that the form is being 
rendered.

Here's some more ideas for solutions:

1. Modify the <s:form> tag so that if the action it is going to call 
implements Preparable than it is invoked prior to rendering the rest of 
the form. This would require removing the prepare interceptor altogether 
or removing it from the default stack.

2. Add a <s:prepare> tag that somehow calls the preparation code.

3. Make the prepare interceptor more intelligent to understand when 
forms are being rendered (is this possible without major headaches?)

-bp


Frank W. Zammetti wrote:
> Hi Adam,
>
> If I'm understanding you, what I think you essentially want is the JSF
> concept of "page/component state saving" where, talking about an S2 app,
> the page, and by extension the "components" on each page (dropdowns,
> testboxes, etc), would know how to get their current state and render
> themselves.
>
> I suppose you could do that today easy enough by storing the values (and
> data, in the case of dropdowns) in session and always render from there. 
> Maybe not the best answer from a performance/resource utilization POV.
>
> Maybe better would be for each tag in each theme to accept an attribute
> that specified the method of an action to call when rendering itself to
> populate it's data (default to populateXXX() where XXX is the ID of the
> element, so maybe the attribute is optional).  Then you could do whatever
> you wanted in that method to provide the tag the data it needs to render
> the element with the current state.  If that method isn't found, just let
> the tag do whatever it would normally do now, so as to not break
> backwards-compatibility, and let the developer only write the code they
> really need to.
>
> (for all I know, S2 already offers this, I don't really know)
>
> Frank
>
>   


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