You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2009/04/10 14:24:03 UTC
Ready for Struts 2.2 and XWork 2.2?
Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
off and move trunk to 2.2? I was wanting to do some refactoring of
how XWork configuration is loaded and parsed, but new classes and the
like really isn't appropriate for a patch/micro release.
Any objections to the branching?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
We should include/improve a flash result/scope for 2.2:
https://issues.apache.org/struts/browse/WW-2635
an yes, we should start drafting some sort of roadmap.
musachy
On Fri, Apr 24, 2009 at 12:49 PM, Rene Gielen <gi...@it-neering.net> wrote:
> to add some ideas that came to my mind lately:
>
> Rework on i18n support
> 1. create a TextProviderNextGen component that can easily be used and
> injected
> 2. create a TextProvider interceptor which
> - sets up a TextProvider
> - sets it on an Action implementing TextProviderAware interface
> - pushes the TextProvider on the stack to have a mixin/"trait"-like
> functionality
> 3. make formats easier to use in tags (textfield, property, select etc)
> - add a "format" property to name a text format to apply to the value
> - provide predefined default formats like number, money, percent
>
> comments:
> 1. The new component would give us the opportunity to get out of the
> TextProvider hell without braking backwards compatibility
>
> 2. Extracting TextProvider functionality to an aspect would remove the
> main reason to extend ActionSupport. While Actions would explicitly
> declare their need for TextProvider as a component, the view developer
> would still be able to use getText(...) expressions directly (via
> TextProvider residing on the stack), without the need to write
> textProvider.getText(...) given TextProviderAware introduces a
> textProvider property on the action.
>
> 3. Although the use of getText expressions provide all the needed
> functionality for i18n/l10n support, they are quite clumsy to use when
> it comes to the widely used pattern of applying text formats to numbers
> and dates. Adding a convenience property named format would held view
> developers to get very easy access to those formats, without the need to
> understand the getText signatures (I have to constantly look it up
> again) for their most common use cases. Providing some reasonable
> default formats would make it work out of the box, while the developer
> could define additional formats as well as use getText expressions like
> before when it comes to multiparameter formats etc.
>
> That said, should we go to setup a (s|x) 2.2 roadmap in Confluence?
>
> - Rene
>
> Don Brown schrieb:
>> Off the top of my head:
>> * Split out the XML parser from XmlConfigurationProvider so that you
>> can parse XML from any source
>> * Get rid of all the Class.forName() calls in XWork
>>
>> I'd rather not do this on a stable branch, particularly since new
>> public classes will be created. How many changes are there in 2.1.7
>> and 2.1.3 that haven't been released? Could we get those releases out
>> the door so we know we branch at a known good state?
>>
>> Don
>>
>> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>>> I think we are good. What changes do you have in mind?, the OSGi
>>> plugin could take advantage of some refactoring of xwork so I am
>>> interested :)
>>>
>>> musachy
>>>
>>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>>> how XWork configuration is loaded and parsed, but new classes and the
>>>> like really isn't appropriate for a patch/micro release.
>>>>
>>>> Any objections to the branching?
>>>>
>>>> Don
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Rene Gielen <gi...@it-neering.net>.
to add some ideas that came to my mind lately:
Rework on i18n support
1. create a TextProviderNextGen component that can easily be used and
injected
2. create a TextProvider interceptor which
- sets up a TextProvider
- sets it on an Action implementing TextProviderAware interface
- pushes the TextProvider on the stack to have a mixin/"trait"-like
functionality
3. make formats easier to use in tags (textfield, property, select etc)
- add a "format" property to name a text format to apply to the value
- provide predefined default formats like number, money, percent
comments:
1. The new component would give us the opportunity to get out of the
TextProvider hell without braking backwards compatibility
2. Extracting TextProvider functionality to an aspect would remove the
main reason to extend ActionSupport. While Actions would explicitly
declare their need for TextProvider as a component, the view developer
would still be able to use getText(...) expressions directly (via
TextProvider residing on the stack), without the need to write
textProvider.getText(...) given TextProviderAware introduces a
textProvider property on the action.
3. Although the use of getText expressions provide all the needed
functionality for i18n/l10n support, they are quite clumsy to use when
it comes to the widely used pattern of applying text formats to numbers
and dates. Adding a convenience property named format would held view
developers to get very easy access to those formats, without the need to
understand the getText signatures (I have to constantly look it up
again) for their most common use cases. Providing some reasonable
default formats would make it work out of the box, while the developer
could define additional formats as well as use getText expressions like
before when it comes to multiparameter formats etc.
That said, should we go to setup a (s|x) 2.2 roadmap in Confluence?
- Rene
Don Brown schrieb:
> Off the top of my head:
> * Split out the XML parser from XmlConfigurationProvider so that you
> can parse XML from any source
> * Get rid of all the Class.forName() calls in XWork
>
> I'd rather not do this on a stable branch, particularly since new
> public classes will be created. How many changes are there in 2.1.7
> and 2.1.3 that haven't been released? Could we get those releases out
> the door so we know we branch at a known good state?
>
> Don
>
> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>> I think we are good. What changes do you have in mind?, the OSGi
>> plugin could take advantage of some refactoring of xwork so I am
>> interested :)
>>
>> musachy
>>
>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>> how XWork configuration is loaded and parsed, but new classes and the
>>> like really isn't appropriate for a patch/micro release.
>>>
>>> Any objections to the branching?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
I forgot to say, we can roll a build without trouble, we just need to
release xwork first (I don't think there is any blocker for xwork).
musachy
On Fri, Apr 10, 2009 at 4:02 PM, Musachy Barroso <mu...@gmail.com> wrote:
> 2.1.7 has bug fixes and some small changes in Convention, nothing big.
>
> musachy
>
> On Fri, Apr 10, 2009 at 9:35 AM, Don Brown <mr...@twdata.org> wrote:
>> Off the top of my head:
>> * Split out the XML parser from XmlConfigurationProvider so that you
>> can parse XML from any source
>> * Get rid of all the Class.forName() calls in XWork
>>
>> I'd rather not do this on a stable branch, particularly since new
>> public classes will be created. How many changes are there in 2.1.7
>> and 2.1.3 that haven't been released? Could we get those releases out
>> the door so we know we branch at a known good state?
>>
>> Don
>>
>> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>>> I think we are good. What changes do you have in mind?, the OSGi
>>> plugin could take advantage of some refactoring of xwork so I am
>>> interested :)
>>>
>>> musachy
>>>
>>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>>> how XWork configuration is loaded and parsed, but new classes and the
>>>> like really isn't appropriate for a patch/micro release.
>>>>
>>>> Any objections to the branching?
>>>>
>>>> Don
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
2.1.7 has bug fixes and some small changes in Convention, nothing big.
musachy
On Fri, Apr 10, 2009 at 9:35 AM, Don Brown <mr...@twdata.org> wrote:
> Off the top of my head:
> * Split out the XML parser from XmlConfigurationProvider so that you
> can parse XML from any source
> * Get rid of all the Class.forName() calls in XWork
>
> I'd rather not do this on a stable branch, particularly since new
> public classes will be created. How many changes are there in 2.1.7
> and 2.1.3 that haven't been released? Could we get those releases out
> the door so we know we branch at a known good state?
>
> Don
>
> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>> I think we are good. What changes do you have in mind?, the OSGi
>> plugin could take advantage of some refactoring of xwork so I am
>> interested :)
>>
>> musachy
>>
>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>> how XWork configuration is loaded and parsed, but new classes and the
>>> like really isn't appropriate for a patch/micro release.
>>>
>>> Any objections to the branching?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Dave Newton <ne...@yahoo.com>.
Obinna wrote:
> Dave Newton updated the patch and applied/assigned to JIRA (
> https://issues.apache.org/struts/browse/WW-3009).
All I did was put it into a file so it was usable. If it needs to be
updated then delete the old attachment and attach a new patch file.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Obinna <ob...@gmail.com>.
I have actually been working slowly but steadily on the struts2-jquery
plugin that was discussed awhile back (
http://code.google.com/p/struts2-jquery-plugin). Sorry for the radio
silence. It's now fairly comprehensive and barring after a few TODOs (see
below) , probably ready for some very early-adopter use or perhaps better to
integrate with Wes' efforts. I have implemented the following tags so far:
*head*: injects required javascript libraries (including the
jquery.subscribe which I've released)
*div*: implements dynamic loading, reloading, topics listeners (eg.
onSuccess, onError, onComplete, onAlways, ...)
*a*: load to dynamic targets, serializes forms and individual elements,
topic listeners, publishing on events, progressIndicator
*form*: submit to dynamic target, topic listeners.
*submit*: similar to anchor
*select*: dynamic loading (requires result returned as json)
*tabbedpane *& *tab*: dynamic loading, reloading, disabling, topic
listeners, publish on events
TODOs:
- Build sample/test app - I have been testing quite a bit but only on an app
that I'm currently building for someone. Wes, you had said that you were
putting together a sample app in the sandbox, perhaps we can combine work
and work there.
- Proper documentation - documentation on site wiki is sparse and out of
date
- Finalize and test validation on form/submit/anchor tags
- Add structured support for jquery 'theming' and internationalization
- Some of the attributes may not be the most intuitive or 'struts-like' and
should be fixed (for example the anchor tag takes an 'href' instead of an
'action')
A couple of things:
- My approach has been far more akin to the easy-to-use, out-of-the-box
ajax attributes (similar to dojo but much more lightweight) than the
approach Wes has taken so far. IMO both are useful. As Wes said, this
provides a standardized easy to adopt framework that a majority of
struts-users may want. simultaneously, we can work on providing a
lower-level framework that may ultimately replace/support this and provide a
client-side view foundation, managing interactions between components,
optimised server communication, etc.
- The html produced by the tags is not always standard (non-standard
attributes are set in elements). I'm not sure if most would consider this
undesirable or an issue. The benefit of having it as it is is that the
jquery binding logic is fully contained in a single javascript file
(jquery.struts2) rather than trying to embed complex javascript into the
page which would make the templates complex and difficult to maintain.
- It doesn't explicitly require the json plugin or any other, however the
select tag expects valid json for asynchronous loading for which one would
almost certainly use the json plugin.
- I've tried to integrate the tags with the simple struts tags as much as
possible to allow users to make use of both the standard and ajax feature
where possible (for example, the select tag can still be populated from a
list in jsp but public an onChange topic.
- I have implemented both freemarker and javatemplates templates for the
tags, however using the freemarker templates requires some extensibility
updates to the javatemplates plugin (I have included an updated plugin.jar
with the source). Awhile ago, I submitted a patch to make the javatemplates
plugin a bit more extensible to allow custom themes and struts
configuration.
Dave Newton updated the patch and applied/assigned to JIRA (
https://issues.apache.org/struts/browse/WW-3009). The issue is currently
pending and still unassigned. I'm keen for this to make it into 2.1.7. Any
idea if/when this can be done? The patch needs to be updated a bit for the
StringUtils refactor. I would be very happy to contribute. In general is
there any movement on the javatemplates plugin for 2.1.7 (for example there
are a number of tags that still need to be implemented in SimpleTheme)?.
As I mentioned, the javatemplates code i have depends on the changes in the
patch, so is currently broken on latest build.
-Eric
2009/4/13 Wes Wannemacher <we...@wantii.com>
> On Sunday 12 April 2009 14:43:44 Frans Thamura wrote:
> > > Right now the plugin doesn't require the JSON plugin. It uses the
> > > JSONValidationInterceptor to handle validation with AJAX form
> submission.
> > > So, it only depends on core. I didn't want to be dependent on a
> > > non-hosted plugin and figured it was time to bring JSON into the core.
> I
> > > think Musachy and I figured we'd be able to get it brought in quicker
> > > than has happened.
> >
> > my cimande project wants to have this feature
> >
> > http://www.blueoxygen.org/wiki/index.php/Cimande:Architecture
> >
> > we inject the interceptor within spring, and make the form submission
> > translate automatically to hibernate model.
> >
> > can share your JSONValidationInterceptor concept ?
> >
> > i think we need to execute an action for every form submission
> >
> > F
>
> Frans,
>
> Check out this page -
>
> http://struts.apache.org/2.x/docs/ajax-validation.html
>
> In particular, check out the prototype example, it gives a good explanation
> of
> how to use the validation outside of the normal Dojo plugin.
>
> -Wes
>
> --
>
> Wes Wannemacher
> Author - Struts 2 In Practice
> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> http://www.manning.com/wannemacher
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Wes Wannemacher <we...@wantii.com>.
On Sunday 12 April 2009 14:43:44 Frans Thamura wrote:
> > Right now the plugin doesn't require the JSON plugin. It uses the
> > JSONValidationInterceptor to handle validation with AJAX form submission.
> > So, it only depends on core. I didn't want to be dependent on a
> > non-hosted plugin and figured it was time to bring JSON into the core. I
> > think Musachy and I figured we'd be able to get it brought in quicker
> > than has happened.
>
> my cimande project wants to have this feature
>
> http://www.blueoxygen.org/wiki/index.php/Cimande:Architecture
>
> we inject the interceptor within spring, and make the form submission
> translate automatically to hibernate model.
>
> can share your JSONValidationInterceptor concept ?
>
> i think we need to execute an action for every form submission
>
> F
Frans,
Check out this page -
http://struts.apache.org/2.x/docs/ajax-validation.html
In particular, check out the prototype example, it gives a good explanation of
how to use the validation outside of the normal Dojo plugin.
-Wes
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Frans Thamura <fr...@meruvian.org>.
> Right now the plugin doesn't require the JSON plugin. It uses the
> JSONValidationInterceptor to handle validation with AJAX form submission. So,
> it only depends on core. I didn't want to be dependent on a non-hosted plugin
> and figured it was time to bring JSON into the core. I think Musachy and I
> figured we'd be able to get it brought in quicker than has happened.
my cimande project wants to have this feature
http://www.blueoxygen.org/wiki/index.php/Cimande:Architecture
we inject the interceptor within spring, and make the form submission
translate automatically to hibernate model.
can share your JSONValidationInterceptor concept ?
i think we need to execute an action for every form submission
F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Wes Wannemacher <we...@wantii.com>.
On Sunday 12 April 2009 14:32:31 Frans Thamura wrote:
> yours jquery will work on top of json plugins, isnt it?
>
> i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
> and REST producer
>
> F
>
Right now the plugin doesn't require the JSON plugin. It uses the
JSONValidationInterceptor to handle validation with AJAX form submission. So,
it only depends on core. I didn't want to be dependent on a non-hosted plugin
and figured it was time to bring JSON into the core. I think Musachy and I
figured we'd be able to get it brought in quicker than has happened.
As I mentioned on another thread, I have some bandwidth this week, so we'll
get this back up and going.
-Wes
PS. Happy Easter everyone!
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Frans Thamura <fr...@meruvian.org>.
yours jquery will work on top of json plugins, isnt it?
i am waiting the JSON-RPC implementation so we can make S2 as JSONRPC
and REST producer
F
On Mon, Apr 13, 2009 at 1:11 AM, Wes Wannemacher <we...@wantii.com> wrote:
> On Sunday 12 April 2009 14:08:48 you wrote:
>> > Once the plugin is moved over, I am planning to pick the JQuery plugin
>> > back up. Right now there is a datepicker, form submission with validation
>> > (via AJAX)... Are there other features that anyone wants in particular?
>> > My goal is
>>
>> love to hear this good news ;)
>>
>> F
>
> Feel free to check it out and contribute -
>
> http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-jquery-plugin/
>
> -Wes
>
> --
>
> Wes Wannemacher
> Author - Struts 2 In Practice
> Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
> http://www.manning.com/wannemacher
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
--
Frans Thamura
Meruvian. Java and Enterprise OSS
Mobile: +62 855 7888 699
Blog & Profile: http://frans.thamura.info
We provide services to migrate your apps to Java (web), in amazing
fast and reliable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Wes Wannemacher <we...@wantii.com>.
On Sunday 12 April 2009 14:08:48 you wrote:
> > Once the plugin is moved over, I am planning to pick the JQuery plugin
> > back up. Right now there is a datepicker, form submission with validation
> > (via AJAX)... Are there other features that anyone wants in particular?
> > My goal is
>
> love to hear this good news ;)
>
> F
Feel free to check it out and contribute -
http://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-jquery-plugin/
-Wes
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Frans Thamura <fr...@meruvian.org>.
>
> Once the plugin is moved over, I am planning to pick the JQuery plugin back
> up. Right now there is a datepicker, form submission with validation (via
> AJAX)... Are there other features that anyone wants in particular? My goal is
love to hear this good news ;)
F
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Wes Wannemacher <we...@wantii.com>.
On Sunday 12 April 2009 13:24:51 Musachy Barroso wrote:
> We need for one of the contributors to fax in the CLA. Is that all we need
> Wes?
>
> musachy
>
> On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura <fr...@meruvian.org> wrote:
> > is it possible the JSON plugins as default bundle for S2 2.2
> >
> > F
Yes, I am waiting on that and I'll do the legwork to bring the plugin in.
Once the plugin is moved over, I am planning to pick the JQuery plugin back
up. Right now there is a datepicker, form submission with validation (via
AJAX)... Are there other features that anyone wants in particular? My goal is
to keep it somewhat thin. I want to provide the features of JQuery, but not
quite as much abstraction as the original Dojo integration. I was waiting to
see if we could use a JQuery publish/subscribe/notify event handling library
that someone has on a googlecode plugin, but I haven't heard from the author
in a while.
-Wes
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
We need for one of the contributors to fax in the CLA. Is that all we need Wes?
musachy
On Sun, Apr 12, 2009 at 12:40 PM, Frans Thamura <fr...@meruvian.org> wrote:
> is it possible the JSON plugins as default bundle for S2 2.2
>
> F
>
> On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso <mu...@gmail.com> wrote:
>> The problem I have is that once the Container is built, there is no
>> way to register new beans into it. The side effect of this is that
>> "constants" and "beans" that are defined in bundled xml config files
>> are never loaded into the container. It is the only limitation so far
>> for the OSGi plugin.
>>
>> musachy
>>
>> On Fri, Apr 10, 2009 at 9:35 AM, Don Brown <mr...@twdata.org> wrote:
>>> Off the top of my head:
>>> * Split out the XML parser from XmlConfigurationProvider so that you
>>> can parse XML from any source
>>> * Get rid of all the Class.forName() calls in XWork
>>>
>>> I'd rather not do this on a stable branch, particularly since new
>>> public classes will be created. How many changes are there in 2.1.7
>>> and 2.1.3 that haven't been released? Could we get those releases out
>>> the door so we know we branch at a known good state?
>>>
>>> Don
>>>
>>> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>>>> I think we are good. What changes do you have in mind?, the OSGi
>>>> plugin could take advantage of some refactoring of xwork so I am
>>>> interested :)
>>>>
>>>> musachy
>>>>
>>>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>>>> how XWork configuration is loaded and parsed, but new classes and the
>>>>> like really isn't appropriate for a patch/micro release.
>>>>>
>>>>> Any objections to the branching?
>>>>>
>>>>> Don
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> --
> Frans Thamura
> Meruvian. Java and Enterprise OSS
>
> Mobile: +62 855 7888 699
> Blog & Profile: http://frans.thamura.info
>
> We provide services to migrate your apps to Java (web), in amazing
> fast and reliable.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Frans Thamura <fr...@meruvian.org>.
is it possible the JSON plugins as default bundle for S2 2.2
F
On Sun, Apr 12, 2009 at 11:34 PM, Musachy Barroso <mu...@gmail.com> wrote:
> The problem I have is that once the Container is built, there is no
> way to register new beans into it. The side effect of this is that
> "constants" and "beans" that are defined in bundled xml config files
> are never loaded into the container. It is the only limitation so far
> for the OSGi plugin.
>
> musachy
>
> On Fri, Apr 10, 2009 at 9:35 AM, Don Brown <mr...@twdata.org> wrote:
>> Off the top of my head:
>> * Split out the XML parser from XmlConfigurationProvider so that you
>> can parse XML from any source
>> * Get rid of all the Class.forName() calls in XWork
>>
>> I'd rather not do this on a stable branch, particularly since new
>> public classes will be created. How many changes are there in 2.1.7
>> and 2.1.3 that haven't been released? Could we get those releases out
>> the door so we know we branch at a known good state?
>>
>> Don
>>
>> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>>> I think we are good. What changes do you have in mind?, the OSGi
>>> plugin could take advantage of some refactoring of xwork so I am
>>> interested :)
>>>
>>> musachy
>>>
>>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>>> how XWork configuration is loaded and parsed, but new classes and the
>>>> like really isn't appropriate for a patch/micro release.
>>>>
>>>> Any objections to the branching?
>>>>
>>>> Don
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
--
Frans Thamura
Meruvian. Java and Enterprise OSS
Mobile: +62 855 7888 699
Blog & Profile: http://frans.thamura.info
We provide services to migrate your apps to Java (web), in amazing
fast and reliable.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
The problem I have is that once the Container is built, there is no
way to register new beans into it. The side effect of this is that
"constants" and "beans" that are defined in bundled xml config files
are never loaded into the container. It is the only limitation so far
for the OSGi plugin.
musachy
On Fri, Apr 10, 2009 at 9:35 AM, Don Brown <mr...@twdata.org> wrote:
> Off the top of my head:
> * Split out the XML parser from XmlConfigurationProvider so that you
> can parse XML from any source
> * Get rid of all the Class.forName() calls in XWork
>
> I'd rather not do this on a stable branch, particularly since new
> public classes will be created. How many changes are there in 2.1.7
> and 2.1.3 that haven't been released? Could we get those releases out
> the door so we know we branch at a known good state?
>
> Don
>
> On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
>> I think we are good. What changes do you have in mind?, the OSGi
>> plugin could take advantage of some refactoring of xwork so I am
>> interested :)
>>
>> musachy
>>
>> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>>> off and move trunk to 2.2? I was wanting to do some refactoring of
>>> how XWork configuration is loaded and parsed, but new classes and the
>>> like really isn't appropriate for a patch/micro release.
>>>
>>> Any objections to the branching?
>>>
>>> Don
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>>
>>
>>
>>
>> --
>> "Hey you! Would you help me to carry the stone?" Pink Floyd
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Don Brown <mr...@twdata.org>.
Off the top of my head:
* Split out the XML parser from XmlConfigurationProvider so that you
can parse XML from any source
* Get rid of all the Class.forName() calls in XWork
I'd rather not do this on a stable branch, particularly since new
public classes will be created. How many changes are there in 2.1.7
and 2.1.3 that haven't been released? Could we get those releases out
the door so we know we branch at a known good state?
Don
On Fri, Apr 10, 2009 at 11:25 PM, Musachy Barroso <mu...@gmail.com> wrote:
> I think we are good. What changes do you have in mind?, the OSGi
> plugin could take advantage of some refactoring of xwork so I am
> interested :)
>
> musachy
>
> On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
>> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
>> off and move trunk to 2.2? I was wanting to do some refactoring of
>> how XWork configuration is loaded and parsed, but new classes and the
>> like really isn't appropriate for a patch/micro release.
>>
>> Any objections to the branching?
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Ready for Struts 2.2 and XWork 2.2?
Posted by Musachy Barroso <mu...@gmail.com>.
I think we are good. What changes do you have in mind?, the OSGi
plugin could take advantage of some refactoring of xwork so I am
interested :)
musachy
On Fri, Apr 10, 2009 at 8:24 AM, Don Brown <mr...@twdata.org> wrote:
> Now that 2.1 is GA (thanks guys and gals), are we ready to branch it
> off and move trunk to 2.2? I was wanting to do some refactoring of
> how XWork configuration is loaded and parsed, but new classes and the
> like really isn't appropriate for a patch/micro release.
>
> Any objections to the branching?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org