I'd suggest in the case where frameworks are unable to support a feature it
should be clearly documented and the plugins tld doesn't include the tag.
By having the two classes my aim is that users can rely on ajax plugins
included in the core to have a basic level of functionality as opposed to
Just so we're all on the same page, can I put forward the following as a
version numbering plan which would seem to reflect most peoples views;
2.0.x - New releases shouldn't alter the public API unless absolutley
neccessary (e.g. something is a security risk).
2.1.x (pre-first GA) - Changes
Yeah, true enough. Although the 2 things I never "loved" with rails were
resolving multiple action methods with all the different validations and
before_ hooks, etc that you only wanted to run for one or two of the
methods, and 2) empty active record models. But that's a different
discussion :)
Sounds good. If you can, I think you should share it. Host it at
googlecode, add it to the plugin registry and announce it on the users
list. There's plenty of S2 plugins hosted at googlecode, some that have
many downloads. If its popular and useful it'll soon be noticed. That's
how SmartURL
Hey Jeremy,
Thanks for writing back. I was kind of starting to wonder if I wasn't
supposed to be posting to this list :).
I really like portions of the REST plugin, but I wanted to be able to
leverage a lot of the interface and class level patterns in Struts (ie, 1
class 1 action), so I ended up
Blake Byrnes wrote:
I dealt with the ajax result discrepency (ie, if you make an ajax request,
you generally want a different result, but probably want to share the same
action) by writing a few things:
1) A sitemesh filter that ignores requests with the content header
X-Requested-With=XMLHttpReq
I think it will benefit everyone to read this three part piece on evolving
APIs:
http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs
Paul
On Thu, Feb 21, 2008 at 10:37 PM, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli <[EMAIL PROTECTED]>
> w
On Thu, Feb 21, 2008 at 8:24 AM, Antonio Petrelli <
[EMAIL PROTECTED]> wrote:
> 2008/2/21, Musachy Barroso <[EMAIL PROTECTED]>:
> >
> > On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]>
> wrote:
> > > Before a GA release of 2.1 I'd ideally like to see dojo upgraded to
> the
> > > lat
On Thu, Feb 21, 2008 at 7:03 PM, Brian Pontarelli <[EMAIL PROTECTED]>
wrote:
> Don Brown wrote:
> > Yes, you are missing my original point #2 - "We need to be able to do
> > "alpha" releases to get new, experimental features into the community
> > for testing." I need a way to create an alpha rele
I think everyone should take a long serious look at ExtJS. I'm using
it on my current gig right now (very large s2 app) and except for a
few small quirks, it is helping us cover far more ground than we could
without it or with a different framework.
Trust me, you can't appreciate it until you try
Jeromy Evans wrote:
Hi Brian,
I shared your frustration when I moved a plugin from 2.1.0 to 2.1.1.
Initially I was taken-aback by the significance of the changes to the
PackageConfig and ActionConfig that broke uses of MockConfiguration. I
didn't expect such a large change between minor revi
Don Brown wrote:
Yes, you are missing my original point #2 - "We need to be able to do
"alpha" releases to get new, experimental features into the community
for testing." I need a way to create an alpha release for 2.1 to hand
off to our community for feedback, but if all releases require a
uniqu
Hi Brian,
I shared your frustration when I moved a plugin from 2.1.0 to 2.1.1.
Initially I was taken-aback by the significance of the changes to the
PackageConfig and ActionConfig that broke uses of MockConfiguration. I
didn't expect such a large change between minor revisions and was
disapp
Ian Roughley wrote:
Dave Newton wrote:
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
Yikes.
The issue with the Dojo plugin (and any other, like my somewhat-waylaid
jQuery plugin) is that I end up writing all the JavaScript anyway,
and the
tags don't help me very much in all but the *mo
Brian Pontarelli wrote:
Dave Newton wrote:
--- Al Sutton <[EMAIL PROTECTED]> wrote:
Is there a list of "gotchas" for a 2.0 to 2.1 migration?
One was started at
http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html
There are more that should be
Yes, you are missing my original point #2 - "We need to be able to do
"alpha" releases to get new, experimental features into the community
for testing." I need a way to create an alpha release for 2.1 to hand
off to our community for feedback, but if all releases require a
unique patch version, I'
Musachy Barroso wrote:
I never thought this would generate such a long thread. Yeah we should
fix it, but c'on, we have a ton of bugs to fix and new/cool stuff to
implement :).
musachy
Yeah, this thread is a classic case of non-urgent non-important chatter
(ref Steven R. Covey's book
h
Don Brown wrote:
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> These two points, put together, will necessarily result in a 2.1.0
> release that is drastically different than 2.1.1. I just don't see
> any way around that.
>
Tooling can solve this issue.
How? As I sai
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> > These two points, put together, will necessarily result in a 2.1.0
> > release that is drastically different than 2.1.1. I just don't see
> > any way around that.
> >
>
> Tooling can solve this issue.
How? As I said, it is not possi
Don Brown wrote:
Here are my two points:
1. Our current versioning scheme requires patch versions for all
releases, regardless of quality
2. We need to be able to do "alpha" releases to get new, experimental
features into the community for testing
These two points, put together, will necessari
Here are my two points:
1. Our current versioning scheme requires patch versions for all
releases, regardless of quality
2. We need to be able to do "alpha" releases to get new, experimental
features into the community for testing
These two points, put together, will necessarily result in a 2.1.
Don Brown wrote:
Well said, and I completely agree. My original point is your point #1
just isn't possible with the current versioning scheme. Because every
release gets its own patch number, regardless of quality or API
changes, it can't be counted on, and really, I don't see any solution
oth
On 2/22/08, Paul Benedict <[EMAIL PROTECTED]> wrote:
> I would strongly suggest that Struts 2.1 refactor itself, if necessary, to
> separate out the public and internal API and produce two distrinct javadocs
> and source bundles based on these. Since 2.1 is already incompatible for
> plugins, I
Moving to API compat thread.
Don Brown wrote:
I do agree we need to be much better about how much of our API we
expose to developers, but I think the question of public vs private
API goes beyond the Java semantics and into what a typical Struts user
will encounter. Unless you are a plugin or
Well said, and I completely agree. My original point is your point #1
just isn't possible with the current versioning scheme. Because every
release gets its own patch number, regardless of quality or API
changes, it can't be counted on, and really, I don't see any solution
other than creating a b
I do not agree that classes that are public belong to the public API. It's
rather well-known that when complex subpackage structures are created, there
is no other way to share classes except to make them public. That is why,
imo, the javadocs be produced in 2: one API that is officially supportabl
I do agree we need to be much better about how much of our API we
expose to developers, but I think the question of public vs private
API goes beyond the Java semantics and into what a typical Struts user
will encounter. Unless you are a plugin or framework developer, it
would be very rare for yo
Don Brown wrote:
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Here's an example... The XWork configuration API changed to the builder
pattern. This is probably a good thing, but required any plugin using it
to make significant changes and re-compile. This change wasn't
compati
--- Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> Don Brown wrote:
> > On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> >> Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
> >> change is minor in comparison.
> > I disagree with that statement. For Struts 2 users, t
Don Brown wrote:
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
change is minor in comparison.
I disagree with that statement. For Struts 2 users, the changes are
only minor. I think you feel them more
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> Here's an example... The XWork configuration API changed to the builder
> pattern. This is probably a good thing, but required any plugin using it
> to make significant changes and re-compile. This change wasn't
> compatible and there a
On 2/22/08, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
>
> Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
> change is minor in comparison.
I disagree with that statement. For Struts 2 users, the changes are
only minor. I think you feel them more because you are working
Don Brown wrote:
But don't you see, if we used the more traditional 1.0-alpha-1 ->
1.0-beta-1 -> 1.0-rc-1 -> 1.0 then we could produce releases that
drastically changed the API within a single version. As it is now,
there could very well be huge changes from 1.0 to 1.0.1 because every
release ge
But don't you see, if we used the more traditional 1.0-alpha-1 ->
1.0-beta-1 -> 1.0-rc-1 -> 1.0 then we could produce releases that
drastically changed the API within a single version. As it is now,
there could very well be huge changes from 1.0 to 1.0.1 because every
release gets its own numeric
Hehe. The changes from 2.0 to 2.1 are completely incompatible, so this
change is minor in comparison. if we were to use the commonly accepted
versioning scheme of major vs. minor releases, 2.1.x would eventually
become 3.0 when it goes GA. So, I say make all these "break everything"
changes n
Dave Newton wrote:
--- Al Sutton <[EMAIL PROTECTED]> wrote:
Is there a list of "gotchas" for a 2.0 to 2.1 migration?
One was started at
http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html
There are more that should be added to this page. I'll t
Just some additional thoughts on this front... It seems like most
frameworks are heading in very similar directions now. They are all
getting lighter, faster, and better at selecting and manipulating
elements. I'm in favor or having some AJAX functionality baked, but I
have never found it ver
>
> I'd suggest that Class 1 comes from all the tags which were in S2.0 core and
> moved out to the plugin in S2.1, this would give S2.0 users a smoother
> migration path knowing that they can chop and change ajax plugins to find
> one they like without the risk of wasting time on a plugin that
Musachy Barroso wrote:
>
> I have totally changed my position about the dojo plugin. I think Struts
> should have some ajax functionality for the most commom use cases, but I
> think we just picked the wrong ajax framework.
>
Musachy, have you looked at Dojo lately? I can understand your frus
I, for one, would love to see two classes of struts/ajax tags in S2.1;
Class 1 - Core support tags that all ajax plugins support which would allow
developers to swap backends.
Class 2 - Plugin specific tags, for covering those ajax framework specific
functions which are just too cool to leave o
I dealt with the ajax result discrepency (ie, if you make an ajax request,
you generally want a different result, but probably want to share the same
action) by writing a few things:
1) A sitemesh filter that ignores requests with the content header
X-Requested-With=XMLHttpRequest
2) An Interceptor
I may get boos on this, but I've thought about creating a hand-rolled
AJAX plugin. I like the available JS frameworks like
Prototype/Dojo/JQuery, but it does seem like there are a lot of
gotchas with any one of them. Having written some XHR processing in
vanilla javascript, sometimes I wonder how h
Dave Newton wrote:
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the
latest, greatest stable version,
I have totally changed my position a
On Thu, Feb 21, 2008 at 7:34 AM, CleverSwine <[EMAIL PROTECTED]>
wrote:
>
>
> Chris Pratt wrote:
> >
> > I don't know for sure, but that's pretty common practice before Java 5's
> > import static.
> >
>
> I disagree. This was in practice in the '90s, although to say it was
> "common" is a stretch.
> The Microsoft YUI? :D
>
I had forgot that. /cry. Good thing that it has a BSD license.
musachy
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comma
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
> I never thought this would generate such a long thread.
Me neither :/ Really, I just wanted confirmation that it was a legacy
holdover.
I vote to deprecate and move the constants into StrutsConstants.
Dave
--
I never thought this would generate such a long thread. Yeah we should
fix it, but c'on, we have a ton of bugs to fix and new/cool stuff to
implement :).
musachy
On Thu, Feb 21, 2008 at 11:21 AM, Antonio Petrelli
<[EMAIL PROTECTED]> wrote:
> 2008/2/21, Paul Benedict <[EMAIL PROTECTED]>:
> >
>
>
--- Musachy Barroso <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
> > Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the
> > latest, greatest stable version,
> I have totally changed my position about the dojo plugin. I thin
It should also improve perf by a tiny bit since several things like OGNL and
TextProviders iterate over all the interfaces and super classes you
implement/extend.
On Thu, Feb 21, 2008 at 11:03 AM, Antonio Petrelli <
[EMAIL PROTECTED]> wrote:
> 2008/2/21, Paul Benedict <[EMAIL PROTECTED]>:
> >
> >
2008/2/21, Musachy Barroso <[EMAIL PROTECTED]>:
>
> On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
> > Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the
> > latest, greatest stable version,
>
>
> I have totally changed my position about the dojo plugin.
2008/2/21, Paul Benedict <[EMAIL PROTECTED]>:
>
> Antonio, you are probably more familiar with the project :-) But the whole
> purpose of minor point releases is to say "hey, i am at least compatible
> with anything else in the 2.x line" -- if you can meet that requirement,
> then you should at lea
On Thu, Feb 21, 2008 at 2:03 AM, Al Sutton <[EMAIL PROTECTED]> wrote:
> Before a GA release of 2.1 I'd ideally like to see dojo upgraded to the
> latest, greatest stable version,
I have totally changed my position about the dojo plugin. I think
Struts should have some ajax functionality for the m
Antonio, you are probably more familiar with the project :-) But the whole
purpose of minor point releases is to say "hey, i am at least compatible
with anything else in the 2.x line" -- if you can meet that requirement,
then you should at least deprecate it in 2.1.
Paul
On Thu, Feb 21, 2008 at 1
2008/2/21, Paul Benedict <[EMAIL PROTECTED]>:
>
> I say fix it in Struts 3.0. Yes, it's a horrible pattern to make a
> programming shortcut. But it's certainly not acceptable to change it in
> minor point releases. Better wait for the next major point release to make
> incompatible changes.
-1.
2008/2/21, Dave Newton <[EMAIL PROTECTED]>:
>
> > In the dozens of companies for which I've consulted, I haven't
> > seen it done since a client in the educational textbook industry
> > in 2001.
>
>
> Just to provide a counter-anecdote, in the dozens of companies for which
> I've
> consulted I've s
--- Al Sutton <[EMAIL PROTECTED]> wrote:
> Is there a list of "gotchas" for a 2.0 to 2.1 migration?
One was started at
http://cwiki.apache.org/S2WIKI/troubleshooting-guide-migrating-from-struts-20x-to-21x.html
Dave
-
To unsubsc
Is there a list of "gotchas" for a 2.0 to 2.1 migration?
Al.
- Original Message -
From: "Brian Pontarelli" <[EMAIL PROTECTED]>
To: "Struts Developers List"
Sent: Thursday, February 21, 2008 3:23 PM
Subject: Re: [s2] Let's get out Struts 2.1.1
opposed to half way through the 2.1 l
I say fix it in Struts 3.0. Yes, it's a horrible pattern to make a
programming shortcut. But it's certainly not acceptable to change it in
minor point releases. Better wait for the next major point release to make
incompatible changes.
Paul
On Thu, Feb 21, 2008 at 9:51 AM, Dave Newton <[EMAIL PRO
--- CleverSwine <[EMAIL PROTECTED]> wrote:
> Chris Pratt wrote:
> > I don't know for sure, but that's pretty common practice before Java 5's
> > import static.
> I disagree. This was in practice in the '90s, although to say it was
> "common" is a stretch. Much more common has always been to define
--- Adam Hardy <[EMAIL PROTECTED]> wrote:
> I think if you look at StrutsStatics it's not really the constant interface
> antipattern.
>
> It has just 6 constants which are the keys to retrieve the HTTP servlet api
> objects from whichever maps.
That's the constant interface antipattern; an inter
Chris Pratt wrote:
>
> I don't know for sure, but that's pretty common practice before Java 5's
> import static.
>
I disagree. This was in practice in the '90s, although to say it was
"common" is a stretch. Much more common has always been to define constants
in a utility class or within the c
opposed to half way through the 2.1 lifecycle. I'd also like to see a
change
to actrionError and actionMessage handling which removes the need for the
store interceptor for redirects, but I know that's something that's in
the
very early stages of thought.
That would be great. This should pr
From my perspective the issue isn't education, it is compatibility at
the code level. Making changes that severely break plugins and
applications needs to be reserved for major releases. Here are two
examples that had severe impacts:
- Making XWork objects immutable with the builder pattern
Actually I'd go one further and say the constant should be a static on the class
to which it has most relevance. Now that reduces typing and improves clarity.
Instead of
StrutsConstants.RESULT_CONSTANT1;
StrutsConstants.ACTION_CONSTANT1;
Action.CONSTANT1;
I think if you look at StrutsStatics
Hallo,
if you use the e.g. jFreeChart plugin, you write actions, which
implement "getChart()". This action would not make sense without the
jFreeChart plugin. In this scenario, wouldn't it be great to define the
action's dependency on jFreeChart by annotation? Struts could then
check, if the actio
I'm not sure why it's a problem in WL, but I don't think it's a WL
bug. It's more likely that it has something to do with container
dependent handling of requests/threads. I don't remember the exact
order of events, and I don't have time right now to debug it again,
but the bottom line is that the
66 matches
Mail list logo
