Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

--- Craig McClanahan <[EMAIL PROTECTED]> wrote: > It is also instructive to observe the growing > popularity (in > enterprise Java circles) of IoC approaches to > instantiating business > and service objects (Spring, Hivemind, > PicoContainer, etc.), which are > implemented as POJOs and composed

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

I second the nugget idea and double the prize! ///;-) On Thu, 17 Mar 2005 01:01:11 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > -Original Message- > > I'm thinking this post deserves a St. > > Paddy's day award for being a > > hidden nugget of gold in a very large pot :) > > I

[Apache Struts Wiki] Updated: FrontPage

Date: 2005-03-16T22:06:33 Editor: MartinCooper Wiki: Apache Struts Wiki Page: FrontPage URL: http://wiki.apache.org/struts/FrontPage no comment Change Log: -- @@ -22,7 +22,8 @@ * StrutsUpload -- a pro

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

-Original Message- > I'm thinking this post deserves a St. > Paddy's day award for being a > hidden nugget of gold in a very large pot :) I'm not entirely sure how to take that, but I've never been one to turn down an award of any kind :) I had my corned beef and cabbage on Sunday any

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

-Original Message- > I'm thinking this post deserves a St. > Paddy's day award for being a > hidden nugget of gold in a very large pot :) I'm not entirely sure how to take that, but I've never been one to turn down an award of any kind :) I had my corned beef and cabbage on Sunday any

[Apache Struts Wiki] New: WhyChain

Date: 2005-03-16T22:01:10 Editor: MartinCooper Wiki: Apache Struts Wiki Page: WhyChain URL: http://wiki.apache.org/struts/WhyChain Ted's excellent explanation of why we're using Commons Chain in Struts 1.3. New Page: The following is the bulk of a message posted to the Struts D

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 14:04:50 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Wed, March 16, 2005 1:47 pm, Joe Germuska said: > > I disagree. Actions are not fine the way they are. They depend too > > directly on the Servlet API, which is one of the reasons they are too > > hard to

[Apache Struts Wiki] Updated: SetupItems

Date: 2005-03-16T20:34:46 Editor: FrankZammetti Wiki: Apache Struts Wiki Page: SetupItems URL: http://wiki.apache.org/struts/SetupItems no comment Change Log: -- @@ -21,7 +21,7 @@ The setupItem element

[Apache Struts Wiki] New: SetupItems

Date: 2005-03-16T20:31:21 Editor: FrankZammetti Wiki: Apache Struts Wiki Page: SetupItems URL: http://wiki.apache.org/struts/SetupItems no comment New Page: ##language:en = Overview = One of the questions I see asked over and over on the Struts Users mailing list, in various r

[Apache Struts Wiki] Updated: FrontPage

Date: 2005-03-16T20:02:44 Editor: FrankZammetti Wiki: Apache Struts Wiki Page: FrontPage URL: http://wiki.apache.org/struts/FrontPage no comment Change Log: -- @@ -32,3 +32,4 @@ * StrutsMinimalInstall

[Apache Struts Wiki] New: FrankZammetti

Date: 2005-03-16T19:57:34 Editor: FrankZammetti Wiki: Apache Struts Wiki Page: FrankZammetti URL: http://wiki.apache.org/struts/FrankZammetti no comment New Page: ##language:en Frank W. Zammetti Email: [[MailTo([EMAIL PROTECTED])]] Here's to hoping I don't break the whole Wik

svn commit: r157885 - struts/build/trunk/maven-nightly.sh.current

Author: jmitchell Date: Wed Mar 16 19:56:58 2005 New Revision: 157885 URL: http://svn.apache.org/viewcvs?view=rev&rev=157885 Log: fix nightly sample (FYI...I run this exact script to build the nightlies. Under a different name of course for security reasons) Modified: struts/build/trunk/mave

svn commit: r157870 - struts/build/trunk/maven.xml

Author: jmitchell Date: Wed Mar 16 19:11:31 2005 New Revision: 157870 URL: http://svn.apache.org/viewcvs?view=rev&rev=157870 Log: forgot to add jar:install so dependent subprojects can reuse each others artifacts Modified: struts/build/trunk/maven.xml Modified: struts/build/trunk/maven.xml

svn commit: r157869 - struts/apps/trunk/shared/project.xml

Author: jmitchell Date: Wed Mar 16 19:10:18 2005 New Revision: 157869 URL: http://svn.apache.org/viewcvs?view=rev&rev=157869 Log: remove unnecessary prop Modified: struts/apps/trunk/shared/project.xml Modified: struts/apps/trunk/shared/project.xml URL: http://svn.apache.org/viewcvs/struts/a

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

Alrighty then. Ted Husted wrote: We've already laid out a roadmap of successive changes to the 1.x series. [http://struts.apache.org/roadmap.html] And discussed on the list whether this represented the consensus view. The nightly build is API compatible with Struts 1.2.x. People should be able to

Stabilising 1.3 (was Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code))

On Wed, 16 Mar 2005 19:07:13 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 16 Mar 2005 10:03:49 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > > Acknowledged. I'm just not ready to be a release manager, especially > > for Struts. If someone is ready to be the release manager, they can

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, 16 Mar 2005 13:55:39 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > As long as that is the case, the only > argument for a 2.x version number that makes any sense would be > marketing related (get some attention with a major new version number > to hide the fact that it's pretty muc

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 10:03:49 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > Acknowledged. I'm just not ready to be a release manager, especially > for Struts. If someone is ready to be the release manager, they can > call a freeze and we can let some of this sit, but until then, I will > keep m

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

We've already laid out a roadmap of successive changes to the 1.x series. [http://struts.apache.org/roadmap.html] And discussed on the list whether this represented the consensus view. The nightly build is API compatible with Struts 1.2.x. People should be able to use Sruts 1.2.x applications w

svn commit: r157832 - struts/core/trunk/src/share/org/apache/struts/chain/contexts/MockActionContext.java

Author: germuska Date: Wed Mar 16 15:49:28 2005 New Revision: 157832 URL: http://svn.apache.org/viewcvs?view=rev&rev=157832 Log: Simple MockActionContext - are there any useful methods we could add to improve testing? Added: struts/core/trunk/src/share/org/apache/struts/chain/contexts/MockA

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

Admittedly I wasn't using Struts back then... I was still pounding away on my own custom framework. But, from what you've said, I would have made the same argument at that point, that being that 1.1 should have been 2.0. In fact, as you describe here, I would have argued it even more stongly b

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Why don't we agree to build something that will work well when used properly and let the "idjits" get idjits? Jack On Wed, 16 Mar 2005 14:03:59 -0800, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Wed, 16 Mar 2005 15:53:35 -0600, Michael Rasmussen > <[EMAIL PROTECTED]> wrote: > > > > > > I under

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

I think if we bent the technology for "miscreants" this far, we may eventually go back to the typewriter and carbon paper. Jack On Wed, 16 Mar 2005 14:04:06 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Wed, 16 Mar 2005 10:08:15 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > > > On

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

+42 I cannot imagine the problem with using an interface. I would, really, like to see what they are. Jack On Wed, 16 Mar 2005 21:29:56 +0100, Manfred Wolff <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: > > >(Of course, you can do this now, just by using a standard Action to > >call an Execu

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

Good point about the original RP still being present and usable... but, I would assume (although I can't say with any authority) that there are significant changes (not functional) besides the RP piece, would that be accurate? If so, my point I still feel is valid, although perhaps diminished a bi

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

I'm not sure how this is different from what I am proposing? I'm also not sure you are saying that it is. On Wed, 16 Mar 2005 17:09:29 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > The issue is that some properties on an arbitrary object might be OK > to populate from the request, and others mi

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

The issue is that some properties on an arbitrary object might be OK to populate from the request, and others might not be. The securityissue is that it's not only the properties on the object itself, but properties on objects that the object might reference. As Martin mentioned, once upon a time,

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 10:08:15 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > On Wed, 16 Mar 2005 09:54:48 -0800, Craig McClanahan <[EMAIL PROTECTED]> > wrote: > > I agree with Ted, and the reasoning he states. Indeed, in this > > particular respect, Action *should* be inflexible because making

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 15:53:35 -0600, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > > > > I understand what you're suggesting, and on the face of it, it seems > > like a nice idea. However, I fear that including such a mechanism in > > Struts would lead to serious security vulnerabilities in some pe

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

[snip] > As long as that is the case, the only > argument for a 2.x version number that makes any sense would be > marketing related (get some attention with a major new version number > to hide the fact that it's pretty much the same as before when you > look at it from the outside). Struts 2005

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, 16 Mar 2005 16:48:39 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > Good point about the original RP still being present and usable... but, I > would assume (although I can't say with any authority) that there are > significant changes (not functional) besides the RP piece,

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

> > I understand what you're suggesting, and on the face of it, it seems > like a nice idea. However, I fear that including such a mechanism in > Struts would lead to serious security vulnerabilities in some peoples' > applications. This is because essentially *any* method on the POJO > could end

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, March 16, 2005 4:36 pm, Niall Pemberton said: >> You know, I didn't think so before, but maybe I am in fact proposing a >> fork. Maybe there is enough difference between the 1.2 branch and the >> 1.3 >> branch (and more importantly, where the 1.3 branch is going) that an >> actual fork is

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

- Original Message - From: "Frank W. Zammetti" <[EMAIL PROTECTED]> Sent: Wednesday, March 16, 2005 9:14 PM > It seems like there is a bit of denial going on here... I view 1.3 as not > a minor upgrade but a major one because a significant amount of code has > changed. There is a load

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 14:27:02 -0600, Michael Rasmussen <[EMAIL PROTECTED]> wrote: > This may have been proposed long ago I don't know, but I will throw it > out there as it just popped into my head. > > I agree with those of you who are against POJO's, but I had a thought: > > Since Action is used

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, March 16, 2005 3:20 pm, Martin Cooper said: > Upgrading from 1.2.6 to 1.2.7, 1.2.8, etc. is still upgrading. If the > people that make decisions don't let you upgrade, then you're already > stuck. Unless, that is, upgrading to a new dot-dot release is OK, but > a dot release is not. However

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Ted Husted wrote: (Of course, you can do this now, just by using a standard Action to call an Execute method on your subclass of ActionForm.) I don't know the exactly english word: Iwill taper a bit (zu deutsch zuspitzen :-) Most of real struts project do such things. They extend the Action to

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

This may have been proposed long ago I don't know, but I will throw it out there as it just popped into my head. I agree with those of you who are against POJO's, but I had a thought: Since Action is used mostly to populate a VO from the Form Bean and then delegate to some business logic facade (

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, 16 Mar 2005 13:22:05 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Similar thinking anyway Jack :) You tend to use a lot of big words that > my primitive brain can't handle mid-week :) but otherwise... > > My point simply boils down to this... > > Anyone that CAN upgrade to

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

This is all good, Ted, and no doubt at all true. But.. There are lots of differences in the openess of the process to new voices that are consistent with everything you have said. And, there are lots of differences in how free individuals with the time are to change things as the

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 14:08:58 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Wed, 16 Mar 2005 15:41:45 -, .. > The teams with which I've met want a web framework to harvest input > values and render output values, so that their business classes can > focus on turning input into

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 14:08:37 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > I wouldn't have a problem with an interface for Actions or ActionForms > at this point in time. Most people will continue to use (or abuse) the > base classes anyway. Of course, by "point in time" I didn't mean the 1.3.0 t

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 15:41:45 -, Niall Pemberton > Having a concrete Action (or ActionForm) doesn't prevent people from using > Struts badly and I don't buy the argument that we shouldn't make the > famework flexible in case people burn themselves. Having flexibilty would > allow people to inova

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 12:47:51 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > >I agree with Ted, and the reasoning he states. Indeed, in this > >particular respect, Action *should* be inflexible because making it an > >interface would encourage you to use it incorrectly. > > I disagree. Actions

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, March 16, 2005 1:47 pm, Joe Germuska said: > I disagree. Actions are not fine the way they are. They depend too > directly on the Servlet API, which is one of the reasons they are too > hard to unit test. I agree with that first part, however, I find the unit test point interesting (not

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

At 9:54 AM -0800 3/16/05, Craig McClanahan wrote: On Wed, 16 Mar 2005 04:33:12 -0800 (PST), Konstantin Priblouda <[EMAIL PROTECTED]> wrote: --- Ted Husted <[EMAIL PROTECTED]> wrote: > IMHO, Actions are fine the way they are. The one and > only problem is > that people keep trying to use Actions

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

It's those of us that CAN'T upgrade, and maybe won't be able to for a while, that concerns me. And there are those that simply DON'T want to upgrade too. If there are those of us willing to keep 1.2 alive and developing, assuming we do so with forward-compatibility in mind, I can't see why there

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

As far as the contributions goes, I just don't know of any other way to do it in a volunteer environment. It's great to have a good idea, but until someone steps up with the code, it's just that, an idea. On a team, I can compel someone to implement something I think is a good idea, because I con

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, 16 Mar 2005 13:22:05 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > It's those of us that CAN'T upgrade, and maybe won't be able to for a > while, that concerns me. And there are those that simply DON'T want to > upgrade too. If there are those of us willing to keep 1.2 alive

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

If someone were able to make a case for changing the DTD, and were willing to be the release manager, and were willing to handle the support inquiries, and had demonstrated that they were as good as their word, then there is unlikely to be a problem. The other thing to keep in mind is that anythin

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

+1. I coach several struts projects in big companies is germany, and they also all uses 1.1 and there is no way to change to 1.2 or 1.3. So I'm interested in adding new things with backward compatibility! I think the new concepts of 1.3 are good and I will try them out, but in production state

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

Similar thinking anyway Jack :) You tend to use a lot of big words that my primitive brain can't handle mid-week :) but otherwise... My point simply boils down to this... Anyone that CAN upgrade to 1.3 will probably do so, and likely won't notice any difference, at least as 1.3 stands now as far

svn commit: r157782 - in struts/taglib/trunk/src/webapp/org/apache/struts/taglib: bean/TestIncludeTag.jsp bean/TestResourceTag.jsp bean/TestStrutsTag.jsp html/TestBaseTag.jsp html/TestFormTag1.jsp html/TestImageTag5.jsp html/TestImageTag6.jsp

Author: jmitchell Date: Wed Mar 16 10:15:09 2005 New Revision: 157782 URL: http://svn.apache.org/viewcvs?view=rev&rev=157782 Log: fix local ref since JSPs were moved from /test/test/org/* to /org/* Modified: struts/taglib/trunk/src/webapp/org/apache/struts/taglib/bean/TestIncludeTag.jsp

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

If Frank is thinking the way I am, there is a real worry that what was an idea to use Chain of Responsibility on top of Template Method to make a composable request processor to make Struts more flexible, an idea that probably will have to be significantly refactored after testing, is getting to lo

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 09:54:48 -0800, Craig McClanahan <[EMAIL PROTECTED]> wrote: > I agree with Ted, and the reasoning he states. Indeed, in this > particular respect, Action *should* be inflexible because making it an > interface would encourage you to use it incorrectly. How is an interface wi

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, March 16, 2005 12:53 pm, Niall Pemberton said: > What I don't understand is if 1.3 is compatible with 1.2 then why are you > happy to move to a new 1.2.x release, but not a new 1.3 release? The only > reason I can think of is if someone has customized the the 1.2 > RequestProcessor? What I

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 04:33:12 -0800 (PST), Konstantin Priblouda <[EMAIL PROTECTED]> wrote: > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > > IMHO, Actions are fine the way they are. The one and > > only problem is > > that people keep trying to use Actions (and Struts) > > as a component of > >

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

- Original Message - From: "Frank W. Zammetti" <[EMAIL PROTECTED]> Sent: Wednesday, March 16, 2005 5:32 PM > But if there are others that still want or need to use 1.2, and there are > some that are willing to tackle some of that work, wouldn't there be > support for that (keeping compati

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 09:58:37 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 7:38 AM -0800 3/16/05, Konstantin Priblouda wrote: > >--- Joe Germuska <[EMAIL PROTECTED]> wrote: > I was just asking Jack what he > meant when he wrote > " I definitly don't think that this is a good idea." and "Thi

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

On Wed, March 16, 2005 12:07 pm, Niall Pemberton said: > I haven't looked at your actual implementation, but my gut feel is that we > need to be careful about adding new elements to the struts-config.xml - > the > simpler the better IMO. Maybe there are alternative mechanisms that > achieve > the s

Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]

To me, Joe's ExecuteForwardCommand, coupled with the catalog/command attributes for action mappings, already do what Frank's setupItem aims to do. Per-forward prep can be done with per-forward commands or chains, and there are per-action equivalents as well. Hubert On Wed, 16 Mar 2005 17:07:42

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

I don't have any issue with actually providing implementations like this, although that wasn't my line of thinking. I was thinking more of changing method signatures in things like ActionContext to use Objects rather than the concrete class. So for example in ActionContext...replacing void setActio

Page Preparation [was Re: POJO Actions and the ActionCommand interface]

I haven't looked at your actual implementation, but my gut feel is that we need to be careful about adding new elements to the struts-config.xml - the simpler the better IMO. Maybe there are alternative mechanisms that achieve the same goal. Martin suggested ChainAction in that thread (for Struts 1

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

- Original Message - From: "Joe Germuska" <[EMAIL PROTECTED]> Sent: Wednesday, March 16, 2005 3:58 PM > At 3:41 PM + 3/16/05, Niall Pemberton wrote: > >OK, "POJO Actions" is a bad example. > > perhaps, but I think having that in the subject line helped stir up > all this discussion ;

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

At 10:29 AM -0500 3/16/05, Ted Husted wrote: On Wed, 16 Mar 2005 08:02:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: So, if I have a way to get my own ActionContext into my actions, then I'm less concerned about the current mechanism for specifying a custom ActionContext. I'd want to hear m

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Ok Niall, you caught me... I was being a bit of a wise-ass. :) And you are right, the feeback was centered around it not being targeted at 1.3. I don't want to hijack this thread, but... That kind of begs the question... if I were to implement what I did in 1.3, would there then be interest from

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Sorry frank I had only half an eye on that thread when it was happening. Wasn't the comments you got back that it was targeted at Struts 1.2 rather than the current 1.3 development version. I didn't think it was criticised for flexibilty, just that any solution to this kind of issue needs to be 1.3

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

At 7:38 AM -0800 3/16/05, Konstantin Priblouda wrote: --- Joe Germuska <[EMAIL PROTECTED]> wrote: > What is your antecedent for "this"? Having an ActionCommand interface? Using an IoC container as an ActionFactory? Having a ThreadLocal store the current ActionContext? action factory going

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

If we are saying that maximum flexibility in Struts is a good thing, may I suggest re-opening my submitted patch for setupItems? If flexibility is the goal (something I generally agree and have argued for in the past), isn't my work very much a move in that direction? -- Frank W. Zammetti Founde

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

From: "Ted Husted" <[EMAIL PROTECTED]> > My feeling is that POJO Actions might encourage people to couch their > business logic as POJO actions :) > > It's unlikely that such a class could be a true POJO. It would have to > be bound to Struts in some way. Otherwise, the Action would not > produce a

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

--- Joe Germuska <[EMAIL PROTECTED]> wrote: > > What is your antecedent for "this"? Having an > ActionCommand > interface? Using an IoC container as an > ActionFactory? Having a > ThreadLocal store the current ActionContext? action factory going to IoC container for actions exists already

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

At 7:07 AM -0800 3/16/05, Dakota Jack wrote: This is where the present options (making the request processor composable and providing a basis for business logic) goes "nuts" and begins to toss the entire idea of Struts out the window. I definitly don't think that this is a good idea. This is a hug

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 08:02:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > So, if I have a way to get my own ActionContext into my actions, then > I'm less concerned about the current mechanism for specifying a > custom ActionContext. I'd want to hear more on the > ActionContextFactory threads

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

This is where the present options (making the request processor composable and providing a basis for business logic) goes "nuts" and begins to toss the entire idea of Struts out the window. I definitly don't think that this is a good idea. This is a huge move which has nothing to do with the comp

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Yes. On Wed, 16 Mar 2005 09:59:36 -0500 (EST), Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Wed, March 16, 2005 9:56 am, Dakota Jack said: > > > I like to think > > of calling objects/classes/interfaces as more like a very organized > > "go to" command in procedural processing. > > > You

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, March 16, 2005 9:56 am, Dakota Jack said: > I like to think > of calling objects/classes/interfaces as more like a very organized > "go to" command in procedural processing. You of course mean Gosub, right?!? :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technolo

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 08:01:41 -0500, Ted Husted <[EMAIL PROTECTED]> wrote: > On Tue, 15 Mar 2005 20:22:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > > The idea, I thought, was to use the Commands to supplant the > > RequestProcessor with a composable request processor. > Refactoring the Reques

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Wed, 16 Mar 2005 04:33:12 -0800 (PST), Konstantin Priblouda <[EMAIL PROTECTED]> wrote: > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > > IMHO, Actions are fine the way they are. The one and > > only problem is > > that people keep trying to use Actions (and Struts) > > as a component of > >

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

These are, of course, huge questions. And, I definitely agree with Ted on the POJO business. We need to remember, I think, that Actions are part of the framework, not part of applications. Unfortunately, too often the team builds functionality that should be part of applications and insinuates i

[Apache Struts Wiki] Updated: StrutsTools

Date: 2005-03-16T06:10:25 Editor: AndersonTeixeira Wiki: Apache Struts Wiki Page: StrutsTools URL: http://wiki.apache.org/struts/StrutsTools no comment Change Log: -- @@ -9,6 +9,8 @@ http://www.cotse

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Alright! Well, I succeeded in generating some discussion, which is fantastic -- thanks to everyone who weighed in. At 8:48 PM -0800 3/15/05, Martin Cooper wrote: I'm not sure I see the reasoning / benefit of POJOs as Actions. Well, here's my specific case. As we design this new application, I

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

On Tue, 15 Mar 2005 20:22:34 -0800, Dakota Jack <[EMAIL PROTECTED]> wrote: > The idea, I thought, was to use the Commands to supplant the > RequestProcessor with a composable request processor. In Struts 1.0, requests were processed using a lump of code in ActionServlet. To keep it organized, th

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

--- Ted Husted <[EMAIL PROTECTED]> wrote: > IMHO, Actions are fine the way they are. The one and > only problem is > that people keep trying to use Actions (and Struts) > as a component of > a business logic framework, rather than as an > *adjunct* to a business > logic framework. I'd like to di

RE: Struts/HTTPS

My apology. I did not know that I should route such questions to struts userlist -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 16, 2005 5:42 PM To: Struts Developers List; [EMAIL PROTECTED] Subject: Re: Struts/HTTPS Rajeneesh, why do you keep as

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

I would tend to agree with Martin. My feeling is that POJO Actions might encourage people to couch their business logic as POJO actions :) It's unlikely that such a class could be a true POJO. It would have to be bound to Struts in some way. Otherwise, the Action would not produce a result that w

Re: Struts/HTTPS

Rajeneesh, why do you keep asking random questions that are easily answered by looking at the Struts web site or Google? Besides, you are posting to the wrong list. Please these kinds of questions on the Users list. -- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 6

DO NOT REPLY [Bug 34032] New: - Buggy compile target in struts-blank's build.xml

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affect

[EMAIL PROTECTED]: Project struts-taglib (in module struts) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project struts-taglib has an issue affecting its community integration. This issue affect

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

+42 On Wed, 16 Mar 2005 09:23:29 +0100, Manfred Wolff <[EMAIL PROTECTED]> wrote: > Dakota Jack wrote: > > >The idea, I thought, was to use the Commands to supplant the > >RequestProcessor with a composable request processor. Some of the > >present suggestions are so radical as to provide some q

Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)

Dakota Jack wrote: The idea, I thought, was to use the Commands to supplant the RequestProcessor with a composable request processor. Some of the present suggestions are so radical as to provide some question whether Struts is going to be Struts. This is especially so of the suggestion that we ti