Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <422F729C.4020804@omnytex.com>
Date: Wed, 09 Mar 2005 17:03:08 -0500
From: "Frank W. Zammetti" <fzlists@omnytex.com>
Reply-To: fzlists@omnytex.com
Organization: Omnytex Technologies
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: setupItems posted to Bugzilla
References: 
 <17272.12.27.179.239.1110386601.squirrel@webmail.chiron.lunarpages.com>
	 <16d6c62005030909597f8dc3c1@mail.gmail.com>
	 <33935.12.27.179.239.1110392417.squirrel@webmail.chiron.lunarpages.com>
	 <16d6c620050309104254c2532a@mail.gmail.com>
	 <27363.12.27.179.239.1110395045.squirrel@webmail.chiron.lunarpages.com>
 <1d0ae8605030913245b7c9c2a@mail.gmail.com>
In-Reply-To: <1d0ae8605030913245b7c9c2a@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael Rasmussen wrote:
> Frank,
>   Maybe I am in the minority, I don't know, but I thought the whole
> point of version numbers to keep track of what features exist in a
> certain package of released code?  

By that logic, one could argue that adding a new feature to the 1.2 
branch is perfectly acceptable, even if it is never added to 1.3.

> No new work will ever be done on
> 1.1 because 1.2 is the current branch of struts.  As soon as 1.3 is
> out the door that will be the case for 1.2.  New feature development
> on every product happens in the latest branch.  Why are you surprised
> or concerned by this?  

I'm not surprised by this.  But I also don't see why that PRECLUDES new 
features in a previous version.

> If you want features that are not in the version you
> have to use, create those features and use them.  

In other words, fork off ;)

The thing is, this is open-source, which means that if there are people 
willing to do the work, NO version of something should ever die.  If I 
am willing to continue adding features to the 1.2 branch (assuming I can 
get a committer to apply it), why should we say as a blanket statement 
that "sorry, too bad, the 1.2 branch is not being supported, so go use 
1.3"?  That seems like a statement completely contrary to the idea of 
open-source and community development.

Well, the bottom-line here is that regardless of what the community may 
want, I can't do anything about it "officially" because I am not a 
committer.  That's kind of the end of the story, isn't it?  Note that I 
AM NOT saying the community wants my solution.  Certainly some do, but I 
don't presume to speak for everyone.  The Struts team in fact DOES 
though, as is their right.  If they say Chain is the answer, then it's 
the answer.  I can disagree until I'm blue in the face, but at the end 
of the day, who cares?

But let's be clear: my only real recourse is to release my own version 
of Struts, which is contrary to trying to make it better and I won't do 
that, so that's that really.  I tried, but in the end THAT doesn't 
matter either.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

> 
> On Wed, 9 Mar 2005 14:04:05 -0500 (EST), Frank W. Zammetti
> <fzlists@omnytex.com> wrote:
> 
>>All of your answers boil down to (a) use 1.2.x and add Chain yourself, or
>>(b) use 1.3.  For some shops (mine as a case in point), (b) isn't an
>>option, and won't be for a long time.  And either option forces you to use
>>Chain, which not everyone is going to be comfortable with, except in the
>>case of 1.3 where using it implicitly means using Chain and you understand
>>that going in.
>>
>>I hope I'm not coming across confrontational as that is not my intent.
>>But, if anything prior to 1.3 is now considered dead (or on life support I
>>suppose), which is how I interpret the comment about it being relegated to
>>bug fixes (it's an evolutionary dead end I think is clear), then that is
>>an interesting tidbit for all to be clear on because it means that no new
>>features will be added to anything other than 1.3.  Am I misrepresenting
>>reality with that statement? :)
>>
>>I can only make the proposals, or create my own fork, which I wouldn't do.
>> It's up to you folks to decide what gets in and what doesn't, and I
>>recognize that.  But, if you are saying that NOTHING new (nothing
>>substantial anyway) is going to be added to 1.x, that's bad news for me,
>>and probably others as well.
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>On Wed, March 9, 2005 1:42 pm, Martin Cooper said:
>>
>>>On Wed, 9 Mar 2005 13:20:17 -0500 (EST), Frank W. Zammetti
>>><fzlists@omnytex.com> wrote:
>>>
>>>>Well, a couple of points:
>>>>
>>>>(1) The idea of "page prep" or "setup functionality" seems to get asked
>>>>a
>>>>lot on the lists.  There are numerous ways to handle it or course, many
>>>>of
>>>>which were debated in the preceeding threads (I'd have to go dig through
>>>>the archives myself to reference them).  It is asked enough in fact that
>>>>a
>>>>"standard" solution built in to Struts makes a lot of sense to me, and
>>>>the
>>>>others that were involved in the discussion.  I believe this proposal is
>>>>a
>>>>very flexible implementation.  Probably not perfect, but an open-ended
>>>>way
>>>>to achieve these goals.
>>>
>>>The use of Chain will (has!) become a standard part of Struts in
>>>Struts 1.3. I'm not sure I see the need for more than one standard
>>>implementation...
>>>
>>>
>>>>(2) ChainAction... I'm not aware of it.  Is it new in 1.3?  If so, I for
>>>>one am not yet interested in using 1.3.  In fact, we're still using 1.1
>>>>here at work, so a solution for "older" Struts versions is nice.
>>>
>>>ChainAction is part of Struts Chain, which has been in the Contrib
>>>area of Struts for rather a long time now. Maybe even back as far as
>>>1.1 - I don't recall. Struts Chain is what has been merged into the
>>>main trunk for Struts 1.3. That includes the composable request
>>>processor and several chain-based actions, such as ChainAction,
>>>amongst other things. You might want to take a look.
>>>
>>>
>>>>(3) Using Commons Chain with 1.2.6 (and presumably older versions
>>>>too)...
>>>>I'm sure that works well, but not everyone likes the idea of adding any
>>>>extra dependencies they don't feel they want to to their projects.  I'd
>>>>prefer a capability similar to this be built in to Struts itself.  I'm
>>>>not
>>>>alone on this, based on the opinions of those working around me.
>>>
>>>Well, I don't see the type of thing you're proposing as part of a
>>>Struts 1.2.x release, since that's pretty much relegated to bug fixes
>>>at this point, as we push towards 1.3. Chain is already built into
>>>Struts 1.3, including the ChainAction I referred to. So the choices
>>>would appear to be Struts 1.2.x + Struts Chain or Struts 1.3 with no
>>>additional dependencies.
>>>
>>>
>>>>(4) Options.  They are good :)  This can be considered another tool in
>>>>the
>>>>toolbox.  Maybe use it, maybe don't.  Sure to be good in some cases,
>>>>probably not in others.  I'd hate to be forced to use something like
>>>>Chain
>>>>for this, I'd rather have the option (not saying you *have* to use Chain
>>>>now to accomplish this of course).  But again, the idea of a "standard"
>>>>approach is worth something I believe.
>>>
>>>Yes, I agree that a standard approach is good. I also believe that
>>>Chain is becoming the standard approach in Struts 1.3. Joe has been
>>>doing some great work on making it as well integrated and easy to use
>>>as possible, and I think it's looking great. I'd be extremely
>>>reluctant to add yet another way of doing things as a "standard" on
>>>top of that. Options *can* be good, but they can also confuse people.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>
>>>>--
>>>>Frank W. Zammetti
>>>>Founder and Chief Software Architect
>>>>Omnytex Technologies
>>>>http://www.omnytex.com
>>>>
>>>>On Wed, March 9, 2005 12:59 pm, Martin Cooper said:
>>>>
>>>>>First of all, I have to admit that I am *way* behind on any thread
>>>>>that has posts of more than about a dozen lines, and have not followed
>>>>>the threads that led to this proposal.
>>>>>
>>>>>That said, I don't understand why this is necessary. Why not just use
>>>>>ChainAction, and do this with Commands, instead of adding yet another
>>>>>mechanism to do it? In my day job, we're using Struts 1.2.6 + Struts
>>>>>Chain for this, and that's working very well for us.
>>>>>
>>>>>Please feel free to point me to a message in the archive that explains
>>>>>this, rather than repeating the explanation. I'm sure I can't be the
>>>>>first to wonder this. ;-)
>>>>>
>>>>>--
>>>>>Martin Cooper
>>>>>
>>>>>
>>>>>On Wed, 9 Mar 2005 11:43:21 -0500 (EST), Frank W. Zammetti
>>>>><fzlists@omnytex.com> wrote:
>>>>>
>>>>>>For those that expressed an interest (one or two with baited breath
>>>>
>>>>as I
>>>>
>>>>>>recall!), and even for those that didn't catch the previous threads,
>>>>
>>>>I
>>>>
>>>>>>just added a Bugzilla ticket for the initial posting of setupItems.
>>>>>>
>>>>>>In short, this is an addition to Struts (1.2.4) that allows for
>>>>>>setup-type
>>>>>>functionality to be declaratively added to action mappings and
>>>>
>>>>forwards.
>>>>
>>>>>>In other words, you can do something like the following:
>>>>>>
>>>>>><action path="/myPage"
>>>>
>>>>type="com.mycompany.myapp.action.MyPageAction">
>>>>
>>>>>>  <setupItem setupClass="com.mycompany.myapp.setups.SetupClass"
>>>>>>setupMethod="setupMethod1" />
>>>>>></action>
>>>>>>
>>>>>>This would result in SetupClass.setupMethod1() being called right
>>>>
>>>>before
>>>>
>>>>>>execute() of MyPageAction is called (it gets passed the request
>>>>
>>>>object).
>>>>
>>>>>>You can do whatever you like in this setup class, but I believe this
>>>>>>will
>>>>>>be good for things like populating dropdowns and such that need to
>>>>>>happen
>>>>>>regardless of what happens in the Action.
>>>>>>
>>>>>>You can add a setupItem to forwards as well, both global and local,
>>>>
>>>>and
>>>>
>>>>>>you can add as many as you like.  They will all be executed, in the
>>>>>>order
>>>>>>they appear.  Also, for the forwards, the setupItems listed for the
>>>>>>action
>>>>>>mapping will executed first, followed by those for the forwards
>>>>
>>>>returned
>>>>
>>>>>>by your Action only, AFTER execute() completes.
>>>>>>
>>>>>>The ticket contains a ZIP archive with a complete example webapp that
>>>>>>shows numerous example of this in a number of variants.  It also
>>>>>>includes
>>>>>>the complete source for the webapp as well as the changes made to
>>>>>>Struts.
>>>>>>Lastly, it includes an updated struts.jar that you should be able to
>>>>>>drop
>>>>>>in an existing application, updated your struts-config.xml file, and
>>>>
>>>>off
>>>>
>>>>>>you go.  Be sure to check out the readme.txt file in WEB-INF/src for
>>>>>>full
>>>>>>details if you give this a try.
>>>>>>
>>>>>>That's that.  Let's see what people think...
>>>>>>
>>>>>>--
>>>>>>Frank W. Zammetti
>>>>>>Founder and Chief Software Architect
>>>>>>Omnytex Technologies
>>>>>>http://www.omnytex.com
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
> 
> 
> 
> 


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