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 -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM/Yahoo: fzammetti MSN: [EMAIL PROTECTED] Author of "Practical Ajax Projects With Java Technology" (2006, Apress, ISBN 1-59059-695-1) and "JavaScript, DOM Scripting and Ajax Projects" (2007, Apress, ISBN 1-59059-816-4) Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, December 31, 2007 11:41 am, Adam Hardy wrote: > Happy New Year everybody. > > > This issue is mostly due to the validation failure mechanism which passes > flow > direct to the 'input' result without giving a chance to code the data > retrieval > needed to get data for dropdowns, associated lists, etc etc which the > view/JSP > will need. > > Currently the assorted solutions to this all seem to be forcing round pegs > into > square holes. For instance, I could make the 'input' result an action > chain to > go onto another action which does the data reading. Or I could fetch the > data > via an <s:action> or a taglib. > > The S2 documentation says in various places things like: > > "First, we need to change or query the application's state, and then we > need to > present an updated view of the application. The Action class manages the > application's state, and the Result Type manages the view." > > Three or four years ago, this issue with the view was discussed alot. > There was > talk of mechanisms termed 'view-controllers' and concepts such as 'view > logic'. > > I'd love to see this accommodated for in S2. > > There is a certain amount of coding I can do to achieve my goals in the > Results, > but it may not be the best place for it - the name 'Result' implies more > of a > link between the Action and the View, rather than a place for coding data > retrieval. > > Essentially I think there is a strong call for a Class or chain of classes > that > can be tied to each particular View, whether Tile, JSP, velocity or > whatever. > > This is obviously not what Results were designed for. I can do it > currently but > the S2 config allows only one class per ResultType - so effectively I'd > need one > ResultType per JSP, or some pattern for it. > > The sort of operations I'm thinking of: > > - retrieving lists, sometimes parameterized (e.g. a list of items allowed > in a > particular category - requires the categoryId) > > - caching lists (countries in ApplicationScope, personalized data in > session > for example) > > - localization of dropdown beans (i.e. country names) > > > Regards > Adam > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
