You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2005/03/16 18:32:27 UTC
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 same goal. Martin suggested ChainAction in that thread (for Struts
> 1.3) - another, Struts 1.2, option would be to use a Tiles Controller.
I did look in to at least some of the suggestions. None of them I felt
achieved the same result, they all missed one point or another (and to be
fair, some may have had additional benefits over what I proposed).
I do see your point about expanding the config DTD, it is something to be
careful of certainly. But, if what is done to it only *adds* to it, while
being cautious is still good of course, I think its something that should
be considered.
> At the end of the day its a bit chicken and egg as far as contributions
> and
> committers go. If you post an idea, people say "code talks" - if you go to
> the trouble of doing the code (as you did), its disheartening to get
> either
> no reaction or a -ve one.
Glad I'm not the only one that noticed that :)
It's all a bit contradictory really (not as a fault of anyone though)... I
very much want to contribute, and of course I can always go through the
bug database and fix stuff, but as is the nature of community development,
if that doesn't scratch my itch, as the saying goes, there's no motivation
to do so. This particular task did scratch an itch, and so I put in the
effort, and then you get into what you said above.
If anyone reading this is thinking I'm just being bitter and bitching,
that is not the case. I am simply trying to see if there is a way to
salvage the idea I had, go somewhere acceptable to all with it, in a
fashion that scratches my itch (ok, I am *officially* SICK of that
expression!!)
> Its a bit hit and miss whether you're going to
> find anyone with either the desire or time to plug in what you produce
> (I've
> had very little over the last few months).
Time is of course a rare commodity for most of us I'd suspect, I
completely understand that.
> Back porting to 1.2 is more
> effort so the same goes. Personally, once I switch over to 1.3 the
> motivation for me to duplicate work on 1.2 will not be that high.
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 compatibility in mind of course, I think that's
a perfectly valid concern)? I mean, let's be honest, there's probably not
a whole lot coming down the pipe that can and/or could be back-ported, but
if something comes up, at least until enough of the community has moved to
1.3, and there are people willing to do it, why not support that effort?
I just hate the thought that because the Struts team themselves are all
ready to move to 1.3, that the rest of us have to if we want to get the
new features (I'm ignoring the possibility of hacking the framework
ourselves because that simply isn't allowed in some environments, mine for
example). I have no problem if you guys don't have the time or the desire
to work on anything but 1.3, but if some of us do, why not support that?
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Sean Schofield <se...@gmail.com>.
[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
(kidding)
;-)
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Dakota Jack <da...@gmail.com>.
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 they will.
Not disagreeing at all. Just saying that there is a lot more to the picture.
Jack
On Wed, 16 Mar 2005 13:44:24 -0500, Ted Husted <te...@gmail.com> wrote:
> 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 control their paycheck. Here, we can't compel
> anyone to do anything.
>
> Likewise, if I have one developer do something, and the work is poor,
> I can compel another developer to fix it. Here, if someone badly
> implements a good idea, we can't compel anyone to fix it. If no one
> volunteers, it doesn't get done.
>
> Because it's a volunteer project, we can only vote on what's in front
> of us now. We can discuss how we feel about ideas, but absolutely
> nothing counts for anything until it gets committed to the repository.
>
> And it's the same for everyone. We put the committers through the same
> gauntlet as new contributors, for all the same reasons. Any one of us
> could disappear tomorrow, and the rest of us would be left holding the
> bag. We all need to agree to everything, because we are all
> responsible for everything.
>
> Is there any organization around here? Yep -- all for one, one for all. :)
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Ted Husted <te...@gmail.com>.
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 control their paycheck. Here, we can't compel
anyone to do anything.
Likewise, if I have one developer do something, and the work is poor,
I can compel another developer to fix it. Here, if someone badly
implements a good idea, we can't compel anyone to fix it. If no one
volunteers, it doesn't get done.
Because it's a volunteer project, we can only vote on what's in front
of us now. We can discuss how we feel about ideas, but absolutely
nothing counts for anything until it gets committed to the repository.
And it's the same for everyone. We put the committers through the same
gauntlet as new contributors, for all the same reasons. Any one of us
could disappear tomorrow, and the rest of us would be left holding the
bag. We all need to agree to everything, because we are all
responsible for everything.
Is there any organization around here? Yep -- all for one, one for all. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Dakota Jack <da...@gmail.com>.
<SNIP>
On Wed, 16 Mar 2005 13:55:39 -0800, Craig McClanahan <cr...@gmail.com> 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 much the same as before when you
> look at it from the outside).
>
> Craig
</SNIP>
Ah, yes! That open source market niche being saved for JSF! ///;-)
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 use Sruts 1.2.x applications with Struts 1.3.x with zero
> code changes. There is no compelling reason to bump the major version
> number, so let's not bother. The bandwidth can be put to better uses.
>
> -Ted.
>
> On Wed, 16 Mar 2005 17:57:00 -0500, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>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 because I think
>>the case is even clearer.
>>
>>Be that as it may, clearly it is too late to care about that decision,
>>but I would argue that it's not too late for the next release. I would
>>contend that the fundamental nature of the change to a CoR pattern
>>warrants the major version bump. I think it needs to be made more clear
>>that the next version really is a big change.
>>
>>The fact that you can still use the "classic" RP, while cool, doesn't
>>really change my opinion because the default, and more importantly *what
>>is being recommended as the next best practice* is changing. Therefore,
>>for all intents and purposes, the ability to switch to the classic RP
>>doesn't change anything (although it's neat!)
>>
>>It's kind of like the change from Windows 2000 to Windows XP (not quite,
>>but work with me here :))... I can set up a WinXP box that looks just
>>like a Win2K box, and accept for some added functionality, works
>>essentially the same. But clearly there were some changes throughout
>>that fundamentally changed the way some things worked under the covers,
>>*but not in a visible way*. Would any of us have agree with Microsoft
>>calling it Windows 2000 v1.1?
>>
>>Like I said, not a perfect analogy, but I trust you get the point :)
>>
>>Frank
>
>
>
>
>
--
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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Ted Husted <te...@gmail.com>.
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 with Struts 1.3.x with zero
code changes. There is no compelling reason to bump the major version
number, so let's not bother. The bandwidth can be put to better uses.
-Ted.
On Wed, 16 Mar 2005 17:57:00 -0500, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> 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 because I think
> the case is even clearer.
>
> Be that as it may, clearly it is too late to care about that decision,
> but I would argue that it's not too late for the next release. I would
> contend that the fundamental nature of the change to a CoR pattern
> warrants the major version bump. I think it needs to be made more clear
> that the next version really is a big change.
>
> The fact that you can still use the "classic" RP, while cool, doesn't
> really change my opinion because the default, and more importantly *what
> is being recommended as the next best practice* is changing. Therefore,
> for all intents and purposes, the ability to switch to the classic RP
> doesn't change anything (although it's neat!)
>
> It's kind of like the change from Windows 2000 to Windows XP (not quite,
> but work with me here :))... I can set up a WinXP box that looks just
> like a Win2K box, and accept for some added functionality, works
> essentially the same. But clearly there were some changes throughout
> that fundamentally changed the way some things worked under the covers,
> *but not in a visible way*. Would any of us have agree with Microsoft
> calling it Windows 2000 v1.1?
>
> Like I said, not a perfect analogy, but I trust you get the point :)
>
> Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 because I think
the case is even clearer.
Be that as it may, clearly it is too late to care about that decision,
but I would argue that it's not too late for the next release. I would
contend that the fundamental nature of the change to a CoR pattern
warrants the major version bump. I think it needs to be made more clear
that the next version really is a big change.
The fact that you can still use the "classic" RP, while cool, doesn't
really change my opinion because the default, and more importantly *what
is being recommended as the next best practice* is changing. Therefore,
for all intents and purposes, the ability to switch to the classic RP
doesn't change anything (although it's neat!)
It's kind of like the change from Windows 2000 to Windows XP (not quite,
but work with me here :))... I can set up a WinXP box that looks just
like a Win2K box, and accept for some added functionality, works
essentially the same. But clearly there were some changes throughout
that fundamentally changed the way some things worked under the covers,
*but not in a visible way*. Would any of us have agree with Microsoft
calling it Windows 2000 v1.1?
Like I said, not a perfect analogy, but I trust you get the point :)
Frank
Craig McClanahan wrote:
> On Wed, 16 Mar 2005 16:48:39 -0500 (EST), Frank W. Zammetti
> <fz...@omnytex.com> 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, would that be
>>accurate? If so, my point I still feel is valid, although perhaps
>>diminished a bit :)
>>
>
>
> Historical perspective ... the changes from 1.0 to 1.1 were MUCH more
> impactful on the typical application (RequestProcessor was refactored
> out of ActionServlet) than the current delta between 1.2 and 1.3, but
> we were fine with staying 1.x because it was fundamentally backwards
> compatible for typical use cases, but we also added a bunch of new
> features (ike sub-app modules). 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).
>
>
>
>>Frank
>
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
--
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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 16 Mar 2005 16:48:39 -0500 (EST), Frank W. Zammetti
<fz...@omnytex.com> 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, would that be
> accurate? If so, my point I still feel is valid, although perhaps
> diminished a bit :)
>
Historical perspective ... the changes from 1.0 to 1.1 were MUCH more
impactful on the typical application (RequestProcessor was refactored
out of ActionServlet) than the current delta between 1.2 and 1.3, but
we were fine with staying 1.x because it was fundamentally backwards
compatible for typical use cases, but we also added a bunch of new
features (ike sub-app modules). 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).
> Frank
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by Joe Germuska <Jo...@Germuska.com>.
>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 bit :)
That's a good question. It deserves more clear documentation, but
the per-action and per-forward command processing will not work with
the base RequestProcessor. While it is logically plausible to add
lookup processes in the base RequestProcessor, there remains the
question of how the ActionContext would be instantiated. It would be
easy enough to push the contextInstance() method up to the base
RequestProcessor, but it might leave unclear some semantics: would
the base RequestProcessor pay attention to any values added to the
context by chain commands? Commands could make changes to the
request and the session, but if, for example, they set the context's
forwardConfig property, I'm not sure it's clear whether (or how) the
base request processor should pay attention to that.
Besides those, I can't think of any new-in-Struts-1.3 functionality
which wouldn't work as well if you told Struts to use the original
RequestProcessor instead of the ComposableRequestProcessor -- if we
went ahead with changes to the Action interface, this might be harder
to promise, so that's probably a good baseline rule for not making
that change yet.
(To be honest, I can't think of any other new-in-Struts-1.3
functionality, except for the arbitrary properties on ForwardConfig.
Most of the other work has been on the repository.)
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 in fact warranted.
> </snip>
>
> If the original RequestProcessor stays in Struts then is there a need to
> fork. Back porting changes between branches and releasing versions from
> different branches, IMO is a pain - maintaining two RequestProcessors in
> the
> current branch not such a big deal.
Agreed on the pain of maintaing two branches. I had to do that for a
while on one app here, and I was in complete control and it was still a
pain.
But, if there was support for such a thing (and I have no illusions about
this: I don't believe there is any) then clearly a division of labor would
help alleviate the difficulty.
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 bit :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
Sent: Wednesday, March 16, 2005 9:14 PM
<snip>
> 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.
</snip>
There is a load of new code in 1.3, but the original RequestProcessor still
exists and I'm presuming, with a small amount of extra config (since the
default will be ComposableRequestProcessor) will work as before. I've yet to
test this out, but so far no-ones proposed doing away with it(?).
<snip>
> 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 in fact warranted.
</snip>
If the original RequestProcessor stays in Struts then is there a need to
fork. Back porting changes between branches and releasing versions from
different branches, IMO is a pain - maintaining two RequestProcessors in the
current branch not such a big deal.
> Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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, if that *is* the case, it is probably
> based on the understanding that dot-dot releases are bug fix releases,
> which is what the entire software industry, at least as I know it,
> uses them to mean.
An argument can be made that the Struts versions are already misused. 1.3
should in fact be 2.0 in my opinion (or 3.0, if the delta was large enough
between 1.1 and 1.2.4 so that 1.2.4 should have been 2.0, but I don't
remember the differences well enough to say).
Sure, you can say that the functionality in 1.3 as far as the public
contracts go hasn't changed (i.e., remains compatible at an
appliction-level) and therefore does not justify a major version bump, but
it is hard to argue that the code base hasn't changed enough to warrant
it, and in that regard a business would be better served deciding between
a 2.x version and a 3.0 version because it more clearly indicates the
degree of change. The bottom line: versioning isn't soley limited to what
FUNCTIONALITY has chaged, but how much CODE has changed. You are doing
something that is core to Struts in a fundamentally different way, and
that carries a higher degree of risk than mearly bug fixes.
I also think your interpretation of dot-dot releases is open to debate...
Some people do indeed think that a 1.0 and a 1.1 version of something
should only differ in being bug fixes, while others feel it should
represent only internal changes *or* additions of functionality, both of
which are relatively minor (a subjective measure).
> You seem to want to inject new functionality into a
> dot-dot release to delibrately mislead the decision makers into
> allowing you to upgade and get that new functionality while they think
> you're only getting bug fixes. Or am I misunderstanding?
You are misunderstanding... This is not me trying to make an end-run
around some decision makers.
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. This carries with it some risk. What you seem to be saying is
that there is a risk moving from 1.2.4 to 1.2.6 for example, but a minor
one, and there is a risk moving from 1.2.6 to 1.3, and even though it is a
much larger risk (based on the amount of code changes), I should be
willing to incur that major risk if I am willing to incur the minor risk
in the first place.
What I have been saying all along is that some people will not want to go
along with that risk. Others may simply not like the direction you guys
are taking Struts. A year from now, when 1.3 has been shown to be stable,
I doubt anyone will have a problem jumping from 1.2.6 to 1.3 (assuming
risk was the deciding factor and not just personal preference), but maybe
not right away.
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 in fact warranted. That wasn't what I started out saying,
but I'm not so sure any more it isn't what I subconsciously meant.
> Perhaps we should just call the current trunk 1.2.7? If you think it's
> OK to add significant new functionality into a dot-dot release, why
> would we change the dot version for what is in trunk now? What
> distinguishes one dot release from another of dot-dot releases can
> also include significant new functionality?
Again, I believe the version numbers are not being used correctly. I
can't speak to what the current version should be, but I do know what the
next version should be basde on what we have now: 2.0.
>From there on, 2.x represents versions with new or changed features, and
2.x.x represents versions with JUST bug fixes.
That is the standard I have seen followed far more frankly. But the more
cogent point is the major version bump.
The other issue is simply what to do with the current branch. I don't for
one second disagree that letting it wither and die (as far as feature
changes go) is standard practice. That does not make it the best answer
though. Like I said, maybe I'm really talking about an incompatible
branch. I don't really like that idea, but I like being essentially
forced to 1.3 even less.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 16 Mar 2005 13:22:05 -0500 (EST), Frank W. Zammetti
<fz...@omnytex.com> 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 1.3 will probably do so, and likely won't
> notice any difference, at least as 1.3 stands now as far as I know it...
> some of the discussions yesterday and today could change that, but
> assuming not, then this is probably true.
>
> 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 wouldn't be support for this.
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, if that *is* the case, it is probably
based on the understanding that dot-dot releases are bug fix releases,
which is what the entire software industry, at least as I know it,
uses them to mean. You seem to want to inject new functionality into a
dot-dot release to delibrately mislead the decision makers into
allowing you to upgade and get that new functionality while they think
you're only getting bug fixes. Or am I misunderstanding?
> And also note I'm not saying anyone should support 1.1 or prior, but I do
> feel that supporting and expanding the latest and greatest in 1.3, AS WELL
> AS the *immediate predecessor* 1.2 version, keeps more people happy than
> does just building on 1.3. If the struts committers only want to focus
> their own time on 1.3, that's cool, I understand that, but if someone else
> is willing to do what they are not, why not support the effort?
Perhaps we should just call the current trunk 1.2.7? If you think it's
OK to add significant new functionality into a dot-dot release, why
would we change the dot version for what is in trunk now? What
distinguishes one dot release from another of dot-dot releases can
also include significant new functionality?
--
Martin Cooper
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Wed, March 16, 2005 1:12 pm, Dakota Jack said:
> > 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 look like a jacket that will be placed in a lot
> > of areas of Struts prior to refactoring, etc. and leading to rigidity
> > in a different direction. Thus, in order to avoid having to go to a
> > different world view and leaving open the extension of the present
> > one, many of us are beginning to hang on to copies of 1.2 as the
> > potential basis for the future at this point.
> >
> > Jack
> >
> >
> > On Wed, 16 Mar 2005 17:53:52 -0000, Niall Pemberton
> > <ni...@blueyonder.co.uk> wrote:
> >> ----- Original Message -----
> >> From: "Frank W. Zammetti" <fz...@omnytex.com>
> >> 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 compatibility in mind of course, I think
> >> that's
> >> > a perfectly valid concern)? I mean, let's be honest, there's probably
> >> not
> >> > a whole lot coming down the pipe that can and/or could be back-ported,
> >> but
> >> > if something comes up, at least until enough of the community has
> >> moved to
> >> > 1.3, and there are people willing to do it, why not support that
> >> effort?
> >>
> >> 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'm supporting is all running under v1.2
> >> currently
> >> and I'm expecting upgrading to v1.3 to not be a big deal.
> >>
> >> Niall
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-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: 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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Ted Husted <te...@gmail.com>.
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 anything anyone puts into the
codebase is something that all of us are going to have to support in
the future. We are commited to backward compatibility, so once it goes
in, it can take a very long time to get it back out again. (Witness
DataSoruces.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Hubert Rabago <hr...@gmail.com>.
On Wed, 16 Mar 2005 13:22:05 -0500 (EST), Frank W. Zammetti
<fz...@omnytex.com> 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 and
> developing, assuming we do so with forward-compatibility in mind, I can't
> see why there wouldn't be support for this.
>
I've thought about this to some extent already, focusing on page prep
functionality. The 1.3 approach to this adds DTD attributes and
allows a chain to do the work. Doing this in 1.2 feels awkward. Use
a struts class to respond to a request, then require a commons-chain
command to do page prep?
Some functionality are better suited for back porting, such as
configuration inheritance. Page prep, the way 1.3 implements it,
doesn't feel like it. To me, page prep functionality that's forward
compatible and still feels like a 1.2 struts solution is still a
custom ForwardConfig.
Hubert
>
> --
> 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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by Joe Germuska <Jo...@Germuska.com>.
>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 wouldn't be support for this.
What I'd like to avoid introducing to the core is multiple ways to
achieve the same goals. If we added the setup actions to Struts 1.2,
they would necessarily need to be in Struts 1.3, and in 1.3, there is
already a good way to achieve the same goals.
I also fail to see how introducing and immediately using the setup
actions is any less bleeding edge than moving to Struts 1.3; are your
architects making these decisions really paying so little attention
as to say "hm; version number's OK -- go for it!" ?
I promise to answer questions until kingdom come about ways to build
the setup action concept as an optional pluggable library for Struts
1.2 and to consider making changes to Struts 1.2 that improve its
ability to have a library like this plugged in. It doesn't diminish
the usability of the tools any to not have them integrated into the
Struts core, and lots of people are out there happily using non-core
extensions to Struts 1.2.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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 as I know it...
some of the discussions yesterday and today could change that, but
assuming not, then this is probably true.
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 wouldn't be support for this.
And also note I'm not saying anyone should support 1.1 or prior, but I do
feel that supporting and expanding the latest and greatest in 1.3, AS WELL
AS the *immediate predecessor* 1.2 version, keeps more people happy than
does just building on 1.3. If the struts committers only want to focus
their own time on 1.3, that's cool, I understand that, but if someone else
is willing to do what they are not, why not support the effort?
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Wed, March 16, 2005 1:12 pm, Dakota Jack said:
> 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 look like a jacket that will be placed in a lot
> of areas of Struts prior to refactoring, etc. and leading to rigidity
> in a different direction. Thus, in order to avoid having to go to a
> different world view and leaving open the extension of the present
> one, many of us are beginning to hang on to copies of 1.2 as the
> potential basis for the future at this point.
>
> Jack
>
>
> On Wed, 16 Mar 2005 17:53:52 -0000, Niall Pemberton
> <ni...@blueyonder.co.uk> wrote:
>> ----- Original Message -----
>> From: "Frank W. Zammetti" <fz...@omnytex.com>
>> 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 compatibility in mind of course, I think
>> that's
>> > a perfectly valid concern)? I mean, let's be honest, there's probably
>> not
>> > a whole lot coming down the pipe that can and/or could be back-ported,
>> but
>> > if something comes up, at least until enough of the community has
>> moved to
>> > 1.3, and there are people willing to do it, why not support that
>> effort?
>>
>> 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'm supporting is all running under v1.2
>> currently
>> and I'm expecting upgrading to v1.3 to not be a big deal.
>>
>> Niall
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-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: 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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Dakota Jack <da...@gmail.com>.
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 look like a jacket that will be placed in a lot
of areas of Struts prior to refactoring, etc. and leading to rigidity
in a different direction. Thus, in order to avoid having to go to a
different world view and leaving open the extension of the present
one, many of us are beginning to hang on to copies of 1.2 as the
potential basis for the future at this point.
Jack
On Wed, 16 Mar 2005 17:53:52 -0000, Niall Pemberton
<ni...@blueyonder.co.uk> wrote:
> ----- Original Message -----
> From: "Frank W. Zammetti" <fz...@omnytex.com>
> 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 compatibility in mind of course, I think that's
> > a perfectly valid concern)? I mean, let's be honest, there's probably not
> > a whole lot coming down the pipe that can and/or could be back-ported, but
> > if something comes up, at least until enough of the community has moved to
> > 1.3, and there are people willing to do it, why not support that effort?
>
> 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'm supporting is all running under v1.2 currently
> and I'm expecting upgrading to v1.3 to not be a big deal.
>
> Niall
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by Manfred Wolff <wo...@manfred-wolff.de>.
+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 - no way.
Manfred
Frank W. Zammetti wrote:
>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'm supporting is all running under v1.2 currently
>>and I'm expecting upgrading to v1.3 to not be a big deal.
>>
>>
>
>Becuase it's not simply about compatibility. Very simply, in many
>environment, the decision is not in the hands of a guy like me. Yes, I am
>a senior architect. Yes, I can make any number of decisions myself.
>
>But not all of them.
>
>One of them is that the company will not be on the bleeding edge with
>ANYTHING. We will instead be conservative and stick with a known solid
>version.
>
>In fact, we are currently using 1.1 in most applications I am aware of.
>We are still using Websphere 5.0.1. Most desktops are not even upgraded
>to IE6.0 yet (actually, that one may not be true, but it was just a few
>months ago). You get the point though I'm sure :)
>
>You see, *I* am ready and willing to move to 1.3 the second it comes out.
>I am not however *able* to do so, not at work at least. This isn't
>exactly an unusual mindset in large corporations by the way. Large
>corporations tend to be beurocratic and somewhat risk-averse when it comes
>to upgrades. At least, that has been my experience.
>
>I would caution anyone (including me!) from assuming their environment is
>typical or even the majority (that's not meant as an accusation to anyone,
>just a pertinent point).
>
>
>
--
===========================================
Dipl.-Inf. Manfred Wolff
Software Engineer
-------------------------------------------
http://www.manfred-wolff.de
http://www.struts-it.org
-------------------------------------------
____________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Page Preparation [was Re: POJO Actions and the ActionCommand
interface]
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
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'm supporting is all running under v1.2 currently
> and I'm expecting upgrading to v1.3 to not be a big deal.
Becuase it's not simply about compatibility. Very simply, in many
environment, the decision is not in the hands of a guy like me. Yes, I am
a senior architect. Yes, I can make any number of decisions myself.
But not all of them.
One of them is that the company will not be on the bleeding edge with
ANYTHING. We will instead be conservative and stick with a known solid
version.
In fact, we are currently using 1.1 in most applications I am aware of.
We are still using Websphere 5.0.1. Most desktops are not even upgraded
to IE6.0 yet (actually, that one may not be true, but it was just a few
months ago). You get the point though I'm sure :)
You see, *I* am ready and willing to move to 1.3 the second it comes out.
I am not however *able* to do so, not at work at least. This isn't
exactly an unusual mindset in large corporations by the way. Large
corporations tend to be beurocratic and somewhat risk-averse when it comes
to upgrades. At least, that has been my experience.
I would caution anyone (including me!) from assuming their environment is
typical or even the majority (that's not meant as an accusation to anyone,
just a pertinent point).
--
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
Re: Page Preparation [was Re: POJO Actions and the ActionCommand interface]
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
----- Original Message -----
From: "Frank W. Zammetti" <fz...@omnytex.com>
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 compatibility in mind of course, I think that's
> a perfectly valid concern)? I mean, let's be honest, there's probably not
> a whole lot coming down the pipe that can and/or could be back-ported, but
> if something comes up, at least until enough of the community has moved to
> 1.3, and there are people willing to do it, why not support that effort?
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'm supporting is all running under v1.2 currently
and I'm expecting upgrading to v1.3 to not be a big deal.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org