-Original Message-
From: Ben Taylor [mailto:[EMAIL PROTECTED]
Sent: 05 March 2005 08:03
To: Struts Users Mailing List
Subject: Eliminate Setup Actions
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)
Many people would suggest that using Actions in Struts would be
preferrable whether or not you need to do any setup or any
processing in the movement from one page to another in a website.
I think of Actions as places to organize what needs to be done
(processing the request) and providing any
But do you see the point in setup functions *outside* an Action's code
that occurs on the forward-level? Meaning, once an Action returns a
forward, do some setup based on what forward was returned?
If so, check out the Bugzilla ticket I opened today where I provide this
functionality, as well as
: Eliminate Setup Actions
Many people would suggest that using Actions in Struts would be
preferrable whether or not you need to do any setup or any
processing in the movement from one page to another in a website.
I think of Actions as places to organize what needs to be done
(processing
On Wed, 9 Mar 2005 14:07:04 -0500 (EST), Frank W. Zammetti
[EMAIL PROTECTED] wrote:
But do you see the point in setup functions *outside* an Action's code
that occurs on the forward-level? Meaning, once an Action returns a
forward, do some setup based on what forward was returned?
Yes. I
More (application-level) code isn't needed... it's just a question of
making it declarative rather than programmatic, which is how so much of
Struts already is.
Here's an example from the example app posted to the Bugzilla ticket I
referenced (ticket # 33935 if you want to download it and try
This is more, not less, code, is it not? You have:
setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1
setupMethod=setupMethod1 /
which has to be used for all actions that use this, right?
compared to:
SetupClass1.setupMethod1(request)
I don't see the less code point.
On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said:
This is more, not less, code, is it not? You have:
setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1
setupMethod=setupMethod1 /
which has to be used for all actions that use this, right?
compared to:
On Wed, March 9, 2005 3:11 pm, Frank W. Zammetti said:
On Wed, March 9, 2005 3:02 pm, Shey Rab Pawo said:
This is more, not less, code, is it not? You have:
setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1
setupMethod=setupMethod1 /
which has to be used for all actions
Mailing List; Ben Taylor
Subject: Re: Eliminate Setup Actions
This is more, not less, code, is it not? You have:
setupItem setupClass=com.omnytex.setupexample.setups.SetupClass1
setupMethod=setupMethod1 /
which has to be used for all actions that use this, right?
compared to:
SetupClass1
Frank, watch that anal talk, would you? I could do without that. :)
My point was just that I don't see a problem and don't understand how
this would help.
--
No one ever went blind looking at the bright side of life.
-
To
I can't state it any clearer than I have, or any clearer than another
poster (I forget who) just did a few minutes ago. If for absolutely no
other reason, convenience and ease of change are good justifications.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
We probably have beat this to death, Frank, but having the framework
setup pages with declarations in the action mappings is not consistent
with MVC to my way of thinking. I definitley would not do this. I
like to keep things simpler. But, others seem to like it. So, maybe
you have something
Can you add this XML functionality to the struts-config please? Then I
won't hate you:)
BusinessApplication
start
read_client_mind
write application for me while I surf web
/read_client_mind
/start
deploy/
getPayCheckAndGoHome/
/BusinessApplication
An extension of the approach here is what we so with the Oracle ADF
framework, namely that of associating a metadata XML file with the
Action which drives the runtime framework to prepare the bindings for
the page. So this is taking the whole declarative thing that much
further by basically
Sorry, I haven't been following this whole thread, but when I saw
this config example from Frank:
action path=myAction type=com.omnytex.actions.MyAction
setupItem class=com.omnytex.setup.MyActionSetup
method=setupMethod1 /
forward name=defaultForward path=page1.jsp
No Joe, you didn't miss anything :) I was already thinking about how easy
this would be under 1.3 too. But, I'm hesitant to start playing with 1.3
until it's actually released (at least in beta). This is an easy add to
1.3, as you indicate, and I'm also looking forward to porting my StrutsWS
At 9:37 AM -0500 3/8/05, Frank W. Zammetti wrote:
No Joe, you didn't miss anything :) I was already thinking about how easy
this would be under 1.3 too. But, I'm hesitant to start playing with 1.3
until it's actually released (at least in beta). This is an easy add to
1.3, as you indicate, and
On Tue, March 8, 2005 9:48 am, Joe Germuska said:
I do think we're pretty close, although not much has happened since
the last wave of what will 1.3.0 be discussions. I know I haven't
had much time for development and documentation in the last few weeks.
I know the feeling :) I'm actually
On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti
[EMAIL PROTECTED] wrote:
You mean as far as 1.x goes? I'm just looking now to see how the config
file is read in (haven't played with Digester at all yet). But yes, just
dropping the doctype was how I was going to, temporarily, get
LOL, sorry Frank, I didn't mean to drown you in documentation. :)
On Tue, 8 Mar 2005 09:31:04 -0600, Hubert Rabago [EMAIL PROTECTED] wrote:
On Tue, 8 Mar 2005 10:14:36 -0500 (EST), Frank W. Zammetti
[EMAIL PROTECTED] wrote:
it might be
helpful to review those messages as there were some
And I've been silently wishing you'd add it, too. :)
We've had discussions about this maybe twice before, and another time
I lit the flame, you responded, but I wasn't able to follow through
with the discussion.
Well, then, now you've gone and done it, Hubert... I've just
committed the basic
For anyone interested, I have a Struts View demo which that allows dialogs
to occur in Struts 1.3. This could work in Struts 1.2, but I haven't had the 3
minutes to write an extended RequestProcessor for current apps. Basically, a
dialog allows objects to persist across HTTP requests.
Please
I just found this link which gives FAR more detail on Tiles
Controllers --
http://www.theserverside.com/articles/article.tss?l=Tiles101
On Sat, 5 Mar 2005 13:15:44 -0600, Corey Probst [EMAIL PROTECTED] wrote:
If your app is using tiles, take a look at Tile controllers.
You could call the action directly (instead of the .jsp) and have the action
add the options to the request if they're not already there, then forward.
- Original Message -
From: Ben Taylor [EMAIL PROTECTED]
To: Struts Users Mailing List user@struts.apache.org
Sent: Saturday, March 05,
You could populate static combo boxes with data stored as application
scope attributes that are set at app startup by either a
ServletContextListener or a Struts PlugIn (those attributes will be
available to any JSP in the app).
Erik
Ben Taylor wrote:
Hi,
Can anyone tell me if there is an easy
If your app is using tiles, take a look at Tile controllers.
http://struts.apache.org/api/org/apache/struts/tiles/Controller.html
The controller will get called right before rendering the jsp,
allowing you to put your info into the request.
Corey
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
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
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
... 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
... 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
Sure, that would work. But, then you are limiting the developer to
basically one setup per class, or forcing them to do some work that
Struts really should be doing...
If I were to add something like this to Struts (and I have enough
interest in this idea that I'd love to persue it, assuming
On Sat, 05 Mar 2005 17:56:40 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
Then again, I know *someone* is going to point out that Shale (or I
guess JSF generically?) already has this notion ingrained in it.
But of course! :-)
In Shale, a ViewController bean (pretty much the equivalent
[mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the
developer to basically one setup per class, or forcing them
to do some work that Struts really should
[mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you are limiting the
developer to basically one setup per class, or forcing them
to do some work that Struts really should
...And I did in fact mean you when I wrote someone :)
I generally like the overall idea behind ViewController beans as you
describe. If there was one problem that I see it is that the
prerender() method is specific to the page the bean is associated with.
This can be viewed as good or bad...
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
systems on and off.
Is it IoC enough for you?:-)
Regards
Leon
-Ursprüngliche Nachricht-
Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Gesendet: Sonntag, 6. März 2005 00:14
An: Struts Users Mailing List
Betreff: Re: Eliminate Setup Actions
Sure, that would work. But, then you
Ben,
I don't want to bother raw Struts user's mailing list,
but I would like to introduce OzStruts again.
because all the Struts developers are struggling with this same issue again,
again and again.
I think this functionality must be prepared as part of web applicaiton
framework.
If you have
LOL This reminds me of the Greek guy in My Big Fat Greek Wedding
who attributes all ideas to Greeks. I think your idea is cool and was
cool when previously presented, but it not only is not but cannot be
part of Shale because of the basic structure of that framework. I
don't think that Shale or
I think that this is the virtue and the vice, isn't it? JSF is
page-centric. It is essentially Swing on html. If you like Swing,
you might love Shale/JSF. That is not a criticism. I like Swing and
think that Shale/JSP is very interesting. Nothing like Struts and a
crime to call itself
I mentioned Shale because of the whole prerender() idea that Craig
talked about in another reply to this thread. I didn't know enough to
specifically name the ViewController and prerender() methods though, I
just remembered the basic concepts :) I think that aspect of Shale (and
JSF too as I
Really interesting stuff, Leon. By making data that normally is
static dynamic, you also do a lot more than is immediately evident.
This is very exciting stuff, in my opinion. I originally tried to do
this sort of thing with hot-deploy and classloaders. I am not sure
that is not a good
On Sat, 05 Mar 2005 18:42:35 -0500, Frank W. Zammetti
[EMAIL PROTECTED] wrote:
...And I did in fact mean you when I wrote someone :)
I generally like the overall idea behind ViewController beans as you
describe. If there was one problem that I see it is that the
prerender() method is
I think, for me, all of this goes the opposite direction of where my
mind is going, that is, a more service-oriented approach.
If you view the setup functionality as a discrete service, then it is
reasonable to say that particular service might be called from multiple
places.
For instance,
That would actually
fulfill the goals I had. Would you find that difficult to manage?
No, surely not :-) I we were misunderstanding each other; actually you wrote
I'm not sure about introducing a whole new collection of objects, and
management components to go along with it.
And I just
That would actually
fulfill the goals I had. Would you find that difficult to manage?
No, surely not :-) I we were misunderstanding each other; actually you wrote
I'm not sure about introducing a whole new collection of objects, and
management components to go along with it.
And I just
LOL dimplomatic (???) -- This is a Freudian feast! LOL ///;-)
Once you really got going with half-assed, Frank, I think I am up on
you on the scale today. ///;-) I actually have a lot of sympathy for
the attempt to compete with Micro$. They are clever as all get out.
However, I think the
49 matches
Mail list logo
