You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Don Brown <do...@gmail.com> on 2005/09/08 09:04:49 UTC
"Struts 1.3 and Beyond" Presentation
I just finished giving a presentation titled "Struts 1.3 and Beyond" to the
Silicon Valley Web Developer JUG that I thought folks on this list might be
interested in. In addition to the regular slide keyboard controls, press "T"
to toggle the outline/printable view which contains extra notes.
Presentation: http://www.twdata.org/presentations/struts-future/
Presentation software: http://www.meyerweb.com/eric/tools/s5/
Don
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
I really doubt that this writer is so lacking in insight as these
sorts of answers reflect. Quite the opposite, assuming that the
writer knows this rather obvious sort of thing, the writer seems to be
pointing up a problem which this sort of answer seems to miss
altogether.
On 9/10/05, Larry Meadors <la...@gmail.com> wrote:
> On 9/9/05, Murray Collingwood <mu...@focus-computing.com.au> wrote:
> > I'm just a humble Struts user (and relatively new), and I don't claim to speak for the
> > group as a whole.
> >
> > I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I get the
> > feeling that the goal posts just don't stop moving.
>
> Welcome to the world of technology.
>
> I hate to be the one to break it to you, but the simple fact is that
> it changes.
>
> Frequently and massively, and often times in a manner more like
> fashion than science (in contrast to Craig's response). Developers
> have ADD, and chase after every shiny object they see.
>
> On the bright side, it is somewhat cyclical. When I finished school in
> the early 90's client-server VB apps were king. Next came the web. Now
> we are looking at fatter RiA (Vic's favorite flavor du juor!) and next
> we'll trim them down to make them run nicer on cell phones, then the
> phones will get beefier and we'll get back to fatter clients, then
> we'll trim them down to run on watches or chips embedded in our
> sunglasses or toenails.
>
> Get used to it, try to predict it to some extent, and you'll do fine.
> If you are looking for a job that doesn't change...bad news: This is
> not it.
>
> Larry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Larry Meadors <la...@gmail.com>.
On 9/9/05, Murray Collingwood <mu...@focus-computing.com.au> wrote:
> I'm just a humble Struts user (and relatively new), and I don't claim to speak for the
> group as a whole.
>
> I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I get the
> feeling that the goal posts just don't stop moving.
Welcome to the world of technology.
I hate to be the one to break it to you, but the simple fact is that
it changes.
Frequently and massively, and often times in a manner more like
fashion than science (in contrast to Craig's response). Developers
have ADD, and chase after every shiny object they see.
On the bright side, it is somewhat cyclical. When I finished school in
the early 90's client-server VB apps were king. Next came the web. Now
we are looking at fatter RiA (Vic's favorite flavor du juor!) and next
we'll trim them down to make them run nicer on cell phones, then the
phones will get beefier and we'll get back to fatter clients, then
we'll trim them down to run on watches or chips embedded in our
sunglasses or toenails.
Get used to it, try to predict it to some extent, and you'll do fine.
If you are looking for a job that doesn't change...bad news: This is
not it.
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Session Synchronization Issues (Re: Who (really) decides?)
Posted by Leon Rosenberg <st...@anotheria.net>.
On Mon, 2005-09-12 at 11:18 -0500, Joe Germuska wrote:
> At 5:24 PM +0200 9/12/05, Leon Rosenberg wrote:
> >And I think there is no PMC for tomcat?
>
> Tomcat is still officially a Jakarta subproject, so the Jakarta PMC
> fills this role. I'm not sure at this time if they are planning to
> move to TLP or not, but probably someone else on this list knows.
>
> > > If nothing changes by Wednesday, if it were me, I'd submit a patch to
> >> the documentation summarizing the issue and pointing to the ticket.
> >
> >How can I submit a patch to the documentation?
>
> The site is in CVS (not SVN); I think this is the main root:
> http://svn.apache.org/viewcvs.cgi/jakarta-tomcat/src/doc/?root=Apache
>
> By the way, iId like to point out that in Struts 1.3 the
> ActionContext provides a pretty convenient way to organize your
> application to help control this. (Soon-to-be-) Common practice is
> to specify an alternative implementation class for ActionContext with
> your own typesafe property methods which internally use the request
> and/or session to store values. You could control synchronization on
> those methods.
>
> At this time, Struts doesn't routinely place the ActionContext itself
> into the request scope (although perhaps it should?) but if you put
> it there, then even your JSPs could use the ActionContext as a facade
> against the Session and then you could control the sync issues.
Sounds interesting, will look into it,
thanx
Leon
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Session Synchronization Issues (Re: Who (really) decides?)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 5:24 PM +0200 9/12/05, Leon Rosenberg wrote:
>And I think there is no PMC for tomcat?
Tomcat is still officially a Jakarta subproject, so the Jakarta PMC
fills this role. I'm not sure at this time if they are planning to
move to TLP or not, but probably someone else on this list knows.
> > If nothing changes by Wednesday, if it were me, I'd submit a patch to
>> the documentation summarizing the issue and pointing to the ticket.
>
>How can I submit a patch to the documentation?
The site is in CVS (not SVN); I think this is the main root:
http://svn.apache.org/viewcvs.cgi/jakarta-tomcat/src/doc/?root=Apache
By the way, iId like to point out that in Struts 1.3 the
ActionContext provides a pretty convenient way to organize your
application to help control this. (Soon-to-be-) Common practice is
to specify an alternative implementation class for ActionContext with
your own typesafe property methods which internally use the request
and/or session to store values. You could control synchronization on
those methods.
At this time, Struts doesn't routinely place the ActionContext itself
into the request scope (although perhaps it should?) but if you put
it there, then even your JSPs could use the ActionContext as a facade
against the Session and then you could control the sync issues.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who (really) decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/12/05, David G. Friedman <hu...@ix.netcom.com> wrote:
> > From: Ted Husted [mailto:ted.husted@gmail.com]
> > Apache Tomcat was established as a top-level
> > project in May. The PMC members are
>
> Funny but I didn't see anything in their front page or main documentation
> about this when I did a search on the Jakarta site.
Tomcat hasn't done the infrastructure work yet. The Tomcat TLP
resolution is part of the May 2005 ASF Board minutes. They've only
posted through April 2005 on the website so far, but the records will
be made public in due course.
Because of the lag in the posting of the board minutes on the web
site, the ASF President, Greg Stein, sends the committers a summary
each month. As an ASF member, I'm also subscribed to the internal
board mailing list, which posts the meeting agendas and draft
resolutions for each meeting.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Who (really) decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
a quote from remy (in the bug comments)
"I wasn't really serious. In the end, it's not really my decision, so
you should send a request to the pmc once it is correctly setup."
So I assume TC is a TLP but they aren't functional yet, this would
explain Ted's and your posts :-)
regards
Leon
On Mon, 2005-09-12 at 12:34 -0400, David G. Friedman wrote:
> > From: Ted Husted [mailto:ted.husted@gmail.com]
> > Apache Tomcat was established as a top-level
> > project in May. The PMC members are
>
> Funny but I didn't see anything in their front page or main documentation
> about this when I did a search on the Jakarta site. Plus, top-levels
> usually
> work for urls like http://tomcat.apache.org and, well, there's just a funny
> redirect there. Any idea why they didn't change the URL and post it to
> their quarterly notes? For example, their q1 notes list Lucene being
> upgraded to top-level with the heading "Lucene moves to Apache top-level"
> but nothing for Tomcat.
>
> The Q1 & Q2 (may) notes don't show anything about Tomcat top-level status
> either. I'm curious, do you remember where you heard about that?
>
> Jakarta Projects' Q1 notes:
> http://jakarta.apache.org/site/news/news-2005-q1.html
>
> Jakarta Projects' Q2 notes:
> http://jakarta.apache.org/site/news/news-2005-q2.html
>
> Jakarta Projects' Q3 notes:
> http://jakarta.apache.org/site/news/news-2005-q3.html
>
> Ever curious,
> David
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Who (really) decides?
Posted by "David G. Friedman" <hu...@ix.netcom.com>.
> From: Ted Husted [mailto:ted.husted@gmail.com]
> Apache Tomcat was established as a top-level
> project in May. The PMC members are
Funny but I didn't see anything in their front page or main documentation
about this when I did a search on the Jakarta site. Plus, top-levels
usually
work for urls like http://tomcat.apache.org and, well, there's just a funny
redirect there. Any idea why they didn't change the URL and post it to
their quarterly notes? For example, their q1 notes list Lucene being
upgraded to top-level with the heading "Lucene moves to Apache top-level"
but nothing for Tomcat.
The Q1 & Q2 (may) notes don't show anything about Tomcat top-level status
either. I'm curious, do you remember where you heard about that?
Jakarta Projects' Q1 notes:
http://jakarta.apache.org/site/news/news-2005-q1.html
Jakarta Projects' Q2 notes:
http://jakarta.apache.org/site/news/news-2005-q2.html
Jakarta Projects' Q3 notes:
http://jakarta.apache.org/site/news/news-2005-q3.html
Ever curious,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who (really) decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/12/05, Leon Rosenberg <st...@anotheria.net> wrote:
> How can I submit a patch to the documentation?
It's the same as code, only to XML source.
* http://jakarta.apache.org/site/source.html#Patches
> And I think there is no PMC for tomcat?
Apache Tomcat was established as a top-level project in May. The PMC
members are
Jean-Francois Arcand (jfarcand@apache.org)
Bill Barker (billbarker@apache.org)
Kin-man Chung (kinman@apache.org)
Jean-Frederic Clere (jfclere@apache.org)
Ian Darwin (idarwin@apache.org)
Tim Funk (funkman@apache.org)
Henri Gomez (hgomez@apache.org)
Filip Hanik (fhanik@apache.org)
Larry Isaacs (larryi@apache.org)
Jim Jagielski (jim@apache.org)
Jan Luehe (luehe@apache.org)
Costin Manolache (costin@apache.org)
Remy Maucherat (remm@apache.org)
Kurt Miller (truk@apache.org)
Glenn Nielsen (glenn@apache.org)
Amy Roh (amyroh@apache.org)
Peter Rossbach (pero@apache.org)
Yoav Shapira (yoavs@apache.org)
Mark Thomas (markt@apache.org)
Mladen Turk (mturk@apache.org)
Keith Wannamaker (keith@apache.org)
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who (really) decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
On Mon, 2005-09-12 at 06:23 -0400, Ted Husted wrote:
> On 9/10/05, Leon Rosenberg <st...@anotheria.net> wrote:
> > I agree with Frank that, what Ted says, is nice and right and everything,
> > but it's the theory. The real life shows it's cold shoulder.
> >
> > I don't know whether my example fits your question, but at least it fits the
> > topic of the thread, so it came in handy.
> > As you might know, or not know, there is an issue with tomcat 5. To make it
> > short:
> > You can not use struts (or probably most other jakarta projects) with tomcat
> > 5. The issue has been submitted. There is a patch available. The bug became
> > 16 votes (btw. some struts commiters voted too), which is by far most votes
> > on open tomcat 5 bugs right now.
> > So far to the community part. The tomcat developers or probably the tomcat
> > developer in lead, Remy Maucherat, refuses to fix it.
> > So who really decides? Anyone, but not the community and not the users. (And
> > please don't think that struts is safe from that)
>
> Looking over the bugzilla ticket, which was posted on Friday, it looks
> like a healthy discussion to me. Sure, one committer wants the ticket
> to go away, but he is being overruled. If not by the other committers,
> certainly by users. Any Tomcat committer can apply that patch. It's
> not a heirarchy. One comitter does not need to ask another for
> permission to make a change.
So we just have to find a willing committer? :-) Maybe you know one? :-)
Btw, the issue is still resolved as invalid, so it doesn't look like
someone has been overruled... I mean tomcat developers / committers
(surely not all, but those involved) simply closed the case...
>
> In this particular instance, there seems to a problem with the
> specification. Unfortunately, the last I knew, the scope of the Tomcat
> project including staying in line with the specification. So, if
> someone did apply the patch, a PMC member could veto it on that
> technical ground. If another PMC member seconds the veto, then the
> patch would have be undone.
Well, this seems in fact being a spec interpretation issue. However, the
bug fix wouldn't harm the spec, because it seems that both cases are
valid. And in my personal opinion Frank's post hits the problem best:
spec or not, if I call session.getAttribute() or setAttribute
() in a servlet or Struts Action or whatnot, I do not expect there to be any
chance of the internal data structures getting corrupted... and I do not
expect to have to do anything myself to ensure any of this...
And I think there is no PMC for tomcat?
>
> But, if not for the specification issue, any Tomcat committer could
> apply that patch. If a PMC member tries to undo another member's
> change, without a technical justification, the likely result will be
> loss of his or her Apache account. We've seen that happen before. The
> ASF board wouldn't rule on a technical issue, but if one project
> member tries to run the project solo, that member is shown the door.
Still I miss the "one" committer :-)
>
> As it stands, in the span of three days, there seems to be available
> to the public
>
> * A patch that users can apply it to their own copy of Tomcat.
> * A suggestion for a compiled patch that people could just put in
> their classpath.
> * A change people can make to the configuation file that solves the problem.
The last one will probably exists in future versions, no committment
when... or "if at all".
>
> If nothing changes by Wednesday, if it were me, I'd submit a patch to
> the documentation summarizing the issue and pointing to the ticket.
How can I submit a patch to the documentation?
> I'd also start a thread on Tomcat User to be sure people know about
> the problem. (Being careful to take that tact: Alert people of the
> problem, without complaining that no one will apply the patch.)
Will do.
>
> You might also encourage people to send in their request to clarify
> the specification, as Craig has already done. If the specification is
> clarified, then the patch is veto-proof. All you need is one Tomcat
> PMC member who will apply it, and the deed is done.
I sent a request to sun myself too, and guess what answer i got... none
at all.
>
> If the issue is not resolved by the time the next release vote comes
> around, if it were me, I'd vote -1 on the release and encourage
> everyone involved in the bugzilla ticket and user thread to do the
> same. The -1s won't be binding, but if the users outvote the
> committers by a wide margin, people will start to wake up and smell
> the coffee.
will do.
>
> (Did someone say coffee?...)
great idea :-) entering *coffee dreaming, moving in the kitchen mode
now*
best regards
Leon
>
> -- HTH, Ted.
> http://www.husted.com/poe/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who (really) decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/10/05, Leon Rosenberg <st...@anotheria.net> wrote:
> I agree with Frank that, what Ted says, is nice and right and everything,
> but it's the theory. The real life shows it's cold shoulder.
>
> I don't know whether my example fits your question, but at least it fits the
> topic of the thread, so it came in handy.
> As you might know, or not know, there is an issue with tomcat 5. To make it
> short:
> You can not use struts (or probably most other jakarta projects) with tomcat
> 5. The issue has been submitted. There is a patch available. The bug became
> 16 votes (btw. some struts commiters voted too), which is by far most votes
> on open tomcat 5 bugs right now.
> So far to the community part. The tomcat developers or probably the tomcat
> developer in lead, Remy Maucherat, refuses to fix it.
> So who really decides? Anyone, but not the community and not the users. (And
> please don't think that struts is safe from that)
Looking over the bugzilla ticket, which was posted on Friday, it looks
like a healthy discussion to me. Sure, one committer wants the ticket
to go away, but he is being overruled. If not by the other committers,
certainly by users. Any Tomcat committer can apply that patch. It's
not a heirarchy. One comitter does not need to ask another for
permission to make a change.
In this particular instance, there seems to a problem with the
specification. Unfortunately, the last I knew, the scope of the Tomcat
project including staying in line with the specification. So, if
someone did apply the patch, a PMC member could veto it on that
technical ground. If another PMC member seconds the veto, then the
patch would have be undone.
But, if not for the specification issue, any Tomcat committer could
apply that patch. If a PMC member tries to undo another member's
change, without a technical justification, the likely result will be
loss of his or her Apache account. We've seen that happen before. The
ASF board wouldn't rule on a technical issue, but if one project
member tries to run the project solo, that member is shown the door.
As it stands, in the span of three days, there seems to be available
to the public
* A patch that users can apply it to their own copy of Tomcat.
* A suggestion for a compiled patch that people could just put in
their classpath.
* A change people can make to the configuation file that solves the problem.
If nothing changes by Wednesday, if it were me, I'd submit a patch to
the documentation summarizing the issue and pointing to the ticket.
I'd also start a thread on Tomcat User to be sure people know about
the problem. (Being careful to take that tact: Alert people of the
problem, without complaining that no one will apply the patch.)
You might also encourage people to send in their request to clarify
the specification, as Craig has already done. If the specification is
clarified, then the patch is veto-proof. All you need is one Tomcat
PMC member who will apply it, and the deed is done.
If the issue is not resolved by the time the next release vote comes
around, if it were me, I'd vote -1 on the release and encourage
everyone involved in the bugzilla ticket and user thread to do the
same. The -1s won't be binding, but if the users outvote the
committers by a wide margin, people will start to wake up and smell
the coffee.
(Did someone say coffee?...)
-- HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who (really) decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Gesendet: Samstag, 10. September 2005 17:12
> An: Struts Users Mailing List
> Betreff: Re: Who decides?
>
> Ted Husted wrote:
> > Sometimes, we hear about people "voting with their feet". Here, we
> > invite people to vote with their hands, by collaborating on
> code and
> > documentation. It's not up to anyone else. It's up to everyone who
> > volunteers. Here, the only decisions that matter are patches and
> > commits, because without commits, nothing can change.
>
> Interesting... It's not really up to those that "vote", it
> is always in the end up to those that "commit". Every time a
> contribution is turned away, that is in essence saying "your
> vote doesn't count, at least this time", isn't it?
I agree with Frank that, what Ted says, is nice and right and everything,
but it's the theory. The real life shows it's cold shoulder.
I don't know whether my example fits your question, but at least it fits the
topic of the thread, so it came in handy.
As you might know, or not know, there is an issue with tomcat 5. To make it
short:
You can not use struts (or probably most other jakarta projects) with tomcat
5. The issue has been submitted. There is a patch available. The bug became
16 votes (btw. some struts commiters voted too), which is by far most votes
on open tomcat 5 bugs right now.
So far to the community part. The tomcat developers or probably the tomcat
developer in lead, Remy Maucherat, refuses to fix it.
So who really decides? Anyone, but not the community and not the users. (And
please don't think that struts is safe from that)
>
> > Discussion is good. Stepping up to the plate and making a
> difference is better.
>
> But how many times have people stepped up and been stopped
> from making a difference? In the end, isn't it the
> committers that have the power to direct where things go,
> regardless of what the community "votes"? As Craig said, a
> good community-driven project will listen to the community.
Yes, and it seems that "community-driven projects" are not to be found at
apache.
Regards
Leon
P.S. In case you didn't know it yet, here is the link to the tomcat issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541
P.P.S. By the way, when goes struts warn their users, that struts 1.1, 1.2.x
and 1.3 aren't compliant with tomcat 5?
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted Husted wrote:
> Sometimes, we hear about people "voting with their feet". Here, we
> invite people to vote with their hands, by collaborating on code and
> documentation. It's not up to anyone else. It's up to everyone who
> volunteers. Here, the only decisions that matter are patches and
> commits, because without commits, nothing can change.
Interesting... It's not really up to those that "vote", it is always in
the end up to those that "commit". Every time a contribution is turned
away, that is in essence saying "your vote doesn't count, at least this
time", isn't it?
> Discussion is good. Stepping up to the plate and making a difference is better.
But how many times have people stepped up and been stopped from making a
difference? In the end, isn't it the committers that have the power to
direct where things go, regardless of what the community "votes"? As
Craig said, a good community-driven project will listen to the community.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/9/05, Murray Collingwood <mu...@focus-computing.com.au> wrote:
> I'm just a humble Struts user (and relatively new), and I don't claim to speak for the
> group as a whole.
>
> I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I get the
> feeling that the goal posts just don't stop moving.
>
> The time I have spent learning and creating a Struts application should be an
> investment in my future development, not a stepping stone to a whole new set of
> technologies that will continue to slow my productivity (through on-going training).
>
> Who, and this is my question, who makes the decision whether a technology is going to
> be good for the greater community? Who asks the questions "Do we need it?", "Will
> the technology provide significantly greater returns than training costs?", "Will the
> technology last long enough to deliver those returns?"
Open source projects like Apache Struts are *not* designed to be
"steering committees" that make these type of decisions for the
"greater good". We are simply a group of engineers, just like you,
who are trying to ship our own products. But, instead of keeping our
work behind closed doors, we try to share what we do with other
engineers.
Believe it or not, we're not trying to sell anyone anything. If people
want to use an Apache Struts product, and contribute to the project by
helping out on the list and with the coding, that's great. But, we're
not here to garner market share. We're here to foster a community of
volunteer developers that can collaborate on creating the software
they themselves want to use in their own projects. We're not trying to
save the world, we're trying to ship our own next release.
> Who is it that has decided we need to keep extending the Struts framework without
> considering the developers' need for better problem identification and documentation of
> the existing Struts system. This list gets so many emails of people struggling with
> existing technology: Dynaforms, Validation, Iteration, Cookies, Flow control, and the
> number of different versions of everything "out there" that we need to know about in
> order to work with this system.
>
> Who answers the question, "Why aren't we getting better error checking / debugging
> facilities for Struts?"
Unpaid volunteers answer that question, and every other question, by
donating their own time and energy to the project. Sometimes,
individual businesses help answer those questions by letting
employeers work on the project during company time.
Tthe "Struts PMC" does *not* answer that question, because nobody
works for the PMC. We are all unpaid volunteers, each answering that
question in our own way, in what little time we have available. The
PMC does decide if a contribution becomes part of a Apache Struts
distribution, but, first, an unpaid volunteer has to create a
contribution for the PMC to review.
To answer the explicit question, Struts does not have better error
checking because no one has volunteered the time and energy to make
that happen.
> It would be amiss of me to say Struts alone is responsible here, we should include
> Tomcat, MySQL, Connector/J, JSP, Java. And I'm not saying everybody is doing a
> terrible job, just asking whether we need to refocus our development efforts.
>
> I'm not a fan of Microsoft but at least they have somebody that makes those decisions
> and they appear to be developing their technology for productivity. They have
> documentation. They have tutorials. They have backward compatibility. And, have
Microsoft has these things because Microsoft pays for them. And, as to
J2EE, Sun also has these things, because Sun pays for them.
The Apache Software Foundation, like most open source organizations,
has no paid staff. The ASF can't "decide" how unpaid volunteers spend
their free time.
Of course, Struts Classic does provide backward compatibility because
we want our own applications to enjoy backward compatability between
releases. Like most Apache projects, we are very careful to put
features through a strict deprecate/release/remove cycle. Not because
it makes for a nice bullet on marketing collateral, but because
evolutionary compatability is a feature we want for ourselves.
> you noticed how many websites are using .NET technology! The number seems to
> growing much faster than J2EE or JEE.
Well, let's do Struts for .NET, then. Or PHP. Or Ruby (if Rails is not
to your liking).
As an engineer, I don't much care what technology my clients or
employers choose. The engineering skills that matter transfer.
Platform specifics are ephemeral details that we will always have to
relearn, it's just a matter of when.
Struts is an ASF project. It is not our mission to support a
particular technology. We are here to foster communities that build
software using whatever technologies the volunteers choose.
>
> When I was looking for an ISP to host my Struts application I found many more
> companies providing Microsoft servers with .NET than Unix/Linux servers with the
> necessary version of Tomcat or JBoss.
>
> If I were to write a web product to be sold and run inhouse, I would probably develop it
> using Microsoft technology, it's just so much easier to say, "requires IIS 6+ and
> SQLserver 2005+" and know that it will work. If you had to ship your product how many
> technologies with specific versions would you have to list?
>
> Is Struts in danger of becoming just an academic exercise?
Hmmm, probably not. Apache Struts developers are not academics, they
are working stiffs just like you. We eat our own dog food, and use
Struts on our own projects. Don Brown is working on Ti because Don
Brown wants to use Ti in his own projects someday.
>If Struts is going to be
> productive then we need to see:
> * more documentation (and I'm not talking about the API, I'm sick of trying to read the
> API and guess the usage of the taglib functions) plus tutorials, online training etc,
> * more tools for building our applications (I know there are some but I'm on NetBeans
> and it appears to be lagging behind, Eclipse and Exadel I found to be too inflexible),
> * more error checking of the configuration files and better error messages indicating
> what the real problem is, maybe even warnings before the program runs,
> * more debugging utilities (spying on the http conversations and being able to
> examine the contents of our beans),
> * more backward compatibility so that I don't have to spend hours upgrading my app
> when my server updates or I move to a new server,
> * more stability in the platform we choose (with reference to the recent Tomcat bugs
> that were brought to the attention of this list).
>
> If I were asked to vote it would probably be a conservative vote to consolidate our
> current technologies with better tools and a better product.
We ask people to vote everyday. Not by raising their virtual hands,
but by doing the actual work.
* http://struts.apache.org/faqs/helping.html
As to J2EE, Sun did "vote" to "consolidate our current technologies
with better tools and a better product", and they named the product
"JavaServer Faces".
If volunteers want to further Sun's "vote", we invite them to help out
with Struts Shale. If not, a lot of people are still working on Struts
Classic, and some are starting to look at Struts Ti.
Sometimes, we hear about people "voting with their feet". Here, we
invite people to vote with their hands, by collaborating on code and
documentation. It's not up to anyone else. It's up to everyone who
volunteers. Here, the only decisions that matter are patches and
commits, because without commits, nothing can change.
> Okay, there, I said it. It's out of my system and open for discussion.
Discussion is good. Stepping up to the plate and making a difference is better.
> Kind regards
> mc
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
Again, there is no reason to think that the writer did not see this.
This is a response that fails to address the problem by assuming (as a
"straw man" or a "red herring") with no evidence at all that the
writer was not aware of this rather obvious fact that people not even
involved in the IT community are well-aware of on a daily basis. The
question was about the Struts community and not the writer. The
writer should be aware from answers like this that something is amiss.
On 9/10/05, David Thielen <da...@windward.net> wrote:
> I was talking to my daughters about this the other day. In the last 25 years
> I have had to learn a whole new environment/API/everything:
>
> * DOS - Pascal and then C
>
> * Windows - C and then C++
>
> o Applications
>
> o System level code (wrote part of Win95)
>
> o Games
>
> * Java - EJB 1.0 & EJB 2.0
>
> * .NET/C#
>
>
>
> You don't get to stick with a single technology anymore. Like it or not, the
> world requires constant learning and constant movement to new tools and
> technology. Struts will be replaced by JSP/Shale and in 5 years (or sooner)
> that will be replaced by something else.
>
>
>
> It's evolution at hyperspeed.
>
>
>
> - dave
>
>
>
>
>
> David Thielen
>
> 303-499-2544
>
> www.windwardreports.com
>
>
>
>
>
> -----Original Message-----
> From: Craig McClanahan [mailto:craigmcc@gmail.com]
> Sent: Friday, September 09, 2005 11:11 PM
> To: Struts Users Mailing List
> Subject: Re: Who decides?
>
>
>
> ...
>
> I'm afraid that this is the nature of the software developer landscape.
>
> You've heard the term "Internet time"? That is the environment in which we
>
> (as application architects) need to decide which technoogies to become
>
> dependent upon. The gamble, of course, is that the lifetime of the
>
> technology will correspond with the lifetime of the application you build on
>
>
> top of it. Sometimes you win, sometimes you lose.
>
> ...
>
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Vic Cekvenich <ne...@roomity.com>.
> Dakota Jack on 10/09/05 07:09, wrote:
>>
>> I would strongly suggest you consider the Spring alternative which is
>> highly unlikely to change in fundamentals for a very long time.
>>
I would argue that technology is shifting to RiA (Ajax, Laszlo, JDNC),
so a static framework (if Spring is statick, I would not know, I know
they have a Swing project) is not futuristic.
But to the topic... :
In some organizations managers decide what the tech. stack is for them.
My theory is that they read PC Week and pick some story like IBM EJB or
MS Access, usualy they use logic like: We paid a lot of money for this,
this will be good + we paid a lot of money for support, so we know we
won't make a mistake. Lets use some inovative design... like push. Use
Notes for mail client, and lots of virus scanners and sofware change
managment on each PC to improve productivity. Then they direct people to
support "company decission" and find ways to use the tech. Of course,
sinc tech is expensive, their people are not best paid. Lets call this
tech 1st orgnaization. Ex: "We are an IBM shop".
Other organizations let exerienced developers pick an effiective tech
stack, based on the business requirments and the business problem. Ex:
"We are a business shop".
Of course, mostly there are shades of gray.
I hope to mostly work in the 2nd type of orgnization and .... I spend
some time monitoring good tech stacks: Faclets, JDNC, CoR, iBatis,
Groovy, Fedora, large MonitorS ....
(And sometimes in my mind I put things in a bad tech stack: EJB,
Spring(too heavy), ORM, Beans (used to be in good stach untill I used
collections more), Notes, DHTML, etc. Your list could be different.
I think Ted is one of people that articulated that in different
organizations in different situations one picks an eviroment friendly
tech stack, or words to that effect. In order for developers to belive
in their tools for one.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Who decides?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Adam Hardy on 10/09/05 11:11, wrote:
> Since you are recommending Spring, can you answer a couple of questions
> about it? For instance, is there any outstanding improvement over struts
> in the patterns that it offers for say:
>
[snip]
> * security - Spring is based on Acegi right?
while i'm on the subject, how should Acegi be pronounced?
ace G.I.
akeggi
A.C.E.G.I
A.C.G.I.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
I am saying that for me Struts is not a viable product to use in any
new commercial areas because of this. Spring is hugely superior as
things stand and Struts is threatening to devolve. Indeed, it would
be easier to build a new Struts on top of Spring than to fix get
anyone to evolve Struts rather than change it into something that no
fan of the Struts type architecture could possibly understand and
love.
On 9/11/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> My aim with the list of patterns / features was to give you something to
> scan over quickly to point out where the Spring MVC framework provides
> something better than struts.
>
> They're not really just struts features, they're more patterns found in
> any web-app. I find several of them require cumbersome solutions in struts.
>
> Are you saying then really that the main plus-point for Spring over
> Struts is the stability of the project?
>
>
> Dakota Jack on 10/09/05 21:24, wrote:
> > The main issue, Adam, was stability. I believe that my statements
> > were useful for the person asking the question. I am not interested
> > in being "non-contensious" or otherwise satisfying your personal
> > needs. I was trying to answer the question in a helpful way, even if
> > you might do otherwise. If you would like to do otherwise, do so. I
> > don't care. I think that a honest answer to the questioner requires
> > stating what is relevant. That seems okay to me. LIke I said, do
> > what you like. If you don't like what I say, I recommend you take
> > evasive action. I am not trying to impress you but assist someone
> > else.
> >
> > Regarding the list you tossed out, much of that is portable and almost
> > all could be easily made portable. Some of the "features", e.g. the
> > way Struts code does multiple commands on a form submit, I personally
> > consider to be more a bug that a feature.
> >
> > What you like is not my concern. I was talking to someone else. I
> > don't find your list to be fair, however. A large part of your list
> > is stuff that is quite portable and not Struts specific and others are
> > simply not covered by Strust. Anyway, I have always liked Struts
> > classic and still do. What I was saying is that the community is
> > unstable and that a person starting an application would be taking a
> > risk at this point starting with Struts.
> >
> >
> >
> > On 9/10/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> >
> >>Dakota Jack on 10/09/05 07:09, wrote:
> >>
> >>>I sympathize entirely with what you are saying, Murray, and believe
> >>>that there is no good reason for the present difficulties you face.
> >>>The situation is NOT inevitable or even desirable.
> >>>
> >>>I would strongly suggest you consider the Spring alternative which is
> >>>highly unlikely to change in fundamentals for a very long time.
> >>>
> >>>There is no vision here that is not willy nilly and merely fulfilling
> >>>some philosophical opinions about community which come down to
> >>>servicing the older committers' daytime jobs and reputatoins, in my
> >>>opinion. They say that too, but I will guess that they don't want
> >>>anyone else saying it.
> >>>
> >>>Struts is a very unstable community producing inferior code at this
> >>>point with political infighting on a "nice" level to steal the name
> >>>for the latest and greatest old idea trying to claim to be very, very,
> >>>very new.
> >>
> >>Dakota, can't you control your trollish instincts? There are far less
> >>contentious ways of saying what you said.
> >>
> >>Since you are recommending Spring, can you answer a couple of questions
> >>about it? For instance, is there any outstanding improvement over struts
> >>in the patterns that it offers for say:
> >>
> >> * tiles
> >> * breadcrumb menu
> >> * taglibs
> >> * nested beans
> >> * l12n and i18n (prob: dropdowns)
> >> * reference data cache
> >> * dropdown data collections (Id & Label)
> >> * DTOs to view mapping
> >> * validator
> >> * multiple commands on form submit
> >> * cancel button
> >> * post-redirect-get
> >> * exception handling
> >> * displaying messages
> >> * security - Spring is based on Acegi right?
> >> * transaction token
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> >>For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
My aim with the list of patterns / features was to give you something to
scan over quickly to point out where the Spring MVC framework provides
something better than struts.
They're not really just struts features, they're more patterns found in
any web-app. I find several of them require cumbersome solutions in struts.
Are you saying then really that the main plus-point for Spring over
Struts is the stability of the project?
Dakota Jack on 10/09/05 21:24, wrote:
> The main issue, Adam, was stability. I believe that my statements
> were useful for the person asking the question. I am not interested
> in being "non-contensious" or otherwise satisfying your personal
> needs. I was trying to answer the question in a helpful way, even if
> you might do otherwise. If you would like to do otherwise, do so. I
> don't care. I think that a honest answer to the questioner requires
> stating what is relevant. That seems okay to me. LIke I said, do
> what you like. If you don't like what I say, I recommend you take
> evasive action. I am not trying to impress you but assist someone
> else.
>
> Regarding the list you tossed out, much of that is portable and almost
> all could be easily made portable. Some of the "features", e.g. the
> way Struts code does multiple commands on a form submit, I personally
> consider to be more a bug that a feature.
>
> What you like is not my concern. I was talking to someone else. I
> don't find your list to be fair, however. A large part of your list
> is stuff that is quite portable and not Struts specific and others are
> simply not covered by Strust. Anyway, I have always liked Struts
> classic and still do. What I was saying is that the community is
> unstable and that a person starting an application would be taking a
> risk at this point starting with Struts.
>
>
>
> On 9/10/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
>
>>Dakota Jack on 10/09/05 07:09, wrote:
>>
>>>I sympathize entirely with what you are saying, Murray, and believe
>>>that there is no good reason for the present difficulties you face.
>>>The situation is NOT inevitable or even desirable.
>>>
>>>I would strongly suggest you consider the Spring alternative which is
>>>highly unlikely to change in fundamentals for a very long time.
>>>
>>>There is no vision here that is not willy nilly and merely fulfilling
>>>some philosophical opinions about community which come down to
>>>servicing the older committers' daytime jobs and reputatoins, in my
>>>opinion. They say that too, but I will guess that they don't want
>>>anyone else saying it.
>>>
>>>Struts is a very unstable community producing inferior code at this
>>>point with political infighting on a "nice" level to steal the name
>>>for the latest and greatest old idea trying to claim to be very, very,
>>>very new.
>>
>>Dakota, can't you control your trollish instincts? There are far less
>>contentious ways of saying what you said.
>>
>>Since you are recommending Spring, can you answer a couple of questions
>>about it? For instance, is there any outstanding improvement over struts
>>in the patterns that it offers for say:
>>
>> * tiles
>> * breadcrumb menu
>> * taglibs
>> * nested beans
>> * l12n and i18n (prob: dropdowns)
>> * reference data cache
>> * dropdown data collections (Id & Label)
>> * DTOs to view mapping
>> * validator
>> * multiple commands on form submit
>> * cancel button
>> * post-redirect-get
>> * exception handling
>> * displaying messages
>> * security - Spring is based on Acegi right?
>> * transaction token
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
The main issue, Adam, was stability. I believe that my statements
were useful for the person asking the question. I am not interested
in being "non-contensious" or otherwise satisfying your personal
needs. I was trying to answer the question in a helpful way, even if
you might do otherwise. If you would like to do otherwise, do so. I
don't care. I think that a honest answer to the questioner requires
stating what is relevant. That seems okay to me. LIke I said, do
what you like. If you don't like what I say, I recommend you take
evasive action. I am not trying to impress you but assist someone
else.
Regarding the list you tossed out, much of that is portable and almost
all could be easily made portable. Some of the "features", e.g. the
way Struts code does multiple commands on a form submit, I personally
consider to be more a bug that a feature.
What you like is not my concern. I was talking to someone else. I
don't find your list to be fair, however. A large part of your list
is stuff that is quite portable and not Struts specific and others are
simply not covered by Strust. Anyway, I have always liked Struts
classic and still do. What I was saying is that the community is
unstable and that a person starting an application would be taking a
risk at this point starting with Struts.
On 9/10/05, Adam Hardy <ah...@cyberspaceroad.com> wrote:
> Dakota Jack on 10/09/05 07:09, wrote:
> > I sympathize entirely with what you are saying, Murray, and believe
> > that there is no good reason for the present difficulties you face.
> > The situation is NOT inevitable or even desirable.
> >
> > I would strongly suggest you consider the Spring alternative which is
> > highly unlikely to change in fundamentals for a very long time.
> >
> > There is no vision here that is not willy nilly and merely fulfilling
> > some philosophical opinions about community which come down to
> > servicing the older committers' daytime jobs and reputatoins, in my
> > opinion. They say that too, but I will guess that they don't want
> > anyone else saying it.
> >
> > Struts is a very unstable community producing inferior code at this
> > point with political infighting on a "nice" level to steal the name
> > for the latest and greatest old idea trying to claim to be very, very,
> > very new.
>
> Dakota, can't you control your trollish instincts? There are far less
> contentious ways of saying what you said.
>
> Since you are recommending Spring, can you answer a couple of questions
> about it? For instance, is there any outstanding improvement over struts
> in the patterns that it offers for say:
>
> * tiles
> * breadcrumb menu
> * taglibs
> * nested beans
> * l12n and i18n (prob: dropdowns)
> * reference data cache
> * dropdown data collections (Id & Label)
> * DTOs to view mapping
> * validator
> * multiple commands on form submit
> * cancel button
> * post-redirect-get
> * exception handling
> * displaying messages
> * security - Spring is based on Acegi right?
> * transaction token
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
Dakota Jack on 10/09/05 07:09, wrote:
> I sympathize entirely with what you are saying, Murray, and believe
> that there is no good reason for the present difficulties you face.
> The situation is NOT inevitable or even desirable.
>
> I would strongly suggest you consider the Spring alternative which is
> highly unlikely to change in fundamentals for a very long time.
>
> There is no vision here that is not willy nilly and merely fulfilling
> some philosophical opinions about community which come down to
> servicing the older committers' daytime jobs and reputatoins, in my
> opinion. They say that too, but I will guess that they don't want
> anyone else saying it.
>
> Struts is a very unstable community producing inferior code at this
> point with political infighting on a "nice" level to steal the name
> for the latest and greatest old idea trying to claim to be very, very,
> very new.
Dakota, can't you control your trollish instincts? There are far less
contentious ways of saying what you said.
Since you are recommending Spring, can you answer a couple of questions
about it? For instance, is there any outstanding improvement over struts
in the patterns that it offers for say:
* tiles
* breadcrumb menu
* taglibs
* nested beans
* l12n and i18n (prob: dropdowns)
* reference data cache
* dropdown data collections (Id & Label)
* DTOs to view mapping
* validator
* multiple commands on form submit
* cancel button
* post-redirect-get
* exception handling
* displaying messages
* security - Spring is based on Acegi right?
* transaction token
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
I sympathize entirely with what you are saying, Murray, and believe
that there is no good reason for the present difficulties you face.
The situation is NOT inevitable or even desirable.
I would strongly suggest you consider the Spring alternative which is
highly unlikely to change in fundamentals for a very long time.
There is no vision here that is not willy nilly and merely fulfilling
some philosophical opinions about community which come down to
servicing the older committers' daytime jobs and reputatoins, in my
opinion. They say that too, but I will guess that they don't want
anyone else saying it.
Struts is a very unstable community producing inferior code at this
point with political infighting on a "nice" level to steal the name
for the latest and greatest old idea trying to claim to be very, very,
very new.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Martin Gainty <mg...@hotmail.com>.
Rick-
Agreed..
If tiles has no support in JSF then you might as well throw tiles into the
mix
If there is anything to be gained it is that your learning curve has to
accelerate to assimilate new technologies as the older technologies are
discarded.
>From my perspective I think the market drives the more proprietary
technologies to be discarded for open source
As in a race we only remember the guy that came in quickest
Martin-
----- Original Message -----
From: "Rick Reumann" <st...@reumann.net>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, September 12, 2005 1:40 PM
Subject: Re: Who decides?
> Craig McClanahan wrote the following on 9/10/2005 1:10 AM:
>
>> * I took my own advice when *I* was in college :-), and have a Business
>> Administration
>> degree, with an emphasis in Accounting. You'd think (from the outside)
>> that there couldn't
>> possibly be a profession that changes slower than accounting, but I can
>> guarantee you that
>> this is not the case. Once you get past double entry bookkeeping,
>> everything I learned in
>> college (even if I remembered it all, 30 years later) would be totally
>> obsolete.
>>
>> * The same sort of thing happens in scientific fields all over the map.
>> For example,
>> I aced a test on Astronomy by (among other things) nothing that Jupiter
>> had 12 moons,
>> Saturn had 9, and so on. Those facts were considered true at the time ...
>> but not any more.
>>
>> * Would you trust a doctor today to diagnose you with a 1950s medical
>> education?
>> Or even a 1990s medical education? Like basically all professions,
>> medicine (and software)
>> assume that a lifetime of learning new things is a fundamental
>> requirement for success.
>
> Although the above is true, there is a big difference from the fields you
> mention above and the IT field. Other professions build much more upon
> previous knowledge and experience. Sure the doctor might learn new
> techniques for performing open heart surgery, but I doubt he's throwing
> away everything he learned previously about the heart. Even his experience
> in performing surgery should increase over time.
>
> With IT, I've noticed that previous knowledge only helps slightly. Yes, a
> seasoned programmer will more valuable than someone right out of college,
> yet once that college grad has about 5 years (maybe less) experience, I
> would not say that he's necessarily any less valuable than the programmer
> who has been programming for 10 or more years. The deciding factor will
> then become who's been keeping up more with the latest technologies.
> Previous experience becomes much less important.
>
> With other professions I don't see this being the case as much. My
> background is in biology (BS degree) and education (masters degree). Even
> though in science things change at a rapid pace, previous experience in
> the field is still highly valued. A new planet might be discovered, but
> you are still working with the same old planets as well. Same thing I'm
> sure can be said for most other professions. Things build upon each other
> much more on other professions. Even if it's not pure 'fact type'
> knowledge, just basic experience in other profession is much more
> valuable. A police officer, fireman, teacher, construction worker - even
> in those fields just time itself in the profession can really have a large
> impact in your skill and value.
>
> Information Technology is very frustrating because certain things you
> learn can be COMPLETELY thrown out in a very short while. Take for
> instance something that hits home directly to me. I'm now in the process
> of learning JSF. All the time spent learning struts and even JSTL is
> basically thrown out the window if I end up coding with JSF. Same thing
> would be said if I jumped over to .NET. I can't think of a profession that
> throws away as much 'old' knowledge as the IT field.
>
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
re: Who decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Gesendet: Montag, 12. September 2005 20:36
> An: Struts Users Mailing List
> Cc: Struts Users Mailing List
> Betreff: Re: Who decides?
>
> On Mon, September 12, 2005 2:26 pm, Rick Reumann said:
> > An employeer shouldn't care so much what you know 'now' but what you
> have the potential to learn down the road.
>
> Hammer, meet head of nail :)
>
> *This* is how you interview an employer. And yes, I typed
> that correctly.
>
> You have essentially two choices in this world... one is to
> be a consultant, where you will have to keep up with all the
> latest, be able to perform immediately, and your employer
> will only care what you know right now, right this minute.
> This works for many people.
>
> The other choice is to find an employer who understands that
> IT is constantly evolving and it is ultimately in their best
> interest to find talented individuals with a track record of
> being able to learn and evolve with the industry. These jobs
> are harder to come by and usually require more in the way of
> experience and proven ability over time.
>
Ok, I'm lucky... I have both, being technically a consulter with all
benefits, but having a primary customer
who is just the perfect employer.
However I have to disagree with the other Steve's point :
>Let me give everyone a major hint. What most "programmers" are doing today
is NOT even close to Innovative. The guys that did the
>real work, started in this IT business back in the 1960' and 1970's, when
his business WAS "Rocket Science"
When I look back at things were done in 60s,70s it's like "they needed so
long, for what?" Back in those years the guys wouldn't be even able to dream
what things we are doing now!
Application Distribution? Middleware? Component-oriented programming?
Software maintanence? Maybe in 20 years our successors will look back and
smirk about our efforts, but we surely don't need to hide ourselfs in front
of the old garde from dark ages.
Besides, if you talk about basics, talk about Ada Byron, Babbage or Alan
Turing! Those were men (and women)! :-)
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Mon, September 12, 2005 2:26 pm, Rick Reumann said:
> An employeer shouldn't care so much what you know 'now' but what you
have the potential to learn down the road.
Hammer, meet head of nail :)
*This* is how you interview an employer. And yes, I typed that correctly.
You have essentially two choices in this world... one is to be a
consultant, where you will have to keep up with all the latest, be able to
perform immediately, and your employer will only care what you know right
now, right this minute. This works for many people.
The other choice is to find an employer who understands that IT is
constantly evolving and it is ultimately in their best interest to find
talented individuals with a track record of being able to learn and evolve
with the industry. These jobs are harder to come by and usually require
more in the way of experience and proven ability over time.
When you are looking for a job, you are interviewing your prospective
employer as much as they are interviewing you. If you choose choice #1,
you won't have quite as difficult a task because you'll be wanting to move
around a lot anyway, and the company knows they can get rid of you easier
and replace you easier, so both sides have a bit less risk.
If you choose the second path, it will be considerably more difficult to
find a job, but you will probably like it a lot better and wind up being
there a lot longer.
Of course, when you have rent to pay, being picky (which is another term
for choice #2!) is a lot more difficult. Give and take, as always :)
The point here is that what Rick said is completely correct... a good
employee has this understanding and accepts it. Look for those employers!
They are harder to find, but much more rewarding when you do.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by BH...@powersystems.rockwell.com.
Just to put in my 2 cent worth,
I am not sure your point is 100% valid. True, languages and technology is
changing daily and what you learn today is worthless in 10 years from a
coding language standpoint, but being a senior developer or architect is
very different than being a coder. Some key things that are learned from
experience:
1. Just because a new technology is "hot" in the industry, it is not
necessarily right for your organization. Many young talented developers
will attempt to change the environement to what they are comfortable with,
not what is the best fit for the company. I have seen a lot of good
developers attempt to write php or javascript functions because they know
how, but do not consider what the impact of that decision is. What is the
impact on the server? What is the impact on the client? How maintainable
is it if they move to a different projeect? etc.
2. Depending on the background of the developer, many younger (I sound
old) developers may not have been exposed to the various stages of the
production life cycle. They may work well on new projects, but not work
well under the pressure of a major production outage. Others may have
spent years developing updates to legacy systems which and not been exposed
to new development. Adding one of these developers to a new project, most
will attempt to impose what they know on the problem and not look at what
is best.
3. New technology geeks (self imposed title), often know a technology or a
suite of technologies. They are truely excellent programmers, but do not
understand business. (Welcome to the 2000 .bom explotion). Just because
something is a great idea, does not mean that it is a good business
decision. Just because you can do something, does not mean that you
should. User interface design, Business Process Optimization, Change
Management, these are soft skills that are required for a lot of companies.
4. When looking for senior level developers, architects, etc, you need a
developer that has been exposed to more than just one method of development
or one environment. Someone who truely knows that there are many ways to
solve a problem and knows how to find the right implementation. They need
to be able to think for themselves, not just code to what they know or want
to know.
Yes technology changes, but good practices, design knowledge, and research
skills are all tools that are developed over time.
Rick Reumann
<struttin@reumann
.net> To
Struts Users Mailing List
09/12/2005 02:26 <us...@struts.apache.org>
PM cc
Subject
Please respond to Re: Who decides?
"Struts Users
Mailing List"
<user@struts.apac
he.org>
Brandon Mercer wrote the following on 9/12/2005 2:11 PM:
> Building a web interface with a database backend isn't innovative.... it
> is mearly being implemented to solve a particular businesses need.
That's exactly my point though. Once you understanding the basics, the
learning is then in the new implementations of things ( you going to use
EJBs, hibernate, iBATIS?). You going to use JSF, WebWorks, Struts,
Tapestry? What's a bit annoying is having to figure out what to "pick"
to learn. It's sort of like gambling on what will be the next 'hot'
thing employeers will look for. Stupid really. An employeer shouldn't
care so much what you know 'now' but what you have the potential to
learn down the road.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Rick Reumann <st...@reumann.net>.
Brandon Mercer wrote the following on 9/12/2005 2:11 PM:
> Building a web interface with a database backend isn't innovative.... it
> is mearly being implemented to solve a particular businesses need.
That's exactly my point though. Once you understanding the basics, the
learning is then in the new implementations of things ( you going to use
EJBs, hibernate, iBATIS?). You going to use JSF, WebWorks, Struts,
Tapestry? What's a bit annoying is having to figure out what to "pick"
to learn. It's sort of like gambling on what will be the next 'hot'
thing employeers will look for. Stupid really. An employeer shouldn't
care so much what you know 'now' but what you have the potential to
learn down the road.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Brandon Mercer <br...@eutonian.com>.
Steve Beaver wrote:
>Let me give everyone a major hint. What most "programmers" are doing today
>is NOT
>even close to Innovative. The guys that did the real work, started in this
>IT business back
>in the 1960' and 1970's, when his business WAS "Rocket Science"
>
>
I'd have to agree. We're building on and utilizing the technology they
'innovated' during that timeframe to solve current business functions.
Building a web interface with a database backend isn't innovative.... it
is mearly being implemented to solve a particular businesses need.
Brandon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Who decides?
Posted by Steve Beaver <st...@comcast.net>.
Let me give everyone a major hint. What most "programmers" are doing today
is NOT
even close to Innovative. The guys that did the real work, started in this
IT business back
in the 1960' and 1970's, when his business WAS "Rocket Science"
Steve
-----Original Message-----
From: Rick Reumann [mailto:struttin@reumann.net]
Sent: Monday, September 12, 2005 12:07 PM
To: Struts Users Mailing List
Subject: Re: Who decides?
netsql wrote the following on 9/12/2005 1:54 PM:
> I disagree. SQL SELECT command writen by somone w/ 6 years, or 9 years
> of 12 years expereince, etc. is a huge difference IMO.
Well SQL/DB stuff is definitely an exception and that's another pet-peve
of mine:) The DBA guys always seem like they are the "big dogs." I'm
not diminishing their skills and what they have to learn, but it's
mostly all geared around the same concept - the database and SQL.
Compare that to someone developing a J2EE application and all the varied
technologies that are involved other than just SQL.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Rick Reumann <st...@reumann.net>.
netsql wrote the following on 9/12/2005 1:54 PM:
> I disagree. SQL SELECT command writen by somone w/ 6 years, or 9 years
> of 12 years expereince, etc. is a huge difference IMO.
Well SQL/DB stuff is definitely an exception and that's another pet-peve
of mine:) The DBA guys always seem like they are the "big dogs." I'm
not diminishing their skills and what they have to learn, but it's
mostly all geared around the same concept - the database and SQL.
Compare that to someone developing a J2EE application and all the varied
technologies that are involved other than just SQL.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by netsql <ne...@roomity.com>.
I disagree. SQL SELECT command writen by somone w/ 6 years, or 9 years
of 12 years expereince, etc. is a huge difference IMO.
Also, would you give a $10MM+ budget to 5 years person? No one would.
They would never see a forest from the trees.
There may be perception amongst MBA's that we are all widgets and "IT
does not matter", but to me ... PHB's don't matter.
.V
lets see my tech timeline: Unix, Informix, DBII, Turbo Pascal, Cliper,
rBase, OS2/MS SQL, PowerBuilder, Sybase, C,C++, Java, Fedora,.....
Rick Reumann wrote:
> Yes,
> a seasoned programmer will more valuable than someone right out of
> college, yet once that college grad has about 5 years (maybe less)
> experience, I would not say that he's necessarily any less valuable than
> the programmer who has been programming for 10 or more years. The
> deciding factor will then become who's been keeping up more with the
> latest technologies. Previous experience becomes much less important.
>
--
thx,
.V
roomity.com is the broadband portal <http://roomity.com/demo.jsp>
cell: 917 825 3035 in DFW
email: netsql at roomity.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Al Eridani <al...@gmail.com>.
> With IT, I've noticed that previous knowledge only helps slightly.
...
> Previous experience becomes much less important.
Not in my book. I wrote my first program in the 70s and over the years I've
seen people enter the field and make the same mistakes I had made a lot
earlier (as expected, as nobody is born knowledgeable already).
Also, there are many parallelisms between the current state of affairs and the
one from years ago. The useful thing is to see the patterns and avoid getting
mired in the details.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 9/10/2005 1:10 AM:
> * I took my own advice when *I* was in college :-), and have a Business
> Administration
> degree, with an emphasis in Accounting. You'd think (from the outside) that
> there couldn't
> possibly be a profession that changes slower than accounting, but I can
> guarantee you that
> this is not the case. Once you get past double entry bookkeeping, everything
> I learned in
> college (even if I remembered it all, 30 years later) would be totally
> obsolete.
>
> * The same sort of thing happens in scientific fields all over the map. For
> example,
> I aced a test on Astronomy by (among other things) nothing that Jupiter had
> 12 moons,
> Saturn had 9, and so on. Those facts were considered true at the time ...
> but not any more.
>
> * Would you trust a doctor today to diagnose you with a 1950s medical
> education?
> Or even a 1990s medical education? Like basically all professions, medicine
> (and software)
> assume that a lifetime of learning new things is a fundamental requirement
> for success.
Although the above is true, there is a big difference from the fields
you mention above and the IT field. Other professions build much more
upon previous knowledge and experience. Sure the doctor might learn new
techniques for performing open heart surgery, but I doubt he's throwing
away everything he learned previously about the heart. Even his
experience in performing surgery should increase over time.
With IT, I've noticed that previous knowledge only helps slightly. Yes,
a seasoned programmer will more valuable than someone right out of
college, yet once that college grad has about 5 years (maybe less)
experience, I would not say that he's necessarily any less valuable than
the programmer who has been programming for 10 or more years. The
deciding factor will then become who's been keeping up more with the
latest technologies. Previous experience becomes much less important.
With other professions I don't see this being the case as much. My
background is in biology (BS degree) and education (masters degree).
Even though in science things change at a rapid pace, previous
experience in the field is still highly valued. A new planet might be
discovered, but you are still working with the same old planets as well.
Same thing I'm sure can be said for most other professions. Things build
upon each other much more on other professions. Even if it's not pure
'fact type' knowledge, just basic experience in other profession is much
more valuable. A police officer, fireman, teacher, construction worker -
even in those fields just time itself in the profession can really have
a large impact in your skill and value.
Information Technology is very frustrating because certain things you
learn can be COMPLETELY thrown out in a very short while. Take for
instance something that hits home directly to me. I'm now in the process
of learning JSF. All the time spent learning struts and even JSTL is
basically thrown out the window if I end up coding with JSF. Same thing
would be said if I jumped over to .NET. I can't think of a profession
that throws away as much 'old' knowledge as the IT field.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Dakota Jack <da...@gmail.com>.
On 9/11/05, Ted Husted <te...@gmail.com> wrote:>
> Right now, our implementation is too much like a template and too
> little like a true chain.
That is because the template method was used first and the chain was
enlisted to fix this mistake. Had a strategy pattern been used in the
first place, this spaghetti would not be necessary.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/10/05, Murray Collingwood <mu...@focus-computing.com.au> wrote:
> I am very happy to contribute towards the development of Struts (since Craig invited
> me) however I'm still kinda new so I might not be much use for a while. So, here I am
> sticking up my virtual hand and asking "what would you like me to do?" as a volunteer
> does.
The first thing any prospective volunteer should do is review the "How
to Help" FAQ, which includes several concrete suggestions.
* http://struts.apache.org/faqs/helping.html
It would also be helpful, but not required, for newcomers to review
the How the ASF works pages.
* http://apache.org/foundation/how-it-works.html
and our project guidelines
* http://struts.apache.org/bylaws.html
A followup suggestion to the How to Help FAQ would be for someone to
review, apply, and report on some or all of the 22 enhancements with
patches. There's a link on the Roadmap page to the Bugzilla issues.
* http://struts.apache.org/roadmap.html#Bugzilla
A very helpful thing would be for someone to review the 252
outstanding Bugzilla enhancement sugggestions, and summarize them in
some way. We don't want to jettison them all, we just want to find
someway to handle the backlog gracefully. At this point, my only
suggestion is to extend the "Idea Jar" page.
* http://wiki.apache.org/struts/StrutsIdeaJar
Then perhaps we can work them into the Roadmap for Struts 1.7 and beyhond.
There are also several milestones on the roadmap that will need
coding. The next in line are the "experimental interfaces".
The elephant in the room is that our first crack at the new Request
Processing chain is no where near as slick as we would like. Someone
interested in that can start by reviewing the Commons CoR
documentation and code, the MailReader example in the sandbox, and the
Core 1.3 code.
* http://jakarta.apache.org/commons/chain/
* http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/mailreader-chain/?rev=280105
* http://svn.apache.org/viewcvs.cgi/struts/core/trunk/conf/java/chain-config.xml?view=markup
There are also some OnJava articles on Chain
* http://www.onjava.com/lpt/a/5671
* http://www.onjava.com/lpt/a/5693
Right now, our implementation is too much like a template and too
little like a true chain.
Struts Classic 1.3.x is built with Maven (maven.apache.org). I'm
working on the documentation updates now. In the meantime, there's a
Wiki page on the Maven build here:
* http://wiki.apache.org/struts/StrutsMaintenanceMaven
>
> Some of the responses we have had indicate that 'committers' are making direction
> decisions rather than the PMC. The role of the PMC is to control the project. It sounds
> from some responses that our 'committers' (some not all) have their own agendas and
> this is being accepted by the PMC. As a volunteer (contributor) I should be doing what
> the PMC ask me to, otherwise they aren't "in control" and I'm not really a volunteer.
The "How it works document" does say that "The PMC as a whole is the
entity that controls the project, nobody else.", but the PMC does
*not* control through delegation.
The PMC members *are* the committers. In the normal course, after a
committer has been active for six months or so, we will invite the
comitter to join the PMC (or explain why we are not). The goal of an
ASF project is for all the committers to be PMC members.
A guiding principle of the Apache Way is "them that do the work, make
the decisions". This phrase is actually a double-entendre. We do make
some decisions by voting (very few), but the real decisions are made
when a volunteer does the work. Otherwise, because we are a volunteer
organization, nothing actually happens.
Even when we vote, there is an implication of volunteering. If a PMC
member "vetos" a code change, the PMC member is obligated to produce a
sound technical reason *or* an alternate implementation. If neither of
these things happen, then the veto is not binding. Likewise, when we
vote +1 on a release, we are also pledging to actively support the
release by applying patches and answering questions. It's not about
having an opinion, it's about being ready, willing, and able to do the
work.
>
> SUMMARY
> --------------
> Maybe my view is a little altruistic or idealistic. I would like to see the PMC take control
> of the project and assign those tasks identified below (by Craig) to the volunteer
> developers that work on this project.
As mentioned, the PMC members *are* the volunteer developers that work
on this project. When a new volunteer starts submitting patches, and
conducting themselves well on the lists, after about six months, we
invite them to join us as a Committer. After another six months, a
Committer becomes a PMC member.
Committers volunteer for tasks as our schedules permit. If one of us
stops volunteering altogether for more than six months, then we change
that individual's status from "active" to "emeritus". If the
volunteer's schedule changes later, and they want to become active
again, we change their status back. (This just happened with David
Geary.)
What's important to remember is that contributing to a project is not
"work" for us. We have an itch, and contributing to the project helps
us scratch that itch. Experience has shown us that simply assigning
work to people doesn't scratch itches, at least not for long. People
have to want to do the task, and they have to volunteer to do it.
>
> Craig, if there is anything from your list you feel I could have a go at, please send it my
> way.
>
> Kind regards
> mc
>
> PS "Voting feet stuck perfectly where mouth is!" - attrib: me, just now
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Murray Collingwood <mu...@focus-computing.com.au>.
Hi folks
Firstly, please feel free to call me Murray (or Muz if you like to be informal). Being
referred to as the author makes me feel like I don't belong....and I do.
I guessed that there would be a volley of responses to my email but I want to make
Craig feel special because he didn't get all defensive in his answer - I appreciated that
Craig. I also want to thank Dakota who assumed (correctly) that I did know what I was
talking about.
I've been in IT for 25 years and been through the mill of Pascal, Basic, C, Assembler
(IBM/370), Easytrieve Plus, dBase, Java, Smalltalk, Javascript/DHTML and a myriad of
proprietary programming languages (I'm sure you understand what I mean). In 1998 I
wrote my own HTML pre-processor - at that time there was little knowledge of anything
called JSP or ASP. I have been using this technology for nearly 7 years.
Interestingly my HTML preprocessor included simple functions like if-else-endif, nested
includes, substitution tokens and a simple syntax that was consistent across the
products - stuff I miss in Struts. I also wrote the reference manual for using the
preprocessor. It was however proprietary and not feasable as an open source product.
I have since sold this technology to a company and decided rather than writing another
one I would hook up with a open source community project, and along came Struts.
I do understand the need to change technology every few years. I have been using
Struts 1.2.7 for just 3 months and am concerned that I should be now looking to learn
JSF/Shale. I know you will agree that changing technology after 3 months is not ideal,
however when I started I wasn't aware that Struts had been around for 5 years already.
I'm also picking up indications that these sub-projects (Shale, JSF, Ti, Tiles, etc) may
become part of the Struts package one day - this is a good thing.
I am very happy to contribute towards the development of Struts (since Craig invited
me) however I'm still kinda new so I might not be much use for a while. So, here I am
sticking up my virtual hand and asking "what would you like me to do?" as a volunteer
does.
Some of the responses we have had indicate that 'committers' are making direction
decisions rather than the PMC. The role of the PMC is to control the project. It sounds
from some responses that our 'committers' (some not all) have their own agendas and
this is being accepted by the PMC. As a volunteer (contributor) I should be doing what
the PMC ask me to, otherwise they aren't "in control" and I'm not really a volunteer.
SUMMARY
--------------
Maybe my view is a little altruistic or idealistic. I would like to see the PMC take control
of the project and assign those tasks identified below (by Craig) to the volunteer
developers that work on this project.
Craig, if there is anything from your list you feel I could have a go at, please send it my
way.
Kind regards
mc
PS "Voting feet stuck perfectly where mouth is!" - attrib: me, just now
On 10 Sep 2005 at 9:05, Craig McClanahan wrote:
> On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >
> > Craig McClanahan wrote:
> > > I hope you'll find my comments useful in furthering this kind of
> > discussion.
> > > But I'm starting from a different place than you ... I personally think
> > it
> > > is a waste of time to improve the tools and documentation support for a
> > five
> > > year old architecture that is definitely showing its age.
> >
> > Craig, I've heard you make this statement a couple of times... can you
> > go into some detail on where and how Struts is "showing its age"?
>
>
> Here's a couple of things that (had we known then what we know now) would
> very likely be different -- and areas where I think improvements would be
> helpful:
>
> * Actions as stateless singletons, instead of per-request instances
>
> * Form beans (should have done it the way WebWork does)
>
> * Extensibility of request processor (getting fixed in 1.3)
>
> * Action chaining is messed up.
>
> * Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing
>
> * Expression language syntax (based on BeanUtils) is way too limited
>
> * Totally dependent on Servlet API objects, making (a) unit tests hard,
> and (b) implementations on portlet difficult
>
> * Key functional areas (such as Tiles and Validator) can be
> pretty obtuse to configure
>
> * No model of user interface components -- just hard coded HTML rendering
>
> None of these things are totally unusable -- but they all need improvement.
>
> Craig
>
FOCUS Computing
Mob: 0415 24 26 24
murray@focus-computing.com.au
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to get the value of parent form field in child - logic:equal
Posted by "O. Oke" <re...@yahoo.co.uk>.
Frank,
Thanks for your advise.
I wish to look into the onLoad option that you
suggested, but please tell me, how to set the value
attribute of logic:equal to the value of the opening
form's field. For example, if
opener.forms[0].to_country.value has a value of UK,
how can I get this value (UK) to the value attribute
of logic:equal in formB?
Please note that fromB opens up as a pop up.
Thank you.
--- "Frank W. Zammetti" <fz...@omnytex.com> wrote:
> Laurie is of course correct. However, the other way
> you can do this is
> to have the script that you show here in the value
> attribute execute as
> a result of the onLoad event. That way you would
> not need to pass the
> information through with the request.
>
> The flow of what happens in that case is basically:
>
> (1) Some event on the page with formA occurs, either
> some Javascript
> that opens a new window, or a form submission
> targeted to a new window
>
> (2) The request is processed on the server and the
> page with formB is
> rendered, but with no values set.
>
> (3) The page with formB on it is returned to the
> client and shown in a
> new window.
>
> (4) Event onLoad fires executing the script which
> copies the values from
> the parent to the child.
>
> This is actually a fairly typical way of doing this,
> it's up to you
> whether you prefer the more client-side approach of
> this or the more
> server-side approach as Laurie suggests. I wouldn't
> say either is
> drastically better than the other.
>
> Frank
>
> Laurie Harper wrote:
> > You're trying to mix JSP syntax, which is
> processed on the server before
> > the page is sent to the browser, with Javascript,
> which is processed by
> > the browser after the page is sent. You can't do
> that.
> >
> > What you'll need to do is, when formA opens formB
> (presumably by
> > submitting an HTTP request), include the
> information you need from formA
> > as request parameters formB can then access during
> rendering.
> >
> > L.
> >
> > O. Oke wrote:
> >
> >> Help please!
> >>
> >> BACKGROUND
> >> ==========
> >> A parent window/form - formA opens up formB. In
> >> formB, I am using logic:equal. In the value
> attribute
> >> of logic:equal, I want to dynamically get the
> current
> >> value of a field in formA - opener.
> >>
> >> PART OF SOURCE CODE
> >> ===================
> >> <logic:equal name="repBranch"
> property="country_id"
> >> value=opener.forms[0].to_country.value>
> >>
> >>
> >> PROBLEM
> >> =======
> >> None of the lines below (value attribute of
> >> logic:equal) work:
> >> value=opener.forms[0].to_country.value
> >> value="opener.forms[0].to_country.value"
> >> value='opener.forms[0].to_country.value'
> >> value=javascript:opener.forms[0].to_country.value
> >>
> value="javascript:opener.forms[0].to_country.value"
> >>
> value='javascript:opener.forms[0].to_country.value'
> >>
> >> The only time it works is when the value is
> hardcoded
> >> i.e. value="UK"
> >>
> >> I do not want to hard code the country name,
> because
> >> it is not always UK.
> >>
> >>
> >> Please tell me how to proceed...
> >>
> >> Thank you.
> >>
> >> O. Oke
> >>
> >>
> >>
> >>
> >>
> >>
>
___________________________________________________________
> Yahoo!
> >> Messenger - NEW crystal clear PC to PC calling
> worldwide with
> >> voicemail http://uk.messenger.yahoo.com
> >
> >
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> > For additional commands, e-mail:
> user-help@struts.apache.org
> >
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> user-help@struts.apache.org
>
>
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to get the value of parent form field in child - logic:equal
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Laurie is of course correct. However, the other way you can do this is
to have the script that you show here in the value attribute execute as
a result of the onLoad event. That way you would not need to pass the
information through with the request.
The flow of what happens in that case is basically:
(1) Some event on the page with formA occurs, either some Javascript
that opens a new window, or a form submission targeted to a new window
(2) The request is processed on the server and the page with formB is
rendered, but with no values set.
(3) The page with formB on it is returned to the client and shown in a
new window.
(4) Event onLoad fires executing the script which copies the values from
the parent to the child.
This is actually a fairly typical way of doing this, it's up to you
whether you prefer the more client-side approach of this or the more
server-side approach as Laurie suggests. I wouldn't say either is
drastically better than the other.
Frank
Laurie Harper wrote:
> You're trying to mix JSP syntax, which is processed on the server before
> the page is sent to the browser, with Javascript, which is processed by
> the browser after the page is sent. You can't do that.
>
> What you'll need to do is, when formA opens formB (presumably by
> submitting an HTTP request), include the information you need from formA
> as request parameters formB can then access during rendering.
>
> L.
>
> O. Oke wrote:
>
>> Help please!
>>
>> BACKGROUND
>> ==========
>> A parent window/form - formA opens up formB. In
>> formB, I am using logic:equal. In the value attribute
>> of logic:equal, I want to dynamically get the current
>> value of a field in formA - opener.
>>
>> PART OF SOURCE CODE
>> ===================
>> <logic:equal name="repBranch" property="country_id"
>> value=opener.forms[0].to_country.value>
>>
>>
>> PROBLEM
>> =======
>> None of the lines below (value attribute of
>> logic:equal) work:
>> value=opener.forms[0].to_country.value
>> value="opener.forms[0].to_country.value"
>> value='opener.forms[0].to_country.value'
>> value=javascript:opener.forms[0].to_country.value
>> value="javascript:opener.forms[0].to_country.value"
>> value='javascript:opener.forms[0].to_country.value'
>>
>> The only time it works is when the value is hardcoded
>> i.e. value="UK"
>>
>> I do not want to hard code the country name, because
>> it is not always UK.
>>
>>
>> Please tell me how to proceed...
>>
>> Thank you.
>>
>> O. Oke
>>
>>
>>
>>
>>
>> ___________________________________________________________ Yahoo!
>> Messenger - NEW crystal clear PC to PC calling worldwide with
>> voicemail http://uk.messenger.yahoo.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to get the value of parent form field in child - logic:equal
Posted by "O. Oke" <re...@yahoo.co.uk>.
Thanks for your response, I have taken note of your
points.
Please note, formB is actually opened as a popup - I
should have mentioned this.
--- Laurie Harper <la...@holoweb.net> wrote:
> You're trying to mix JSP syntax, which is processed
> on the server before
> the page is sent to the browser, with Javascript,
> which is processed by
> the browser after the page is sent. You can't do
> that.
>
> What you'll need to do is, when formA opens formB
> (presumably by
> submitting an HTTP request), include the information
> you need from formA
> as request parameters formB can then access during
> rendering.
>
> L.
>
> O. Oke wrote:
> > Help please!
> >
> > BACKGROUND
> > ==========
> > A parent window/form - formA opens up formB. In
> > formB, I am using logic:equal. In the value
> attribute
> > of logic:equal, I want to dynamically get the
> current
> > value of a field in formA - opener.
> >
> > PART OF SOURCE CODE
> > ===================
> > <logic:equal name="repBranch"
> property="country_id"
> > value=opener.forms[0].to_country.value>
> >
> >
> > PROBLEM
> > =======
> > None of the lines below (value attribute of
> > logic:equal) work:
> > value=opener.forms[0].to_country.value
> > value="opener.forms[0].to_country.value"
> > value='opener.forms[0].to_country.value'
> > value=javascript:opener.forms[0].to_country.value
> >
> value="javascript:opener.forms[0].to_country.value"
> >
> value='javascript:opener.forms[0].to_country.value'
> >
> > The only time it works is when the value is
> hardcoded
> > i.e.
> > value="UK"
> >
> > I do not want to hard code the country name,
> because
> > it is not always UK.
> >
> >
> > Please tell me how to proceed...
> >
> > Thank you.
> >
> > O. Oke
> >
> >
> >
> >
> >
> >
>
___________________________________________________________
>
> > Yahoo! Messenger - NEW crystal clear PC to PC
> calling worldwide with voicemail
> http://uk.messenger.yahoo.com
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> user-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> user-help@struts.apache.org
>
>
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: How to get the value of parent form field in child - logic:equal
Posted by Laurie Harper <la...@holoweb.net>.
You're trying to mix JSP syntax, which is processed on the server before
the page is sent to the browser, with Javascript, which is processed by
the browser after the page is sent. You can't do that.
What you'll need to do is, when formA opens formB (presumably by
submitting an HTTP request), include the information you need from formA
as request parameters formB can then access during rendering.
L.
O. Oke wrote:
> Help please!
>
> BACKGROUND
> ==========
> A parent window/form - formA opens up formB. In
> formB, I am using logic:equal. In the value attribute
> of logic:equal, I want to dynamically get the current
> value of a field in formA - opener.
>
> PART OF SOURCE CODE
> ===================
> <logic:equal name="repBranch" property="country_id"
> value=opener.forms[0].to_country.value>
>
>
> PROBLEM
> =======
> None of the lines below (value attribute of
> logic:equal) work:
> value=opener.forms[0].to_country.value
> value="opener.forms[0].to_country.value"
> value='opener.forms[0].to_country.value'
> value=javascript:opener.forms[0].to_country.value
> value="javascript:opener.forms[0].to_country.value"
> value='javascript:opener.forms[0].to_country.value'
>
> The only time it works is when the value is hardcoded
> i.e.
> value="UK"
>
> I do not want to hard code the country name, because
> it is not always UK.
>
>
> Please tell me how to proceed...
>
> Thank you.
>
> O. Oke
>
>
>
>
>
> ___________________________________________________________
> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
How to get the value of parent form field in child - logic:equal
Posted by "O. Oke" <re...@yahoo.co.uk>.
Help please!
BACKGROUND
==========
A parent window/form - formA opens up formB. In
formB, I am using logic:equal. In the value attribute
of logic:equal, I want to dynamically get the current
value of a field in formA - opener.
PART OF SOURCE CODE
===================
<logic:equal name="repBranch" property="country_id"
value=opener.forms[0].to_country.value>
PROBLEM
=======
None of the lines below (value attribute of
logic:equal) work:
value=opener.forms[0].to_country.value
value="opener.forms[0].to_country.value"
value='opener.forms[0].to_country.value'
value=javascript:opener.forms[0].to_country.value
value="javascript:opener.forms[0].to_country.value"
value='javascript:opener.forms[0].to_country.value'
The only time it works is when the value is hardcoded
i.e.
value="UK"
I do not want to hard code the country name, because
it is not always UK.
Please tell me how to proceed...
Thank you.
O. Oke
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/10/05, Leon Rosenberg <st...@anotheria.net> wrote:
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Craig McClanahan [mailto:craigmcc@gmail.com]
> > Gesendet: Samstag, 10. September 2005 18:06
> > An: Struts Users Mailing List; fzlists@omnytex.com
> > Betreff: Re: Who decides?
> >
> > Here's a couple of things that (had we known then what we
> > know now) would very likely be different -- and areas where I
> > think improvements would be
> > helpful:
> >
> > * Actions as stateless singletons, instead of per-request instances
>
> I think they 'de facto' are stateless singletons? I mean the controller
> only
> creates one instance, and you shouldn't create another :-)
Well, you can certainly make your custom RequestProcessor do this as well
... but nearly every successful developer using Struts has had it pounded
into their heads that you shouldn't use instance variables in an Action to
store per-request state.
Creating an Action per request also still doesn't let you eliminate form
beans and just use properties on the Action instance itself (the way
WebWork, Tapestry, and JSF like you to do).
> * Expression language syntax (based on BeanUtils) is way too limited
>
> For those who need it :-)
The conciseness and power of using expression language based manipulations,
especially when it can do dependency injection style bean creation the way
JSF managed beans work "for free", and even when you're programming your
actions in Java, is one of the hidden jewels that remains for many
developers to discover :-).
>
> > * Totally dependent on Servlet API objects, making (a) unit
> > tests hard, and (b) implementations on portlet difficult
>
> I think it's the nature of a http framework?
Nope ... it's the nature of an http framework that was designed before
portlets existed. JSF, for one, goes to great pains to hide the differences
between the two environments. The same result should be possible with pretty
much any architectural strategy that passes a context object around ... just
make sure the context object has accessors to get to the abstract idea of a
"request parameter" (and so on), without being coded directly to the servlet
or portlet API. In the Commons Chain world, for example, that's why the
WebContext abstraction exists.
...
>
> Regards
> Leon
Craig
PS: No, it's not really 5 in the morning where I am ... just arrived in
Bejing for the Java China conference going on this week , and it's 8pm here.
But you're not very likely to see me participating in conversations in
semi-real-time this week :-).
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
As my wife likes to say, cool beans :)
Frank
Ted Husted wrote:
> Speaking for myself, yes.
>
> On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Ted, I read what you wrote here with interest. I consider myself a
>>champion of backwards compatibility... in fact, within the past month I
>>recall being involved in a discussion thread here where I seemed to be
>>the only one saying backwards compatibility should not be broken, within
>>the context of that discussion (which, to be honest, I do not recall :)
>>). I completely agree that it is an important consideration always.
>>
>>What I infer from what you wrote, and please correct me if the inference
>>is not accurate, is that the milestone of breaking things out into
>>subprojects could in essence serve to open the floodgates a bit...
>>meaning, maybe the committers will be more willing to entertain some
>>ideas that they may have previously passed on once that reorganization
>>is complete and "in the wild" because it will theoretically be easier to
>>do them then. Is that a fair assessment?
>>
>>If so, I for one look forward to the 1.3 release even more than I did
>>before :)
>>
>>Frank
>>
>>Ted Husted wrote:
>>
>>>On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>>>
>>>
>>>>Over the past few months there have been a number of people who have
>>>>attempted to evolve Struts to "catch up" in some ways with what other
>>>>frameworks are doing. They have been turned away, sometimes for
>>>>obviously legitimate reasons, sometimes for more debatable ones.
>>>
>>>
>>>Usually, the problem has been retaining backward compatibility. When a
>>>suggestion breaks backward compatibility, we tend to pass, at least
>>>until we can setup a deprecate/ remove/ release cycle. Since this
>>>cycle can take a year or more, some people drift away before we can
>>>implement a suggestion.
>>>
>>>Some suggestions have been out of scope, mainly for the taglibs. Along
>>>the way we decided that the original taglibs should stick to the HTML
>>>4.1 specification. Some taglib suggestions are non-starters because of
>>>the product's scope.
>>>
>>>The big fix for both of these problems, and several others, is to
>>>subdivide the one-size-must-fit-all Struts distribution into
>>>subprojects. If a suggestion is not backwardly compatible, then
>>>perhaps we can make it an optional component in the Extras subproject.
>>>If a taglib is not HTML 4.1 compliant, then maybe we can start another
>>>taglib subproject.
>>>
>>>But, until last month, we simply didn't have the infrastructure to
>>>even consider such things.
>>>
>>>Another problem is being sure that there be someone around to maintain
>>>the code. We like to see broad enough support for any suggestion to
>>>ensure that there will be at least three people around who will
>>>support the code. It doesn't matter if comes from a developer or a
>>>committer. A lot of suggestions from committers die on the vine
>>>because too few people seem interested.
>>>
>>>Many folks don't realize that extensions we now take for granted, like
>>>Validator and Tiles, were being used in production applications for
>>>*years* before we added them to the distribution. (I used both myself
>>>in April 2001, before Struts 1.0 final.)
>>>
>>>In the same light, I expect we will see an Ajax subproject for Apache
>>>Struts one day. But before that happens, we'd like to see broad
>>>support for Ajax among Struts users. Then, we can be sure there will
>>>be committers around to support the subproject later.
>>>
>>>As it stands, we are just now completing tasks we planned *18 months*
>>>ago. But, we are completing them, slow and steady.
>>>
>>>In fact, I remember Don Brown making the first "subproject
>>>reorganization" commits at ApacheCon 2004 last November. Martin and I
>>>were sitting at a table with him at the Hackathon, jovially giving Don
>>>verbal +1s. :)
>>>
>>>Ten months later, we're finally at the point where we can build and
>>>distribute the original Struts subprojects, along with the new kids on
>>>the block, Flow, Scripting, and Shale.
>>>
>>>
>>>
>>>>Everyone seems to want to go off and create something entirely new when
>>>>I haven't seen a single good, concrete reason why Struts as it exists
>>>>today can't be evolved. Why?
>>>
>>>
>>>It *is* being evolved. It's just that evolution takes time.
>>>Personally, I still fully intend to walk down the Struts Classic
>>>Roadmap that we posted over a year ago. We're just now hitting the
>>>first milestone: subprojects. We hit this one, and we'll hit the
>>>others too.
>>>
>>>* http://struts.apache.org/roadmap.html
>>>
>>>Meanwhile, exploring alternatives like Ti can be good for Struts
>>>Classic too. Like as not, there will be techniques used in Ti that we
>>>can retrofit to Struts Classic. And, perhaps, one day, they might even
>>>evolve into the same product. Or not. At this point, Ti is still
>>>hypotethical.
>>>
>>>
>>>
>>>>Many of the things that people claim to want in a modern framework I
>>>>have either myself done or seen done with the current Struts codebase.
>>>>Things like components that remember and render their own state ala JSF,
>>>>a simple managed bean facility (IoC), built-in AJAX support, something
>>>>akin to a prerender facility, the work of Michael Jouravlev, all of
>>>>these things have been done in Struts, so clearly it is not a case of
>>>>Struts not being expandable or "fixable". Why is there so much seeming
>>>>resistance to doing this I wonder?
>>>
>>>
>>>It's not resistance, it's as you say: If we want to, we can already do
>>>all of this now in our own applications. I expect that many of us are.
>>>But, going the extra yard and making what we do for ourselves
>>>available to everyone is a lot of work. We're doing the work, but it's
>>>on a time available basis, and most of us have very little time
>>>available. Unlike some open source projects, we don't have any
>>>committers who are paid to work on Struts during company time.
>>>
>>>Because committers tend to have busy professional lives, we try to
>>>bring on new committers whenever we can. Last month, we brought on
>>>Wendy Smoak, who has been a godsend. With help from James, She's
>>>propelled the Mavenized web sites forward, and we can see the light at
>>>the end of the tunnel.
>>>
>>>Meanwhlile, after adding the "extends" feature, our other new hand,
>>>Hubert, cleaned up the stale deprecations, so we can continue to
>>>steadily evolve the codebase. Now, it's left to me to finish
>>>refactoring the documentation, and push Struts Classic 1.3.0 out the
>>>door. It won't be a final release, but it will tap the keg.
>>>
>>>Once we have a 1.3.0 distribution out for review, I plan to review the
>>>22 enhancement tickets with patches, and apply as many as we can.
>>>
>>>If someone wanted to preview those patches, and post a summary to
>>>dev@, that would be helpful. There are prefab bugzilla query links on
>>>the RoadMap page.
>>>
>>>* http://struts.apache.org/roadmap.html#Bugzilla
>>>
>>>There's a wiki page already setup for 1.3.1, and we can start making
>>>notes on what to do about these other outstanding contributions.
>>>
>>>* http://wiki.apache.org/struts/StrutsClassicRelease131
>>>
>>>-Ted.
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>--
>>Frank W. Zammetti
>>Founder and Chief Software Architect
>>Omnytex Technologies
>>http://www.omnytex.com
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Ted Husted <te...@gmail.com>.
Speaking for myself, yes.
On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Ted, I read what you wrote here with interest. I consider myself a
> champion of backwards compatibility... in fact, within the past month I
> recall being involved in a discussion thread here where I seemed to be
> the only one saying backwards compatibility should not be broken, within
> the context of that discussion (which, to be honest, I do not recall :)
> ). I completely agree that it is an important consideration always.
>
> What I infer from what you wrote, and please correct me if the inference
> is not accurate, is that the milestone of breaking things out into
> subprojects could in essence serve to open the floodgates a bit...
> meaning, maybe the committers will be more willing to entertain some
> ideas that they may have previously passed on once that reorganization
> is complete and "in the wild" because it will theoretically be easier to
> do them then. Is that a fair assessment?
>
> If so, I for one look forward to the 1.3 release even more than I did
> before :)
>
> Frank
>
> Ted Husted wrote:
> > On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >
> >>Over the past few months there have been a number of people who have
> >>attempted to evolve Struts to "catch up" in some ways with what other
> >>frameworks are doing. They have been turned away, sometimes for
> >>obviously legitimate reasons, sometimes for more debatable ones.
> >
> >
> > Usually, the problem has been retaining backward compatibility. When a
> > suggestion breaks backward compatibility, we tend to pass, at least
> > until we can setup a deprecate/ remove/ release cycle. Since this
> > cycle can take a year or more, some people drift away before we can
> > implement a suggestion.
> >
> > Some suggestions have been out of scope, mainly for the taglibs. Along
> > the way we decided that the original taglibs should stick to the HTML
> > 4.1 specification. Some taglib suggestions are non-starters because of
> > the product's scope.
> >
> > The big fix for both of these problems, and several others, is to
> > subdivide the one-size-must-fit-all Struts distribution into
> > subprojects. If a suggestion is not backwardly compatible, then
> > perhaps we can make it an optional component in the Extras subproject.
> > If a taglib is not HTML 4.1 compliant, then maybe we can start another
> > taglib subproject.
> >
> > But, until last month, we simply didn't have the infrastructure to
> > even consider such things.
> >
> > Another problem is being sure that there be someone around to maintain
> > the code. We like to see broad enough support for any suggestion to
> > ensure that there will be at least three people around who will
> > support the code. It doesn't matter if comes from a developer or a
> > committer. A lot of suggestions from committers die on the vine
> > because too few people seem interested.
> >
> > Many folks don't realize that extensions we now take for granted, like
> > Validator and Tiles, were being used in production applications for
> > *years* before we added them to the distribution. (I used both myself
> > in April 2001, before Struts 1.0 final.)
> >
> > In the same light, I expect we will see an Ajax subproject for Apache
> > Struts one day. But before that happens, we'd like to see broad
> > support for Ajax among Struts users. Then, we can be sure there will
> > be committers around to support the subproject later.
> >
> > As it stands, we are just now completing tasks we planned *18 months*
> > ago. But, we are completing them, slow and steady.
> >
> > In fact, I remember Don Brown making the first "subproject
> > reorganization" commits at ApacheCon 2004 last November. Martin and I
> > were sitting at a table with him at the Hackathon, jovially giving Don
> > verbal +1s. :)
> >
> > Ten months later, we're finally at the point where we can build and
> > distribute the original Struts subprojects, along with the new kids on
> > the block, Flow, Scripting, and Shale.
> >
> >
> >>Everyone seems to want to go off and create something entirely new when
> >>I haven't seen a single good, concrete reason why Struts as it exists
> >>today can't be evolved. Why?
> >
> >
> > It *is* being evolved. It's just that evolution takes time.
> > Personally, I still fully intend to walk down the Struts Classic
> > Roadmap that we posted over a year ago. We're just now hitting the
> > first milestone: subprojects. We hit this one, and we'll hit the
> > others too.
> >
> > * http://struts.apache.org/roadmap.html
> >
> > Meanwhile, exploring alternatives like Ti can be good for Struts
> > Classic too. Like as not, there will be techniques used in Ti that we
> > can retrofit to Struts Classic. And, perhaps, one day, they might even
> > evolve into the same product. Or not. At this point, Ti is still
> > hypotethical.
> >
> >
> >>Many of the things that people claim to want in a modern framework I
> >>have either myself done or seen done with the current Struts codebase.
> >>Things like components that remember and render their own state ala JSF,
> >>a simple managed bean facility (IoC), built-in AJAX support, something
> >>akin to a prerender facility, the work of Michael Jouravlev, all of
> >>these things have been done in Struts, so clearly it is not a case of
> >>Struts not being expandable or "fixable". Why is there so much seeming
> >>resistance to doing this I wonder?
> >
> >
> > It's not resistance, it's as you say: If we want to, we can already do
> > all of this now in our own applications. I expect that many of us are.
> > But, going the extra yard and making what we do for ourselves
> > available to everyone is a lot of work. We're doing the work, but it's
> > on a time available basis, and most of us have very little time
> > available. Unlike some open source projects, we don't have any
> > committers who are paid to work on Struts during company time.
> >
> > Because committers tend to have busy professional lives, we try to
> > bring on new committers whenever we can. Last month, we brought on
> > Wendy Smoak, who has been a godsend. With help from James, She's
> > propelled the Mavenized web sites forward, and we can see the light at
> > the end of the tunnel.
> >
> > Meanwhlile, after adding the "extends" feature, our other new hand,
> > Hubert, cleaned up the stale deprecations, so we can continue to
> > steadily evolve the codebase. Now, it's left to me to finish
> > refactoring the documentation, and push Struts Classic 1.3.0 out the
> > door. It won't be a final release, but it will tap the keg.
> >
> > Once we have a 1.3.0 distribution out for review, I plan to review the
> > 22 enhancement tickets with patches, and apply as many as we can.
> >
> > If someone wanted to preview those patches, and post a summary to
> > dev@, that would be helpful. There are prefab bugzilla query links on
> > the RoadMap page.
> >
> > * http://struts.apache.org/roadmap.html#Bugzilla
> >
> > There's a wiki page already setup for 1.3.1, and we can start making
> > notes on what to do about these other outstanding contributions.
> >
> > * http://wiki.apache.org/struts/StrutsClassicRelease131
> >
> > -Ted.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
> >
> >
> >
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
--
HTH, Ted.
http://www.husted.com/poe/
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ted, I read what you wrote here with interest. I consider myself a
champion of backwards compatibility... in fact, within the past month I
recall being involved in a discussion thread here where I seemed to be
the only one saying backwards compatibility should not be broken, within
the context of that discussion (which, to be honest, I do not recall :)
). I completely agree that it is an important consideration always.
What I infer from what you wrote, and please correct me if the inference
is not accurate, is that the milestone of breaking things out into
subprojects could in essence serve to open the floodgates a bit...
meaning, maybe the committers will be more willing to entertain some
ideas that they may have previously passed on once that reorganization
is complete and "in the wild" because it will theoretically be easier to
do them then. Is that a fair assessment?
If so, I for one look forward to the 1.3 release even more than I did
before :)
Frank
Ted Husted wrote:
> On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Over the past few months there have been a number of people who have
>>attempted to evolve Struts to "catch up" in some ways with what other
>>frameworks are doing. They have been turned away, sometimes for
>>obviously legitimate reasons, sometimes for more debatable ones.
>
>
> Usually, the problem has been retaining backward compatibility. When a
> suggestion breaks backward compatibility, we tend to pass, at least
> until we can setup a deprecate/ remove/ release cycle. Since this
> cycle can take a year or more, some people drift away before we can
> implement a suggestion.
>
> Some suggestions have been out of scope, mainly for the taglibs. Along
> the way we decided that the original taglibs should stick to the HTML
> 4.1 specification. Some taglib suggestions are non-starters because of
> the product's scope.
>
> The big fix for both of these problems, and several others, is to
> subdivide the one-size-must-fit-all Struts distribution into
> subprojects. If a suggestion is not backwardly compatible, then
> perhaps we can make it an optional component in the Extras subproject.
> If a taglib is not HTML 4.1 compliant, then maybe we can start another
> taglib subproject.
>
> But, until last month, we simply didn't have the infrastructure to
> even consider such things.
>
> Another problem is being sure that there be someone around to maintain
> the code. We like to see broad enough support for any suggestion to
> ensure that there will be at least three people around who will
> support the code. It doesn't matter if comes from a developer or a
> committer. A lot of suggestions from committers die on the vine
> because too few people seem interested.
>
> Many folks don't realize that extensions we now take for granted, like
> Validator and Tiles, were being used in production applications for
> *years* before we added them to the distribution. (I used both myself
> in April 2001, before Struts 1.0 final.)
>
> In the same light, I expect we will see an Ajax subproject for Apache
> Struts one day. But before that happens, we'd like to see broad
> support for Ajax among Struts users. Then, we can be sure there will
> be committers around to support the subproject later.
>
> As it stands, we are just now completing tasks we planned *18 months*
> ago. But, we are completing them, slow and steady.
>
> In fact, I remember Don Brown making the first "subproject
> reorganization" commits at ApacheCon 2004 last November. Martin and I
> were sitting at a table with him at the Hackathon, jovially giving Don
> verbal +1s. :)
>
> Ten months later, we're finally at the point where we can build and
> distribute the original Struts subprojects, along with the new kids on
> the block, Flow, Scripting, and Shale.
>
>
>>Everyone seems to want to go off and create something entirely new when
>>I haven't seen a single good, concrete reason why Struts as it exists
>>today can't be evolved. Why?
>
>
> It *is* being evolved. It's just that evolution takes time.
> Personally, I still fully intend to walk down the Struts Classic
> Roadmap that we posted over a year ago. We're just now hitting the
> first milestone: subprojects. We hit this one, and we'll hit the
> others too.
>
> * http://struts.apache.org/roadmap.html
>
> Meanwhile, exploring alternatives like Ti can be good for Struts
> Classic too. Like as not, there will be techniques used in Ti that we
> can retrofit to Struts Classic. And, perhaps, one day, they might even
> evolve into the same product. Or not. At this point, Ti is still
> hypotethical.
>
>
>>Many of the things that people claim to want in a modern framework I
>>have either myself done or seen done with the current Struts codebase.
>>Things like components that remember and render their own state ala JSF,
>>a simple managed bean facility (IoC), built-in AJAX support, something
>>akin to a prerender facility, the work of Michael Jouravlev, all of
>>these things have been done in Struts, so clearly it is not a case of
>>Struts not being expandable or "fixable". Why is there so much seeming
>>resistance to doing this I wonder?
>
>
> It's not resistance, it's as you say: If we want to, we can already do
> all of this now in our own applications. I expect that many of us are.
> But, going the extra yard and making what we do for ourselves
> available to everyone is a lot of work. We're doing the work, but it's
> on a time available basis, and most of us have very little time
> available. Unlike some open source projects, we don't have any
> committers who are paid to work on Struts during company time.
>
> Because committers tend to have busy professional lives, we try to
> bring on new committers whenever we can. Last month, we brought on
> Wendy Smoak, who has been a godsend. With help from James, She's
> propelled the Mavenized web sites forward, and we can see the light at
> the end of the tunnel.
>
> Meanwhlile, after adding the "extends" feature, our other new hand,
> Hubert, cleaned up the stale deprecations, so we can continue to
> steadily evolve the codebase. Now, it's left to me to finish
> refactoring the documentation, and push Struts Classic 1.3.0 out the
> door. It won't be a final release, but it will tap the keg.
>
> Once we have a 1.3.0 distribution out for review, I plan to review the
> 22 enhancement tickets with patches, and apply as many as we can.
>
> If someone wanted to preview those patches, and post a summary to
> dev@, that would be helpful. There are prefab bugzilla query links on
> the RoadMap page.
>
> * http://struts.apache.org/roadmap.html#Bugzilla
>
> There's a wiki page already setup for 1.3.1, and we can start making
> notes on what to do about these other outstanding contributions.
>
> * http://wiki.apache.org/struts/StrutsClassicRelease131
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Ted Husted <te...@gmail.com>.
On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Over the past few months there have been a number of people who have
> attempted to evolve Struts to "catch up" in some ways with what other
> frameworks are doing. They have been turned away, sometimes for
> obviously legitimate reasons, sometimes for more debatable ones.
Usually, the problem has been retaining backward compatibility. When a
suggestion breaks backward compatibility, we tend to pass, at least
until we can setup a deprecate/ remove/ release cycle. Since this
cycle can take a year or more, some people drift away before we can
implement a suggestion.
Some suggestions have been out of scope, mainly for the taglibs. Along
the way we decided that the original taglibs should stick to the HTML
4.1 specification. Some taglib suggestions are non-starters because of
the product's scope.
The big fix for both of these problems, and several others, is to
subdivide the one-size-must-fit-all Struts distribution into
subprojects. If a suggestion is not backwardly compatible, then
perhaps we can make it an optional component in the Extras subproject.
If a taglib is not HTML 4.1 compliant, then maybe we can start another
taglib subproject.
But, until last month, we simply didn't have the infrastructure to
even consider such things.
Another problem is being sure that there be someone around to maintain
the code. We like to see broad enough support for any suggestion to
ensure that there will be at least three people around who will
support the code. It doesn't matter if comes from a developer or a
committer. A lot of suggestions from committers die on the vine
because too few people seem interested.
Many folks don't realize that extensions we now take for granted, like
Validator and Tiles, were being used in production applications for
*years* before we added them to the distribution. (I used both myself
in April 2001, before Struts 1.0 final.)
In the same light, I expect we will see an Ajax subproject for Apache
Struts one day. But before that happens, we'd like to see broad
support for Ajax among Struts users. Then, we can be sure there will
be committers around to support the subproject later.
As it stands, we are just now completing tasks we planned *18 months*
ago. But, we are completing them, slow and steady.
In fact, I remember Don Brown making the first "subproject
reorganization" commits at ApacheCon 2004 last November. Martin and I
were sitting at a table with him at the Hackathon, jovially giving Don
verbal +1s. :)
Ten months later, we're finally at the point where we can build and
distribute the original Struts subprojects, along with the new kids on
the block, Flow, Scripting, and Shale.
> Everyone seems to want to go off and create something entirely new when
> I haven't seen a single good, concrete reason why Struts as it exists
> today can't be evolved. Why?
It *is* being evolved. It's just that evolution takes time.
Personally, I still fully intend to walk down the Struts Classic
Roadmap that we posted over a year ago. We're just now hitting the
first milestone: subprojects. We hit this one, and we'll hit the
others too.
* http://struts.apache.org/roadmap.html
Meanwhile, exploring alternatives like Ti can be good for Struts
Classic too. Like as not, there will be techniques used in Ti that we
can retrofit to Struts Classic. And, perhaps, one day, they might even
evolve into the same product. Or not. At this point, Ti is still
hypotethical.
>
> Many of the things that people claim to want in a modern framework I
> have either myself done or seen done with the current Struts codebase.
> Things like components that remember and render their own state ala JSF,
> a simple managed bean facility (IoC), built-in AJAX support, something
> akin to a prerender facility, the work of Michael Jouravlev, all of
> these things have been done in Struts, so clearly it is not a case of
> Struts not being expandable or "fixable". Why is there so much seeming
> resistance to doing this I wonder?
It's not resistance, it's as you say: If we want to, we can already do
all of this now in our own applications. I expect that many of us are.
But, going the extra yard and making what we do for ourselves
available to everyone is a lot of work. We're doing the work, but it's
on a time available basis, and most of us have very little time
available. Unlike some open source projects, we don't have any
committers who are paid to work on Struts during company time.
Because committers tend to have busy professional lives, we try to
bring on new committers whenever we can. Last month, we brought on
Wendy Smoak, who has been a godsend. With help from James, She's
propelled the Mavenized web sites forward, and we can see the light at
the end of the tunnel.
Meanwhlile, after adding the "extends" feature, our other new hand,
Hubert, cleaned up the stale deprecations, so we can continue to
steadily evolve the codebase. Now, it's left to me to finish
refactoring the documentation, and push Struts Classic 1.3.0 out the
door. It won't be a final release, but it will tap the keg.
Once we have a 1.3.0 distribution out for review, I plan to review the
22 enhancement tickets with patches, and apply as many as we can.
If someone wanted to preview those patches, and post a summary to
dev@, that would be helpful. There are prefab bugzilla query links on
the RoadMap page.
* http://struts.apache.org/roadmap.html#Bugzilla
There's a wiki page already setup for 1.3.1, and we can start making
notes on what to do about these other outstanding contributions.
* http://wiki.apache.org/struts/StrutsClassicRelease131
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Cool, thanks Craig. It might amaze you to hear that not a single one of
those items I really disagree with :)
I was in the middle of composing a big, grandious new message, but I
think I can ask a single question here that really sums up all that I
was writing there...
Of this list, I don't see a single thing that can't be done in current
Struts. Admittedly some are not as easy as others, but none of it, as
far as I can tell, is undoable. So, the question is, why don't we? Not
you specifically Craig, I know your off on your own crusade :) Just a
general question for everyone else.
Over the past few months there have been a number of people who have
attempted to evolve Struts to "catch up" in some ways with what other
frameworks are doing. They have been turned away, sometimes for
obviously legitimate reasons, sometimes for more debatable ones.
Everyone seems to want to go off and create something entirely new when
I haven't seen a single good, concrete reason why Struts as it exists
today can't be evolved. Why?
Many of the things that people claim to want in a modern framework I
have either myself done or seen done with the current Struts codebase.
Things like components that remember and render their own state ala JSF,
a simple managed bean facility (IoC), built-in AJAX support, something
akin to a prerender facility, the work of Michael Jouravlev, all of
these things have been done in Struts, so clearly it is not a case of
Struts not being expandable or "fixable". Why is there so much seeming
resistance to doing this I wonder?
Frank
Craig McClanahan wrote:
> On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>>Craig McClanahan wrote:
>>
>>>I hope you'll find my comments useful in furthering this kind of
>>
>>discussion.
>>
>>>But I'm starting from a different place than you ... I personally think
>>
>>it
>>
>>>is a waste of time to improve the tools and documentation support for a
>>
>>five
>>
>>>year old architecture that is definitely showing its age.
>>
>>Craig, I've heard you make this statement a couple of times... can you
>>go into some detail on where and how Struts is "showing its age"?
>
>
>
> Here's a couple of things that (had we known then what we know now) would
> very likely be different -- and areas where I think improvements would be
> helpful:
>
> * Actions as stateless singletons, instead of per-request instances
>
> * Form beans (should have done it the way WebWork does)
>
> * Extensibility of request processor (getting fixed in 1.3)
>
> * Action chaining is messed up.
>
> * Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing
>
> * Expression language syntax (based on BeanUtils) is way too limited
>
> * Totally dependent on Servlet API objects, making (a) unit tests hard,
> and (b) implementations on portlet difficult
>
> * Key functional areas (such as Tiles and Validator) can be
> pretty obtuse to configure
>
> * No model of user interface components -- just hard coded HTML rendering
>
> None of these things are totally unusable -- but they all need improvement.
>
> Craig
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: AW: AW: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Assuming I too did not misunderstand, which certainly is possible, that
sounds about right based on the last time I looked at doing it (this has
been something that has been discussed for as long as I can remember).
Although, I don't remember it being even *that* complex :) But, it's
been a while since I looked, and the underlying point is what's
important: instantiating an Action on a per-request basis no longer
carries the performance penalty it used to (from what I have heard...
can't say I've verified this myself), has some benefits that people
would probably appreciate, and changing the current codebase to do it is
pretty close to trivial, regardless of how one decides to actually
implement it.
Frank
Leon Rosenberg wrote:
>
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Frank W. Zammetti [mailto:fzlists@omnytex.com]
>>Gesendet: Samstag, 10. September 2005 18:47
>>An: Struts Users Mailing List
>>Betreff: Re: AW: Who decides?
>>
>>Leon Rosenberg wrote:
>>
>>>I think they 'de facto' are stateless singletons? I mean the
>>>controller only creates one instance, and you shouldn't
>>
>>create another
>>
>>>:-)
>>
>>That is how it currently works, and Craig has in the past
>>explained the decision. It made perfect sense 4+ years ago
>>when he first wrote Struts, on the basis of performance.
>>Modern JVMs make those concerns no longer true though.
>>
>>If an Action was created per request, you could do some
>>things that you can't do now, like non-static class members.
>>This would not be a huge change to the Struts codebase (at
>>least, that was my conclusion when I thought about it some
>>months ago and looked at the code), but would open up a lot
>>of nice possibilities.
>
>
>
> Hmm, ok, than I must have misunderstood him. Nevertheless, aren't we talking
> about a virutal three-liner here, which works with existing code as well?
>
> Interface ActionCommand{
> public ActionMapping execute(...);
> }
>
> Interface ActionCommandFactory(){
> public ActionCommand createCommand();
> }
>
> And then a basic action:
> CommandEnabledAction extends Action{
> execute(...){
> ActionCommandFactory factory = lookupFactory(...);
> return factory.createCommand().execute();
> }
> }
>
> Now implement an extension to the config to specify a factory, and you are
> done, aren't you?
>
>
> Regards
> Leon
>
>
>>One could go even further and quite easily add the ability to
>>specify scope for an Action, so you could put them in session
>>if you wanted.
>>Then, combining your ActionForms and your Actions would be
>>trivially easy... and hey, that starts to look a lot more
>>like JSF/Shale, doesn't it?!? ;)
>>
>>
>>>>* Totally dependent on Servlet API objects, making (a) unit tests
>>>>hard, and (b) implementations on portlet difficult
>>>
>>>
>>>I think it's the nature of a http framework?
>>
>>Not to speak for Craig, but if I understood this point
>>correctly, the idea is that right now there are a number of
>>places where request/response/session are passed around
>>directly and accessed directly. A layer of abstraction
>>between those places and those underlying objects would make
>>unit testing easier. I can't speak on the portlet point, but
>>I take his word for it.
>>
>>In 1.3, at least as far as the request processor chain
>>commands go, you get a single Context object (ActionContext I
>>think?) If your Actions also recieved that object only, and
>>there were methods that you called instead of directly
>>accessing request/response/session, you'd have that abstraction.
>>
>>As per my previous post, you could do all of this with the
>>current Struts code base... well, the single Context thing
>>would be a little more difficult because you couldn't replace
>>what an Action looks like now without breaking backwards
>>compatibility, but probably it can be done *in adddition* to
>>how it is now.
>>
>>
>>>Regards
>>>Leon
>>
>>Frank
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>For additional commands, e-mail: user-help@struts.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
AW: AW: Who decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Gesendet: Samstag, 10. September 2005 18:47
> An: Struts Users Mailing List
> Betreff: Re: AW: Who decides?
>
> Leon Rosenberg wrote:
> > I think they 'de facto' are stateless singletons? I mean the
> > controller only creates one instance, and you shouldn't
> create another
> > :-)
>
> That is how it currently works, and Craig has in the past
> explained the decision. It made perfect sense 4+ years ago
> when he first wrote Struts, on the basis of performance.
> Modern JVMs make those concerns no longer true though.
>
> If an Action was created per request, you could do some
> things that you can't do now, like non-static class members.
> This would not be a huge change to the Struts codebase (at
> least, that was my conclusion when I thought about it some
> months ago and looked at the code), but would open up a lot
> of nice possibilities.
Hmm, ok, than I must have misunderstood him. Nevertheless, aren't we talking
about a virutal three-liner here, which works with existing code as well?
Interface ActionCommand{
public ActionMapping execute(...);
}
Interface ActionCommandFactory(){
public ActionCommand createCommand();
}
And then a basic action:
CommandEnabledAction extends Action{
execute(...){
ActionCommandFactory factory = lookupFactory(...);
return factory.createCommand().execute();
}
}
Now implement an extension to the config to specify a factory, and you are
done, aren't you?
Regards
Leon
>
> One could go even further and quite easily add the ability to
> specify scope for an Action, so you could put them in session
> if you wanted.
> Then, combining your ActionForms and your Actions would be
> trivially easy... and hey, that starts to look a lot more
> like JSF/Shale, doesn't it?!? ;)
>
> >>* Totally dependent on Servlet API objects, making (a) unit tests
> >>hard, and (b) implementations on portlet difficult
> >
> >
> > I think it's the nature of a http framework?
>
> Not to speak for Craig, but if I understood this point
> correctly, the idea is that right now there are a number of
> places where request/response/session are passed around
> directly and accessed directly. A layer of abstraction
> between those places and those underlying objects would make
> unit testing easier. I can't speak on the portlet point, but
> I take his word for it.
>
> In 1.3, at least as far as the request processor chain
> commands go, you get a single Context object (ActionContext I
> think?) If your Actions also recieved that object only, and
> there were methods that you called instead of directly
> accessing request/response/session, you'd have that abstraction.
>
> As per my previous post, you could do all of this with the
> current Struts code base... well, the single Context thing
> would be a little more difficult because you couldn't replace
> what an Action looks like now without breaking backwards
> compatibility, but probably it can be done *in adddition* to
> how it is now.
>
> > Regards
> > Leon
>
> Frank
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: AW: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Leon Rosenberg wrote:
> I think they 'de facto' are stateless singletons? I mean the controller only
> creates one instance, and you shouldn't create another :-)
That is how it currently works, and Craig has in the past explained the
decision. It made perfect sense 4+ years ago when he first wrote
Struts, on the basis of performance. Modern JVMs make those concerns no
longer true though.
If an Action was created per request, you could do some things that you
can't do now, like non-static class members. This would not be a huge
change to the Struts codebase (at least, that was my conclusion when I
thought about it some months ago and looked at the code), but would open
up a lot of nice possibilities.
One could go even further and quite easily add the ability to specify
scope for an Action, so you could put them in session if you wanted.
Then, combining your ActionForms and your Actions would be trivially
easy... and hey, that starts to look a lot more like JSF/Shale, doesn't
it?!? ;)
>>* Totally dependent on Servlet API objects, making (a) unit
>>tests hard, and (b) implementations on portlet difficult
>
>
> I think it's the nature of a http framework?
Not to speak for Craig, but if I understood this point correctly, the
idea is that right now there are a number of places where
request/response/session are passed around directly and accessed
directly. A layer of abstraction between those places and those
underlying objects would make unit testing easier. I can't speak on the
portlet point, but I take his word for it.
In 1.3, at least as far as the request processor chain commands go, you
get a single Context object (ActionContext I think?) If your Actions
also recieved that object only, and there were methods that you called
instead of directly accessing request/response/session, you'd have that
abstraction.
As per my previous post, you could do all of this with the current
Struts code base... well, the single Context thing would be a little
more difficult because you couldn't replace what an Action looks like
now without breaking backwards compatibility, but probably it can be
done *in adddition* to how it is now.
> Regards
> Leon
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: AW: Who decides?
Posted by Martin Gainty <mg...@hotmail.com>.
Leon et al
addressing the last item
Unit tests easily handled by Artur Hecfyz's tool testsgen (independent of
implementation protocol)
http://wttools.sourceforge.net/unittestsgen/package.html
Struts Portlets can be easily implemented with Oracle JDeveloper via
http://portalstudio.oracle.com/pls/ops/docs/FOLDER/COMMUNITY/PDK/articles/pdkstruts/portletize-your-app.html
(also independent of implementation protocol)
Martin-
>
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Craig McClanahan [mailto:craigmcc@gmail.com]
> > Gesendet: Samstag, 10. September 2005 18:06
> > An: Struts Users Mailing List; fzlists@omnytex.com
> > Betreff: Re: Who decides?
> >
> > Here's a couple of things that (had we known then what we
> > know now) would very likely be different -- and areas where I
> > think improvements would be
> > helpful:
> >
> > * Actions as stateless singletons, instead of per-request instances
>
>I think they 'de facto' are stateless singletons? I mean the controller
>only
>creates one instance, and you shouldn't create another :-)
>
> > * Expression language syntax (based on BeanUtils) is way too limited
>
>For those who need it :-)
>
> >
> > * Totally dependent on Servlet API objects, making (a) unit
> > tests hard, and (b) implementations on portlet difficult
>
>I think it's the nature of a http framework?
>
>...
>
>Regards
>Leon
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
AW: Who decides?
Posted by Leon Rosenberg <st...@anotheria.net>.
> -----Ursprüngliche Nachricht-----
> Von: Craig McClanahan [mailto:craigmcc@gmail.com]
> Gesendet: Samstag, 10. September 2005 18:06
> An: Struts Users Mailing List; fzlists@omnytex.com
> Betreff: Re: Who decides?
>
> Here's a couple of things that (had we known then what we
> know now) would very likely be different -- and areas where I
> think improvements would be
> helpful:
>
> * Actions as stateless singletons, instead of per-request instances
I think they 'de facto' are stateless singletons? I mean the controller only
creates one instance, and you shouldn't create another :-)
> * Expression language syntax (based on BeanUtils) is way too limited
For those who need it :-)
>
> * Totally dependent on Servlet API objects, making (a) unit
> tests hard, and (b) implementations on portlet difficult
I think it's the nature of a http framework?
...
Regards
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Who decides?
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/10/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > I hope you'll find my comments useful in furthering this kind of
> discussion.
> > But I'm starting from a different place than you ... I personally think
> it
> > is a waste of time to improve the tools and documentation support for a
> five
> > year old architecture that is definitely showing its age.
>
> Craig, I've heard you make this statement a couple of times... can you
> go into some detail on where and how Struts is "showing its age"?
Here's a couple of things that (had we known then what we know now) would
very likely be different -- and areas where I think improvements would be
helpful:
* Actions as stateless singletons, instead of per-request instances
* Form beans (should have done it the way WebWork does)
* Extensibility of request processor (getting fixed in 1.3)
* Action chaining is messed up.
* Decorating actions (a la Spring MVC or WebWork or Tapestry) is missing
* Expression language syntax (based on BeanUtils) is way too limited
* Totally dependent on Servlet API objects, making (a) unit tests hard,
and (b) implementations on portlet difficult
* Key functional areas (such as Tiles and Validator) can be
pretty obtuse to configure
* No model of user interface components -- just hard coded HTML rendering
None of these things are totally unusable -- but they all need improvement.
Craig
Re: Who decides?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> I hope you'll find my comments useful in furthering this kind of discussion.
> But I'm starting from a different place than you ... I personally think it
> is a waste of time to improve the tools and documentation support for a five
> year old architecture that is definitely showing its age.
Craig, I've heard you make this statement a couple of times... can you
go into some detail on where and how Struts is "showing its age"? More
precisely, in those areas, what are the alternatives and what makes them
better?
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Who decides?
Posted by David Thielen <da...@windward.net>.
I was talking to my daughters about this the other day. In the last 25 years
I have had to learn a whole new environment/API/everything:
* DOS - Pascal and then C
* Windows - C and then C++
o Applications
o System level code (wrote part of Win95)
o Games
* Java - EJB 1.0 & EJB 2.0
* .NET/C#
You don't get to stick with a single technology anymore. Like it or not, the
world requires constant learning and constant movement to new tools and
technology. Struts will be replaced by JSP/Shale and in 5 years (or sooner)
that will be replaced by something else.
It's evolution at hyperspeed.
- dave
David Thielen
303-499-2544
www.windwardreports.com
-----Original Message-----
From: Craig McClanahan [mailto:craigmcc@gmail.com]
Sent: Friday, September 09, 2005 11:11 PM
To: Struts Users Mailing List
Subject: Re: Who decides?
...
I'm afraid that this is the nature of the software developer landscape.
You've heard the term "Internet time"? That is the environment in which we
(as application architects) need to decide which technoogies to become
dependent upon. The gamble, of course, is that the lifetime of the
technology will correspond with the lifetime of the application you build on
top of it. Sometimes you win, sometimes you lose.
...
Re: Who decides?
Posted by Craig McClanahan <cr...@gmail.com>.
There's no way to respond to quite all of the fascinating questions you are
raising in one message, but I'm packing up tonight to head for Beijing to
speak at the inagural Java China Conference (http://www.javachina.cn), so
I've got a few minutes to wax philosophical. This is also probably worth a
couple of blog entries, too, but those will have to wait until I have time
to sit down and compose them.
A (very few) scatttered comments inline ... not commenting on something
doesn't mean I do not find it interesting, just that I have a limited amount
of time to respond tonight.
On 9/9/05, Murray Collingwood <mu...@focus-computing.com.au> wrote:
>
> I'm just a humble Struts user (and relatively new), and I don't claim to
> speak for the
> group as a whole.
>
> I have read through Donald Brown's presentation (Struts 1.3 and beyond)
> and I get the
> feeling that the goal posts just don't stop moving.
I'm afraid that this is the nature of the software developer landscape.
You've heard the term "Internet time"? That is the environment in which we
(as application architects) need to decide which technoogies to become
dependent upon. The gamble, of course, is that the lifetime of the
technology will correspond with the lifetime of the application you build on
top of it. Sometimes you win, sometimes you lose.
Ironically, Struts 1.x triggers people to respond at both extremes, as well
as everywhere in the middle:
* It evolves very slowly, engendering confidence that I can count on support
over a multiple year lifetime for my application.
* It evolves very slowly, and since it was originally designed five years
ago,
it is hopelessly out of date relative to current best practices, and should
be tossed on the trash heap.
Both answers are quite reasonable and understandable ... depending on your
perspective.
The time I have spent learning and creating a Struts application should be
> an
> investment in my future development, not a stepping stone to a whole new
> set of
> technologies that will continue to slow my productivity (through on-going
> training).
I think this goal is reasonable in the short term, but naive in the long
term. You have to *count* on the technologies you understand today becoming
obsolete -- and the pace of that obsolescence is higher in software than in
any other profession I've ever looked at (although they *all* suffer from
this). A couple of thought points on this topic to consider:
* My son (now in his early 20s) is also a geek -- he really likes PHP, but
I love him anyway :-). In between contract jobs, he's working towards a
college degree ... but he's taking my advice to do something other than
Computer Science. Why? Because even if he were following the traditional
route of doing college in four years, anything *technical* he learned would
be totally obsolete by the time he graduated. It's important to learn the
fundamental
principles of good software development, but you've got to understand that
the point technologies you use at any given time are ephemeral.
* I took my own advice when *I* was in college :-), and have a Business
Administration
degree, with an emphasis in Accounting. You'd think (from the outside) that
there couldn't
possibly be a profession that changes slower than accounting, but I can
guarantee you that
this is not the case. Once you get past double entry bookkeeping, everything
I learned in
college (even if I remembered it all, 30 years later) would be totally
obsolete.
* The same sort of thing happens in scientific fields all over the map. For
example,
I aced a test on Astronomy by (among other things) nothing that Jupiter had
12 moons,
Saturn had 9, and so on. Those facts were considered true at the time ...
but not any more.
* Would you trust a doctor today to diagnose you with a 1950s medical
education?
Or even a 1990s medical education? Like basically all professions, medicine
(and software)
assume that a lifetime of learning new things is a fundamental requirement
for success.
I spent more time on this particular paragraph than the others below, to
give you a feel for why I answer some of those questions the way I do.
Who, and this is my question, who makes the decision whether a technology is
> going to
> be good for the greater community? Who asks the questions "Do we need
> it?", "Will
> the technology provide significantly greater returns than training
> costs?", "Will the
> technology last long enough to deliver those returns?"
Software development is like everything else ... it doesn't come with a
crystal ball. At best, someone tries to create an answer to perceived needs,
and then the market responds by indicating whether (a) the need was actual,
and (b) the provided solution actually met that need.
Open source software has very different economics on doing this sort of
stuff than you see in traditional product development at corporations that
build and sell "stuff", but it's the same basic issues under the covers.
Nobody knows *for sure* what the future holds, and what people will want
then. And different open source projects do things differently -- at Apache,
though, the direct day-to-day decisions of what happens next are up to the
committers on that project. There's good writeups of roles and
responsibilities that are worth looking at ... a good starting point for
exploration is:
http://jakarta.apache.org/site/getinvolved.html
At Struts, in other words, the actual decisions about what code gets
committed to the workspace is made by the committers (of which there are
currently 15 or so). In turn, those committers get driven by what interests
them, and what input they get from the community. Successul open source
projects tend to listen to the latter more than unsuccessful ones, but it is
very difficult to generalize on detailed practices.
Who is it that has decided we need to keep extending the Struts framework
> without
> considering the developers' need for better problem identification and
> documentation of
> the existing Struts system. This list gets so many emails of people
> struggling with
> existing technology: Dynaforms, Validation, Iteration, Cookies, Flow
> control, and the
> number of different versions of everything "out there" that we need to
> know about in
> order to work with this system.
Personally, I'm in agreement with you ... the Struts 1.x architecture needs
to be fundamentally replaced. That's why I spend my own personal open source
development time on Shale, where I am not stuck with concerns about
backwards compatibility. An incredible number of lessons have been learned
in the five years that Struts has existed. But those lessons cannot be fully
harvested without creating something completely different.
That being said, there are *millions* of applications based on Struts 1.x in
the word today. It would be totally irresponsible for the Struts development
community to abandon the developers who created those applications.
Therefore, it is entirey appropriate that an evolutionary path occur -- in
parallel to one or more "revolutionary" paths, since we don't have crystal
balls handy :-).
Who answers the question, "Why aren't we getting better error checking /
> debugging
> facilities for Struts?"
On this kind of "evolutionary" question, the answer is simple: "because
nobody has gone out and built a revised mousetrap that has better features."
Struts is not the creature of a corporate entity ... it is a labor of love
by volunteers. And there are no boundaries on who those volunteers might be
-- it could be you! What have *you* done to solve this problem?
Reminds me of how I got involved in open source software in the first place.
I was working on a startup, and we (of course) had no money, and needed a
cheap application server solution. Apache JServ (predecessor to Tomcat) fit
the bill ... but they sat at version 0.9 for months and months ... until my
son told me "Dad, you know Java, it's open source, go help them fix it!" So
I did.
It would be amiss of me to say Struts alone is responsible here, we should
> include
> Tomcat, MySQL, Connector/J, JSP, Java. And I'm not saying everybody is
> doing a
> terrible job, just asking whether we need to refocus our development
> efforts.
>
> I'm not a fan of Microsoft but at least they have somebody that makes
> those decisions
> and they appear to be developing their technology for productivity. They
> have
> documentation. They have tutorials. They have backward compatibility. And,
> have
> you noticed how many websites are using .NET technology! The number seems
> to
> growing much faster than J2EE or JEE.
I'll have to both agree and disagree with you with regards to Microsoft.
Yes, they have an overall story that is pretty effective, and enough
developers to build cradle-to-grave technologies to make it come true. That
is quite different from the Java ecosystem, where it's a bunch of
cooperative efforts, instead of a single monolithic organization, that makes
it all happen.
But "backwards compatibility"? Give me a break. Ask any VB developer what it
will take them to learn VB.Net. Or how easy it is to convert an ASP page to
ASP.Net. It's learning a new technology and applying it.
Note that this is, again, the nature of the beast. You can't champion both
"backwards compatibilty" and "rapid radical innovation" -- the two goals are
in a substantal degree of conflict.
When I was looking for an ISP to host my Struts application I found many
> more
> companies providing Microsoft servers with .NET than Unix/Linux servers
> with the
> necessary version of Tomcat or JBoss.
>
> If I were to write a web product to be sold and run inhouse, I would
> probably develop it
> using Microsoft technology, it's just so much easier to say, "requires IIS
> 6+ and
> SQLserver 2005+" and know that it will work. If you had to ship your
> product how many
> technologies with specific versions would you have to list?
I'll let others comment on the "know it will work" comment :-). My personal
experience with building JSF components and getting them to work in IE, for
browsers that theoretically implement the W3C standards for HTML, makes me
chuckle reading this paragraph.
Is Struts in danger of becoming just an academic exercise? If Struts is
> going to be
> productive then we need to see:
> * more documentation (and I'm not talking about the API, I'm sick of
> trying to read the
> API and guess the usage of the taglib functions) plus tutorials, online
> training etc,
> * more tools for building our applications (I know there are some but I'm
> on NetBeans
> and it appears to be lagging behind, Eclipse and Exadel I found to be too
> inflexible),
> * more error checking of the configuration files and better error messages
> indicating
> what the real problem is, maybe even warnings before the program runs,
> * more debugging utilities (spying on the http conversations and being
> able to
> examine the contents of our beans),
> * more backward compatibility so that I don't have to spend hours
> upgrading my app
> when my server updates or I move to a new server,
> * more stability in the platform we choose (with reference to the recent
> Tomcat bugs
> that were brought to the attention of this list).
Have you looked around yet? In the Java web application framework space,
Struts is ***by far*** the leader, even today, in terms of robust support
and documentation (not just from the project itself, but from tools and
third party sources like books and knowledgeable consultants). JSF is
getting there. Nothing else is even close.
That being said, it's still an open source project. If *you* believe that
the sufficient resources are insufficient, where's *your* contribution to
make it better?
If I were asked to vote it would probably be a conservative vote to
> consolidate our
> current technologies with better tools and a better product.
>
> Okay, there, I said it. It's out of my system and open for discussion.
> Kind regards
> mc
I hope you'll find my comments useful in furthering this kind of discussion.
But I'm starting from a different place than you ... I personally think it
is a waste of time to improve the tools and documentation support for a five
year old architecture that is definitely showing its age. It's time to
leverage all the things we've learned in the past few years ... and provide
*transition* strategies for existing framework users (while also providing
incremental improvements and bugfixes to those who cannot transition as
quickly as we geeks might like).
But, assuming that you can learn a technology once and let it be the
foundation for an entire career is hopelessly idealistic.
Craig
Who decides?
Posted by Murray Collingwood <mu...@focus-computing.com.au>.
I'm just a humble Struts user (and relatively new), and I don't claim to speak for the
group as a whole.
I have read through Donald Brown's presentation (Struts 1.3 and beyond) and I get the
feeling that the goal posts just don't stop moving.
The time I have spent learning and creating a Struts application should be an
investment in my future development, not a stepping stone to a whole new set of
technologies that will continue to slow my productivity (through on-going training).
Who, and this is my question, who makes the decision whether a technology is going to
be good for the greater community? Who asks the questions "Do we need it?", "Will
the technology provide significantly greater returns than training costs?", "Will the
technology last long enough to deliver those returns?"
Who is it that has decided we need to keep extending the Struts framework without
considering the developers' need for better problem identification and documentation of
the existing Struts system. This list gets so many emails of people struggling with
existing technology: Dynaforms, Validation, Iteration, Cookies, Flow control, and the
number of different versions of everything "out there" that we need to know about in
order to work with this system.
Who answers the question, "Why aren't we getting better error checking / debugging
facilities for Struts?"
It would be amiss of me to say Struts alone is responsible here, we should include
Tomcat, MySQL, Connector/J, JSP, Java. And I'm not saying everybody is doing a
terrible job, just asking whether we need to refocus our development efforts.
I'm not a fan of Microsoft but at least they have somebody that makes those decisions
and they appear to be developing their technology for productivity. They have
documentation. They have tutorials. They have backward compatibility. And, have
you noticed how many websites are using .NET technology! The number seems to
growing much faster than J2EE or JEE.
When I was looking for an ISP to host my Struts application I found many more
companies providing Microsoft servers with .NET than Unix/Linux servers with the
necessary version of Tomcat or JBoss.
If I were to write a web product to be sold and run inhouse, I would probably develop it
using Microsoft technology, it's just so much easier to say, "requires IIS 6+ and
SQLserver 2005+" and know that it will work. If you had to ship your product how many
technologies with specific versions would you have to list?
Is Struts in danger of becoming just an academic exercise? If Struts is going to be
productive then we need to see:
* more documentation (and I'm not talking about the API, I'm sick of trying to read the
API and guess the usage of the taglib functions) plus tutorials, online training etc,
* more tools for building our applications (I know there are some but I'm on NetBeans
and it appears to be lagging behind, Eclipse and Exadel I found to be too inflexible),
* more error checking of the configuration files and better error messages indicating
what the real problem is, maybe even warnings before the program runs,
* more debugging utilities (spying on the http conversations and being able to
examine the contents of our beans),
* more backward compatibility so that I don't have to spend hours upgrading my app
when my server updates or I move to a new server,
* more stability in the platform we choose (with reference to the recent Tomcat bugs
that were brought to the attention of this list).
If I were asked to vote it would probably be a conservative vote to consolidate our
current technologies with better tools and a better product.
Okay, there, I said it. It's out of my system and open for discussion.
Kind regards
mc
On 9 Sep 2005 at 19:39, Don Brown wrote:
> Heh, well, I can assure you I for one have my doubts :) Shale is one of the
> more interesting developments in Struts and certainly deserved a few slides.
> My goal was not to promote Shale as the future, but provide a snapshot of
> the many growth areas within Struts, Shale included. I wanted to say more
> about a new development I'm personally more interested in, Struts Ti, but it
> isn't to the level of maturity and acceptance as Shale so it was relegated
> to a single bullet.
>
> Don
>
> On 9/9/05, $BNB_[>l (B <pc...@gmail.com> wrote:
> >
> > Don
> >
> > I have read your presentation.
> > I give me an impression.
> >
> > Shale is the future of Struts without doubt!!!
> >
> >
> >
> > 2005/9/8, Don Brown <do...@gmail.com>:
> > > I just finished giving a presentation titled "Struts 1.3 and Beyond" to
> > the
> > > Silicon Valley Web Developer JUG that I thought folks on this list might
> > be
> > > interested in. In addition to the regular slide keyboard controls, press
> > "T"
> > > to toggle the outline/printable view which contains extra notes.
> > >
> > > Presentation: http://www.twdata.org/presentations/struts-future/
> > > Presentation software: http://www.meyerweb.com/eric/tools/s5/
> > >
> > > Don
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
FOCUS Computing
Mob: 0415 24 26 24
murray@focus-computing.com.au
http://www.focus-computing.com.au
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.20/95 - Release Date: 9/09/2005
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: "Struts 1.3 and Beyond" Presentation
Posted by Craig McClanahan <cr...@gmail.com>.
On 9/9/05, Don Brown <do...@gmail.com> wrote:
>
> Heh, well, I can assure you I for one have my doubts :) Shale is one of
> the
> more interesting developments in Struts and certainly deserved a few
> slides.
> My goal was not to promote Shale as the future, but provide a snapshot of
> the many growth areas within Struts, Shale included. I wanted to say more
> about a new development I'm personally more interested in, Struts Ti, but
> it
> isn't to the level of maturity and acceptance as Shale so it was relegated
> to a single bullet.
For those interested in compare-and-contrast on various web frameworks
(primarily ones already in fairly widespread use), you might also be
interested in the slides for my presentation (on that subject) at O'Reilly
Open Source last month:
http://people.apache.org/~craigmcc/oscon_2005_web_architectures.pdf
One of the things I tried to do here was identify the key architectural
decisions that a framework designer focuses on, and how several existing
frameworks deal with those decisions.
Don
Craig
On 9/9/05, 梁炳場 <pc...@gmail.com> wrote:
> >
> > Don
> >
> > I have read your presentation.
> > I give me an impression.
> >
> > Shale is the future of Struts without doubt!!!
> >
> >
> >
> > 2005/9/8, Don Brown <do...@gmail.com>:
> > > I just finished giving a presentation titled "Struts 1.3 and Beyond"
> to
> > the
> > > Silicon Valley Web Developer JUG that I thought folks on this list
> might
> > be
> > > interested in. In addition to the regular slide keyboard controls,
> press
> > "T"
> > > to toggle the outline/printable view which contains extra notes.
> > >
> > > Presentation: http://www.twdata.org/presentations/struts-future/
> > > Presentation software: http://www.meyerweb.com/eric/tools/s5/
> > >
> > > Don
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
Re: "Struts 1.3 and Beyond" Presentation
Posted by Don Brown <do...@gmail.com>.
Heh, well, I can assure you I for one have my doubts :) Shale is one of the
more interesting developments in Struts and certainly deserved a few slides.
My goal was not to promote Shale as the future, but provide a snapshot of
the many growth areas within Struts, Shale included. I wanted to say more
about a new development I'm personally more interested in, Struts Ti, but it
isn't to the level of maturity and acceptance as Shale so it was relegated
to a single bullet.
Don
On 9/9/05, 梁炳場 <pc...@gmail.com> wrote:
>
> Don
>
> I have read your presentation.
> I give me an impression.
>
> Shale is the future of Struts without doubt!!!
>
>
>
> 2005/9/8, Don Brown <do...@gmail.com>:
> > I just finished giving a presentation titled "Struts 1.3 and Beyond" to
> the
> > Silicon Valley Web Developer JUG that I thought folks on this list might
> be
> > interested in. In addition to the regular slide keyboard controls, press
> "T"
> > to toggle the outline/printable view which contains extra notes.
> >
> > Presentation: http://www.twdata.org/presentations/struts-future/
> > Presentation software: http://www.meyerweb.com/eric/tools/s5/
> >
> > Don
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
Re: "Struts 1.3 and Beyond" Presentation
Posted by 梁炳場 <pc...@gmail.com>.
Don
I have read your presentation.
I give me an impression.
Shale is the future of Struts without doubt!!!
2005/9/8, Don Brown <do...@gmail.com>:
> I just finished giving a presentation titled "Struts 1.3 and Beyond" to the
> Silicon Valley Web Developer JUG that I thought folks on this list might be
> interested in. In addition to the regular slide keyboard controls, press "T"
> to toggle the outline/printable view which contains extra notes.
>
> Presentation: http://www.twdata.org/presentations/struts-future/
> Presentation software: http://www.meyerweb.com/eric/tools/s5/
>
> Don
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org