struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dakota Jack <dakota.j...@gmail.com>
Subject Re: Eliminate Setup Actions
Date Sat, 05 Mar 2005 23:43:45 GMT
I have no interest in Shale personally.  And, I don't think this idea
has been bounced around in that regard.  The only interest I have in
this in a request driven web MVC setup, which Shale (JSF) is not. 
Shale is an event driven framework like Echo and Tapestry and is
essentially an attempt to make web programming available to those who
cannot understand what is happening: tools, in other words.  This is
okay by me.  But, I would rather do what works well than what serves
those who have limited knowledge well.

That much said.  I don't think Shale is related too much to this.  Not
sure why you were thinking that.  It was originally offered in
relation to Jericho.

Essentially it provides a set of interfaces between the model data
(database, etc.) and the view data (page, request, session,
application) scopes) which is not context but function based, sort of
like "AOP Data" to coin a combo-term.  I had the StrutsState posted on
the wiki.  The wiki keeps such information forever, of course, so it
is still there: just a bit harder to get to and really old news.


On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti
<fzlists@omnytex.com> wrote:
> I for one would be interested in such a thing.  I was starting to think
> about how to do this in a generic enough way too...
> 
> I was actually thinking of doing it declaratively, i.e., for each Action
> mapping you could specify a list of setup methods to call, and Struts
> would go ahead and do that right before it called your Action's
> execute().  I figured you'd specify the class and method to call,
> although even easier would be to write an actual SetupAction class, or
> something along those lines, with a known interface that all these
> classes would have to implement, then you would just specify the class
> and Struts would know what method to call.  But, that would probably
> mean only one setup method per setup class, and I'm not sure that would
> be optimal.
> 
> I'm kind of babbling here :), but the basic idea I do like.
> 
> Did you post your StrutsState proposal anywhere?  I'd be interested in
> seeing it.  I wonder if we were thinking along the same lines?
> 
> Then again, I know *someone* is going to point out that Shale (or I
> guess JSF generically?) already has this notion ingrained in it.  That
> might well be true, and I know neither of us are the first people to
> mention such an idea (I've seen mention of this before numerous times),
> but I for one think such a thing added to "classic" Struts would be very
> nice indeed.
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> 
> Dakota Jack wrote:
> > I think this solution is "the bomb".  I once suggested a generic
> > solution like this for Struts called StrutsState.  No one was much
> > interested, so I just built it for my own work.  It is so helpful that
> > I cannot express my gratitude toward myself to myself.  ///;-)
> >
> >
> > On Sat, 05 Mar 2005 14:27:08 -0500, Frank W. Zammetti
> > <fzlists@omnytex.com> wrote:
> >
> >>Someone else made some good suggestions about listeners and plugins.
> >>These will work well if the dropdown contents are truly static.
> >>
> >>If however it might be the kind of values that you want to make sure are
> >>up-to-date, i.e., read from a database maybe...
> >>
> >>Then one simple solution is create yourself a class that is basically
> >>independant from your application that is used for setup for a paricular
> >>screen or set of screens.  Create a static method for the setup, then
> >>from any Action associated with a page that needs that data, just call
> >>that static method at the start of the Action.  Simple, one line of code
> >>per Action and one import (or none, if it's in the same package).
> >>
> >>I would create static members of the setup class for the attribute
> >>names, and make the static setup method(s) return something like an
> >>ArrayList (or whatever type you need), so that you can call it from your
> >>Actions with something like:
> >>
> >>request.setAttribute(MySetupClass.MY_ATTRIBUTE_NAME,
> >>MySetupClass.doSetup());
> >>
> >>That way you aren't tied to it being a webapp, should you need to do a
> >>different presentation layer later.
> >>
> >>I think this is a decent, simple approach to this type of thing.
> >>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>Ben Taylor wrote:
> >>
> >>>Hi,
> >>>
> >>>Can anyone tell me if there is an easy way to put information
> >>>(required to populate drop down boxes using data from a db) in to the
> >>>request, without having to write a setup Action for each page as is
> >>>done here: http://www.reumann.net/struts/lesson2/step9.do .
> >>>
> >>>
> >>>Thank you for any help!
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>>For additional commands, e-mail: user-help@struts.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
> 
> ---------------------------------------------------------------------
> 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~

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


Mime
View raw message