Why so hesitant to do another release? It has been a long time since
2.0. I think it is time for some major rework and releasing a new
major version.
Sent from my iPhone
On Aug 12, 2009, at 8:06 PM, Don Brown wrote:
On Thu, Aug 13, 2009 at 12:01 PM, Paul
Benedict wrote:
Are you sure it's
Except the API changes. Remember that any API change that breaks
someone should be a major release. That's why people work so hard on
keeping old APIs around.
Sent from my iPhone
On Aug 12, 2009, at 3:45 PM, Wendy Smoak wrote:
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict
wrote:
I defin
On Thu, Aug 13, 2009 at 12:01 PM, Paul Benedict wrote:
> Are you sure it's not an incompatible change? I thought the discussion was
> the importing of XWork and getting rid of its branding. That means all of
> XWork's annotations and packages would be changed to org.apache.struts. I
> don't believe
Are you sure it's not an incompatible change? I thought the discussion was
the importing of XWork and getting rid of its branding. That means all of
XWork's annotations and packages would be changed to org.apache.struts. I
don't believe there is any desire to keep com.opensymphony when this occurs.
+1 GA
Cheers, Rainer
Von meinem iPhone gesendet
Am 12.08.2009 um 19:29 schrieb Wes Wannemacher :
The Struts Annotations 1.0.5 test build is now available as a Maven
artifact. Functionality was added, but Struts releases do not
currently
use the new features.
The test build is available in
On Wed, Aug 12, 2009 at 2:36 PM, Paul Benedict wrote:
> I definitely agree that Struts 3 would be a good candidate to do this XWork
> migration. It is not an appropriate candidate for 2.1, or 2.2. However, if
> you like to do a 2.5 (I dislike superficial jumps in versions though), then
> it might b
I definitely agree that Struts 3 would be a good candidate to do this XWork
migration. It is not an appropriate candidate for 2.1, or 2.2. However, if
you like to do a 2.5 (I dislike superficial jumps in versions though), then
it might be acceptable in the 2.x branch.
Paul
On Tue, Aug 11, 2009 at
+1 GA
Wes Wannemacher schrieb:
> The Struts Annotations 1.0.5 test build is now available as a Maven
> artifact. Functionality was added, but Struts releases do not currently
> use the new features.
>
> The test build is available in the Struts snapshot repository located
> here -
>
> http://peo
Here is my +1 GA, binding
-W
On Wed, Aug 12, 2009 at 1:29 PM, Wes Wannemacher wrote:
> The Struts Annotations 1.0.5 test build is now available as a Maven
> artifact. Functionality was added, but Struts releases do not currently
> use the new features.
>
> The test build is available in the Strut
+1 GA
On Wed, Aug 12, 2009 at 10:29 AM, Wes Wannemacher wrote:
> The Struts Annotations 1.0.5 test build is now available as a Maven
> artifact. Functionality was added, but Struts releases do not currently
> use the new features.
>
> The test build is available in the Struts snapshot repository l
The Struts Annotations 1.0.5 test build is now available as a Maven
artifact. Functionality was added, but Struts releases do not currently
use the new features.
The test build is available in the Struts snapshot repository located
here -
http://people.apache.org/builds/struts/struts-annotations-
2009/8/12 Johannes Geppert
>
> Hello Eric,
>
> thank you for fast response.
>
>
> Obinna wrote:
> >
> > What I have done is to put all of the meat of the javascript code into a
> > single file which is included in the sj:head and then just have a small
> > binding snippet code rendered with each
Since it's a finite set of cases, you might be able to use jQuery's awesome
ability to gather information together and meet both requirements with very
little work. If you assign non-visual classes to the inputs then use a
single script tag at the end of the document to bind all the inputs to thei
>
> 2.) This big javascript was loaded on every single page
This is an advantage instead of a problem. Browsers can cache this
javascript file, if you put all the javascript in the page, it will:
1. make your pages bigger (not good)
2. prevent the browser from caching the javascript (longer render
The change to struts-annotations was trivial and long over due, so
there should be no problems. Build away.
musachy
On Wed, Aug 12, 2009 at 6:27 AM, Wes Wannemacher wrote:
> There have been a few small changes to both struts-master and
> struts-annotations... The change to struts-master will hope
Hello Eric,
thank you for fast response.
Obinna wrote:
>
> What I have done is to put all of the meat of the javascript code into a
> single file which is included in the sj:head and then just have a small
> binding snippet code rendered with each tag which calls a binding function
> in the ma
There have been a few small changes to both struts-master and
struts-annotations... The change to struts-master will hopefully keep
someone (me) from stomping on the http://struts.apache.org site when
releasing it in the future. Unfortunately, the only way to test it is
to do a release (at least as
Johannes,
What I have done is to put all of the meat of the javascript code into a
single file which is included in the sj:head and then just have a small
binding snippet code rendered with each tag which calls a binding function
in the main .js file.
The binding snippet is identical for all tags
Hello,
maybe anybody can give my some input for an idea I have today.
I work on the current struts2-jquery-plugin.
http://code.google.com/p/struts2-jquery/
At the moment the tags create after each generated html tag
an separate tag like this: