Re: [s2] Proposal: Rest Plugin

[Craig McClanahan]

On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > >
> > > [...]
> > > Which reminds me, this plugin is targeted towards HTML-based web apps
> > > that want to expose their information in machine-readable ways (XML
> > > and JSON),
> >
> >
> > I presume you mean DOM-based apps; some of us don't use HTML any more. ;-)
>
> HTML = text format that you want to manually generate using jsp,
> velocity, or freemarker

What happens when different clients want different representations?
This is one of the places where Rails does a pretty nice job, using
the respond_to method to let the controller choose which
representation to produce, based on some combination of (a) what did
the client ask for (via a content type header or a format suffix on
the URL), and (b) what representations are available in the app.

On the other hand, when combined with a plugin like
make_resourceful[1] , a Rails controller supporting simple things like
CRUD operations, with multiple representations, can be incredibly
concise.  (Rails lets you define multiple related actions in a single
controller, so this is all in one class.)  The domain of interest in
this example is the posts on a blog system.

  class PostController << ApplicationController
make_resourceful do
  actions :all
  publish :xml, :json, :yaml,
attributes => [ :id, :title, :body,
 { :comments => [ :id, :author, :body  ]  }
   ]
end;
  end;

That's the whole controller (without make_resourceful it'd be about
100 lines of code) ... but it allows you to select any of XML, JSON,
or YAML (a text format for hierarchical data commonly used in Rails
config files, but not restricted to Ruby).  Adding HTML as an output
option is one more entry on the publish line (plus writing the
corresponding views in your favorite template language).  And this
controller automatically maps *all* of the following (think of them as
context relative) URLs to the specified controller actions, which
perform the specified tasks:

  # POST /posts -- create a new post and return status 201 plus a
Location header with the
  # appropriate URL to access the newly created post instance
  def create ... end

  # DELETE /posts/xxx -- delete the post row with key xxx
  def delete ... end

  # GET /posts/xxx/edit -- create an HTML entry form for the post with
key xxx; the
  # resulting PUT will call the update() action.  Only used for HTML
representation
  # (in earlier edge rails, this was ";edit" instead of "/edit")
  def edit ... end

  # GET /posts -- return an HTML table or a data structure in the
requested format
  def index ...  end

  # GET /posts/new -- create an HTML entry form for a new post
instance; the resulting
  # POST will trigger the create() action.  Only used for HTML representation
  # (prior to edge rails, this was ";new" instead of "/new")
  def new ... end

  # GET /posts/xxx -- return HTML details or data representation of
post with key xxx
  def show ... end

  # PUT /posts/xxx -- update the post row with key xxx from parameters
in this request
  def update ... end

Several notes are important to understand if you're not familiar with
Rails REST support:

* With make_resourceful, you don't actually write the above methods at
all -- they
  are generated at runtime.  The source code above is what the
developer writes (plus any
  HTML views).  Can you write a complete CRUD web service with
Struts2, supporting
  multiple representations, in nine lines of code (minus HTML views)?

* Without make_resourceful, there's a Rails generator that will
actually generate all
  this code -- but you end up with ~100 lines per controller, with a
pattern that is repeated
  in every controller with only a few details being different.  That's
not optimal, which is
  why a plugin like this got created.  It won't be part of Rails 2.0
core (the Rails core
  developers have a similar allergy to a bloated core that the Struts2
developers have),
  but it's readily available.

* You can add additional actions that are related, and this is not
uncommon for special
  purpose requests that don't strictly conform to CRUD operations but
share the same
  requirements for data acquisition.

* For index and show, the client requests the representation they
want, either via an
  accept header specifying the content type, or adding ".xml",
".json", or ".yml" to the URL.

* A client of a RESTful web service will never need the "edit" or
"new" actions ... it will
  simply interact directly with "update" or "create" appropriately.

* The Rails helper methods for form based HTML input have workarounds
for the fact
  that browsers do not actually know how to do a PUT or DELETE (except
in an Ajax
  callback).  This kind of thing could easily be implemented in the
server side view
  representation, but it'll be specific to whatever templat

Re: [S2] Plugins gone wild!

[Martin Gilday]

I haven't been following this topic too closely, so apologies if I have
missed the point.  Why is dojo being considered a core plugin?  I
understand it is used by some of the tags to simplify some AJAX tasks,
are there any other benefits to it?.  From my brief experience with it
Dojo is not the most designer friendly framework, more the home of
widget developers.  In our apps we have found it simpler, and we have
more control with, using a mix of Prototype and rolling our own JSON. 
Our designers are much more comfortable with something like Prototype,
JQuery or YUI.  When I read the name "core" it reads to me as plugins I
really should need.  I guess it depends on your point of view but I
would consider something like Spring a more essential plugin than dojo,
especially as many apps move away from the classic tags->html view.  My
point really is the name core may be confusing/misleading, more so as
there is already struts2-core.


- Original message -
From: "Don Brown" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Date: Tue, 23 Oct 2007 10:38:02 +1000
Subject: Re: [S2] Plugins gone wild!

It might be interesting to have several "bundles":
 * Core - codebehind, dojo
 * Starter - codebehind, dojo, spring, jpa
 * Rest - codebehind, rest, dojo

Of course, the value of this bundle concept is low for those that use
Maven 2 or any other transitive dependency system.  For my rest
example application, my pom only declares one dependency, the rest
plugin, and Maven handes everything from there.

Also, I wouldn't include the rest plugin in core as it places some
strict requirements on the format of the url that won't be compatible
with most Struts 2 apps.

Don

On 10/23/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> > Bringing together a couple of other threads, for Struts 2.1.x  (or
> > even Struts 2.2.x), we seem to be talking about
> >
> > * Creating a "plugin" artifact, along the lines of the "apps"
> > artifact, which would include all the plugins we maintain in the
> > Struts repository
> >
> > * Creating a "struts2-core-plugin" artifact that would include the
> > plugins that are needed to write a "typical" Struts 2 application.
> >
> > The "struts2-core-plugins" artifact would contain the equivalent of the
> >
> > * codebehind plugin (including zero-config)
> > * JSON plugin
> > * restful plugin
> >
> > along with new
> >
> > * annotations plugin
> > * tags plugin
> >
> > I haven't looked into yet, but we might also consider a "persistence"
> > plugin with JPA support, if that makes any sense.
>
>
> I'd just as soon see persistence left out of this "core plugins" artifact.
> Perhaps I'm some weird corner case, but in over 7 years of building
> enterprise web apps, I've never been in a position to use any kind of
> standard persistence mechanism. That being the case, it doesn't strike me as
> something that should be part of "core" anything.
>
> --
> Martin Cooper
>
>
> The Struts "lib" artifact would host the struts2-core.jar, the
> > struts2-core-plugins.jar, and whatever dependencies these artifacts
> > require.
> >
> > We could use strut2-core.jar with the struts2-core-plugins.jar, and
> > just add any other plugins we like that do not overlap with the core
> > plugins, or mix and match strut2-core.jar with whatever plugins are
> > preferred (if any).
> >
> > Ideally, the same code would be available in the
> > struts2-core-plugin.jar and as standalone plugins. The key problem
> > might be glomming together the struts-plugin.xmls, since I believe we
> > only get one to a JAR.
> >
> > Arguably, we could also include an Ajax plugin in the "standard
> > array", but I would like to explore alternatives to the Dojo plugin. I
> > think we should maintain a Dojo plugin, just as we plan to maintain a
> > Spring plugin, but I'd also like to try an AjaxParts or a (complete)
> > YUI plugin before we pull the trigger.
> >
> > We might also want to consider whether we should grow the JSON plugin
> > into a web-services plugin. Starting next month, I'll be doing a lot
> > more work with web services myself.
> >
> > -Ted.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Don Brown]

Great post, Craig.  Most everything you describe is supported by the
Rest Plugin:
 * All the described URL patterns
 * The automatic use of the Location header after a POST
 * Ability to switch representation using extension (adding accept
header support would be easy)
 *  All actions are on one Controller class
 * XML and JSON outputs are automatically generated and processed on POST/PUT
 * Ability to customize XML and JSON output (declare a result named
"NAME-EXTENSION", e.g. "success-xml"
 * Support for any additional action method
 * Workaround support for browsers that can't PUT or DELETE (using the
_method parameter just like Rails)
 * Code doesn't know or care if the request came from a browser or
service client

The reason all the Rails features are supported is a blatantly copied
their design and conventions.  In addition to easing the transition of
one familiar with Rails and using a proven design, it means clients
written for Rails apps will work with no changes.  The pieces that are
missing are the backend, database-touching stuff like ActiveRecord or
the automatic HTML generation.  So while you wouldn't get the quick
initial development speed of Rails, you get all the core framework
support and then some.

Some things that Struts 2 with the Rest Plugin has (or will have) that
Rails doesn't:
 * Type-safe cache header (last-modified and etag) support
 * Better view abstraction with the Result object so paths aren't
hard-coded into your class
 * The controller doesn't have to have any knowledge of the
representation types it supports - all automatic
 * Automatic partial GET support (not done yet, but it is next)
 * WADL support (again, coming soon)

Don't get me wrong, I'm not trying to make Struts 2 go up against
Rails, but rather, I think it is past time we applied the lessons of
Rails' Rest support to a Java framework and I think Struts 2 is the
perfect match.

Don

On 10/23/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > On 10/22/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > > On 10/21/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > > >
> > > > [...]
> > > > Which reminds me, this plugin is targeted towards HTML-based web apps
> > > > that want to expose their information in machine-readable ways (XML
> > > > and JSON),
> > >
> > >
> > > I presume you mean DOM-based apps; some of us don't use HTML any more. ;-)
> >
> > HTML = text format that you want to manually generate using jsp,
> > velocity, or freemarker
>
> What happens when different clients want different representations?
> This is one of the places where Rails does a pretty nice job, using
> the respond_to method to let the controller choose which
> representation to produce, based on some combination of (a) what did
> the client ask for (via a content type header or a format suffix on
> the URL), and (b) what representations are available in the app.
>
> On the other hand, when combined with a plugin like
> make_resourceful[1] , a Rails controller supporting simple things like
> CRUD operations, with multiple representations, can be incredibly
> concise.  (Rails lets you define multiple related actions in a single
> controller, so this is all in one class.)  The domain of interest in
> this example is the posts on a blog system.
>
>   class PostController << ApplicationController
> make_resourceful do
>   actions :all
>   publish :xml, :json, :yaml,
> attributes => [ :id, :title, :body,
>  { :comments => [ :id, :author, :body  ]  }
>]
> end;
>   end;
>
> That's the whole controller (without make_resourceful it'd be about
> 100 lines of code) ... but it allows you to select any of XML, JSON,
> or YAML (a text format for hierarchical data commonly used in Rails
> config files, but not restricted to Ruby).  Adding HTML as an output
> option is one more entry on the publish line (plus writing the
> corresponding views in your favorite template language).  And this
> controller automatically maps *all* of the following (think of them as
> context relative) URLs to the specified controller actions, which
> perform the specified tasks:
>
>   # POST /posts -- create a new post and return status 201 plus a
> Location header with the
>   # appropriate URL to access the newly created post instance
>   def create ... end
>
>   # DELETE /posts/xxx -- delete the post row with key xxx
>   def delete ... end
>
>   # GET /posts/xxx/edit -- create an HTML entry form for the post with
> key xxx; the
>   # resulting PUT will call the update() action.  Only used for HTML
> representation
>   # (in earlier edge rails, this was ";edit" instead of "/edit")
>   def edit ... end
>
>   # GET /posts -- return an HTML table or a data structure in the
> requested format
>   def index ...  end
>
>   # GET /posts/new -- create an HTML entry form for a new post
> instance; the resulting
>   # POST will trigger the create()

Re: [S2] Plugins gone wild!

[Ted Husted]

Initially, it was just knee-jerk backward-compatibility with the Ajax
theme. But, I think this is a good point. If we want extensions to the
base tags, we can always just drop in whatever other plugin we like.
Or just use Ajax "out of the box", without the plugin grease.

The name "core" came about when we started to discuss moving bits like
the tags into a plugin. Spring does something similar by combining the
most common JARs into a single spring.jar.

-Ted.

On 10/23/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
> I haven't been following this topic too closely, so apologies if I have
> missed the point.  Why is dojo being considered a core plugin?  I
> understand it is used by some of the tags to simplify some AJAX tasks,
> are there any other benefits to it?.  From my brief experience with it
> Dojo is not the most designer friendly framework, more the home of
> widget developers.  In our apps we have found it simpler, and we have
> more control with, using a mix of Prototype and rolling our own JSON.
> Our designers are much more comfortable with something like Prototype,
> JQuery or YUI.  When I read the name "core" it reads to me as plugins I
> really should need.  I guess it depends on your point of view but I
> would consider something like Spring a more essential plugin than dojo,
> especially as many apps move away from the classic tags->html view.  My
> point really is the name core may be confusing/misleading, more so as
> there is already struts2-core.
>
>
> - Original message -
> From: "Don Brown" <[EMAIL PROTECTED]>
> To: "Struts Developers List" 
> Date: Tue, 23 Oct 2007 10:38:02 +1000
> Subject: Re: [S2] Plugins gone wild!
>
> It might be interesting to have several "bundles":
>  * Core - codebehind, dojo
>  * Starter - codebehind, dojo, spring, jpa
>  * Rest - codebehind, rest, dojo
>
> Of course, the value of this bundle concept is low for those that use
> Maven 2 or any other transitive dependency system.  For my rest
> example application, my pom only declares one dependency, the rest
> plugin, and Maven handes everything from there.
>
> Also, I wouldn't include the rest plugin in core as it places some
> strict requirements on the format of the url that won't be compatible
> with most Struts 2 apps.
>
> Don
>
> On 10/23/07, Martin Cooper <[EMAIL PROTECTED]> wrote:
> > On 10/22/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> > >
> > > Bringing together a couple of other threads, for Struts 2.1.x  (or
> > > even Struts 2.2.x), we seem to be talking about
> > >
> > > * Creating a "plugin" artifact, along the lines of the "apps"
> > > artifact, which would include all the plugins we maintain in the
> > > Struts repository
> > >
> > > * Creating a "struts2-core-plugin" artifact that would include the
> > > plugins that are needed to write a "typical" Struts 2 application.
> > >
> > > The "struts2-core-plugins" artifact would contain the equivalent of the
> > >
> > > * codebehind plugin (including zero-config)
> > > * JSON plugin
> > > * restful plugin
> > >
> > > along with new
> > >
> > > * annotations plugin
> > > * tags plugin
> > >
> > > I haven't looked into yet, but we might also consider a "persistence"
> > > plugin with JPA support, if that makes any sense.
> >
> >
> > I'd just as soon see persistence left out of this "core plugins" artifact.
> > Perhaps I'm some weird corner case, but in over 7 years of building
> > enterprise web apps, I've never been in a position to use any kind of
> > standard persistence mechanism. That being the case, it doesn't strike me as
> > something that should be part of "core" anything.
> >
> > --
> > Martin Cooper
> >
> >
> > The Struts "lib" artifact would host the struts2-core.jar, the
> > > struts2-core-plugins.jar, and whatever dependencies these artifacts
> > > require.
> > >
> > > We could use strut2-core.jar with the struts2-core-plugins.jar, and
> > > just add any other plugins we like that do not overlap with the core
> > > plugins, or mix and match strut2-core.jar with whatever plugins are
> > > preferred (if any).
> > >
> > > Ideally, the same code would be available in the
> > > struts2-core-plugin.jar and as standalone plugins. The key problem
> > > might be glomming together the struts-plugin.xmls, since I believe we
> > > only get one to a JAR.
> > >
> > > Arguably, we could also include an Ajax plugin in the "standard
> > > array", but I would like to explore alternatives to the Dojo plugin. I
> > > think we should maintain a Dojo plugin, just as we plan to maintain a
> > > Spring plugin, but I'd also like to try an AjaxParts or a (complete)
> > > YUI plugin before we pull the trigger.
> > >
> > > We might also want to consider whether we should grow the JSON plugin
> > > into a web-services plugin. Starting next month, I'll be doing a lot
> > > more work with web services myself.
> > >
> > > -Ted.
> > >
> > > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> 

Re: [S2] Plugins gone wild!

[Ted Husted]

On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> It might be interesting to have several "bundles":
>  * Core - codebehind, dojo
>  * Starter - codebehind, dojo, spring, jpa
>  * Rest - codebehind, rest, dojo

This might be a great role for AppFuse-style Maven prototypes!

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Ted Husted]

On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> True, but I was talking about APT, and in that case it's not really
> making anything easier as far as I can tell... APT is already pretty
> close to plug-and-play as you know... aside from making the config file
> name a default, which would benefit both the plugin and APT outside of
> S2, can you see any way to make it more useful as a plugin?

Dojo is plug-and-play too, but the Dojo plugin is powering Struts tags
behind the scenes.

 *  http://struts.apache.org/2.x/docs/ajax-tags.html
 *  http://struts.apache.org/2.x/docs/ajax-and-javascript-recipes.html

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Ted Husted]

So, to follow-up, the amended struts-core-plugins.jar list seems to be

  * annotations plugin (new)
  * codebehind plugin (including zero-config)
  * tags plugin (new)

I'd like to keep codebehind in the core, since I believe we are on
track for making XML-action-free Struts apps the recommended approach.

Though, when we say that, I don't think we need to excise the
struts.xml and go back to using struts.properties. Using the
struts.xml to set one-time global configuration parameters is very
different from using the struts.xml to describe all of the
application's actions.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fixing theme inheritance

[Ted Husted]

The problem seems to be that we need a volunteer who is eager to work
on this feature. The patch was a start, but only a start, and the
comments indicate that there is still a lot of work to do.

-Ted.

On 10/19/07, Aymeric Levaux <[EMAIL PROTECTED]> wrote:
> Hi,
>
> At this time there is no way to extend a theme in a good way. See
> https://issues.apache.org/struts/browse/WW-1328
> It would be great to have this issue fixed for 2.1 as there is already a
> patch which looks good and this fix would allow much more possibilities
> for plugin development.
>
> --
> Aymeric Levaux

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 2.0.11 Quality - RESULT

[Ted Husted]

+1 GA binding

 * Antonio Petrelli
 * Ted Husted
 * Rainer Hermanns

+1 GA supporting

 * Piero Sartini
 * Matt Raible (committer)
 * Pedro Herrera

Struts 2.0.11 is now rated at GA, and I will proceed to announce the release.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Martin Gilday]

Where abouts is the annotations plugin housed?  I could not see it in
the struts2 trunk or sandbox trunk.  Following Don's comment in this
https://issues.apache.org/struts/browse/WW-2264 I was interested in
trying to created this feature "A new feature we could add would be a
new annotation so that a user could annotate which setters/getters can
be accessed, which is probably a good idea regardless.".  My initial
idea was another flag on the parameter interceptor which, when enabled,
would only set against the action when an annotation is present on the
setter.  It might make more sense for this feature/annotation to be part
of the annotations plugin.  Does anyone else see this as a useful
feautre?  I'd rather annotate what I want to permit to be set than
exclude my DAO/Services (which are required by the Spring plugin).


- Original message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Date: Tue, 23 Oct 2007 06:20:13 -0400
Subject: Re: [S2] Plugins gone wild!

So, to follow-up, the amended struts-core-plugins.jar list seems to be

  * annotations plugin (new)
  * codebehind plugin (including zero-config)
  * tags plugin (new)

I'd like to keep codebehind in the core, since I believe we are on
track for making XML-action-free Struts apps the recommended approach.

Though, when we say that, I don't think we need to excise the
struts.xml and go back to using struts.properties. Using the
struts.xml to set one-time global configuration parameters is very
different from using the struts.xml to describe all of the
application's actions.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Ted Husted]

The source has been moved to the codebehind plugin. The package is
org.apache.struts2.config. If we keep it there, which is fine with me,
then we wouldn't need a separate annotations plugin.

 * 
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/codebehind/src/main/java/org/apache/struts2/config/

-Ted.

On 10/23/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
> Where abouts is the annotations plugin housed?  I could not see it in
> the struts2 trunk or sandbox trunk.  Following Don's comment in this
> https://issues.apache.org/struts/browse/WW-2264 I was interested in
> trying to created this feature "A new feature we could add would be a
> new annotation so that a user could annotate which setters/getters can
> be accessed, which is probably a good idea regardless.".  My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> setter.  It might make more sense for this feature/annotation to be part
> of the annotations plugin.  Does anyone else see this as a useful
> feautre?  I'd rather annotate what I want to permit to be set than
> exclude my DAO/Services (which are required by the Spring plugin).
>
>
> - Original message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: "Struts Developers List" 
> Date: Tue, 23 Oct 2007 06:20:13 -0400
> Subject: Re: [S2] Plugins gone wild!
>
> So, to follow-up, the amended struts-core-plugins.jar list seems to be
>
>   * annotations plugin (new)
>   * codebehind plugin (including zero-config)
>   * tags plugin (new)
>
> I'd like to keep codebehind in the core, since I believe we are on
> track for making XML-action-free Struts apps the recommended approach.
>
> Though, when we say that, I don't think we need to excise the
> struts.xml and go back to using struts.properties. Using the
> struts.xml to set one-time global configuration parameters is very
> different from using the struts.xml to describe all of the
> application's actions.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
HTH, Ted 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[S2] Annotations (was Plugins gone wild!)

[Ted Husted]

On 10/23/07, Martin Gilday <[EMAIL PROTECTED]> wrote:
> Where abouts is the annotations plugin housed?  I could not see it in
> the struts2 trunk or sandbox trunk.  Following Don's comment in this
> https://issues.apache.org/struts/browse/WW-2264 I was interested in
> trying to created this feature "A new feature we could add would be a
> new annotation so that a user could annotate which setters/getters can
> be accessed, which is probably a good idea regardless.".

We've been doing something like this with .NET at work, except that we
were listing the properties an "action" accepted in XML. I like the
concept, since it more clearly defines the API contract, but I was
always, always, always, adding new properties and forgetting to add
them to the list. With annotations, this might be less of a problem,
but this is also a place where's Matt's "fumble-finger" alerts would
be helpful.

A related idea would be an "accept" validator that says populating the
property is permitted but optional. In that case,  a strict validation
mode would reject any properties without a validator.

Either way, this feature could also lead to actions being able to
describe themselves, the way services do.  (Hmm, are annotations tied
to JavaDocs these days?)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Struts 2.0.11 Quality - RESULT

[Ted Husted]

The release has been submitted for mirroring. Here's a draft
announcement that we could post tomorrow morning. Is there anything in
the release that we should be highlighting?



The Apache Struts group is pleased to announce that Struts 2.0.11 is
available as a "General Availability" release. The GA designation is
our highest quality grade.

Apache Struts 2 is an elegant, extensible framework for creating
enterprise-ready Java web applications. The framework is designed to
streamline the full development cycle, from building, to deploying, to
maintaining applications over time.

This release includes a number of fixes and improvements since the
2.0.9 GA release. Struts 2.0.11 is available in a full distribution,
or as separate library, source, example and documentation
distributions, from the releases page. The release is also available
through the central Maven repository under Group ID
"org.apache.struts". The release notes are available online.

The 2.0.x series of the Apache Struts framework has a minimum
requirement of the following specification versions: Servlet API 2.4,
JSP API 2.0, Java 5, Backported Java 4 JARs are also available.

Should any issues arise with your use of any version of the Struts
framework, please post your comments to the user list, and, if
appropriate, file a ticket with JIRA.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Ted Husted]

On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
>  * Ability to customize XML and JSON output (declare a result named
> "NAME-EXTENSION", e.g. "success-xml"

Why not make this "name.extension", and make it part of the core framework?

Instead of just having one default result, we could have a default
result for various extension types. Not just for this plugin, but for
all XWork2 applications.


> The reason all the Rails features are supported is a blatantly copied
> their design and conventions.  In addition to easing the transition of
> one familiar with Rails and using a proven design, it means clients
> written for Rails apps will work with no changes.

I'd suggest that then we just call this the "Rails" plugin, but I
believe that Rails is a protected mark. In any event, we might want to
start thinking of this plugin as a way to run Rails-type applications
in a Struts environment, and perhaps come up with a name that
communicates that goal.


> The pieces that are
> missing are the backend, database-touching stuff like ActiveRecord or
> the automatic HTML generation.  So while you wouldn't get the quick
> initial development speed of Rails, you get all the core framework
> support and then some.

Oh, I don't know. Throw in JPA and some Maven archetypes, and you
could hit the ground running for the common use cases. A key technique
might be to develop archetypes that we could run for adding new
pages/actions/entities/tests to existing applications. Between POJO
Actions and codebehinds, we might be able to do useful CRUD with zero
lines of Struts framework code.

MyEclipse has some stunning DAO generation and JPA integration
capabilities. For what we can't do with our plugins, we might be able
to do with Eclipse plugins.


> Don't get me wrong, I'm not trying to make Struts 2 go up against
> Rails,

Why not? A lot of teams do not have a snowball's chance of adopting
Rails anytime soon. But, they might have a chance of moving from
Struts 1 to Struts 2, and then adopting the "agile" prototype. I think
a lot more of us would use Rails if we could, but the reality is that
we can't, and Struts with a Rails workalike plugin is going to be the
next best thing.


> but rather, I think it is past time we applied the lessons of
> Rails' Rest support to a Java framework and I think Struts 2 is the
> perfect match.

I think we all have the same goals, the question is how can we achieve
those same goals from a Struts/Java perspective.

It's my understanding that Rails is as much about mindset and culture
as it is about code. There are a lot of ways we can streamline the way
we write Java code, so that we can do more with less. A lot times it
seems to me like we Java developers go out of our way to make more
work for ourselves.,

The real lesson Rails is that we should stop following voo-doo
conventions that exist for no apparent reason, and create new
conventions that actually help us do more with less code.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Ted Husted]

(From "Plugins gone Wild")

On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> Also, I wouldn't include the rest plugin in core as it places some
> strict requirements on the format of the url that won't be compatible
> with most Struts 2 apps.

That's a good point. I went over the Rails conventions for REST, and I
would agree that they would tend to conflict with other trends in
Struts development. To further the discussion, I put together some
notes regarding some REST conventions that would better coincide with
our own general direction.

 * 
http://cwiki.apache.org/confluence/display/S2PLUGINS/RESTful+CRUD+for+HTML+methods

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Ted Husted]

Craig McClanahan wrote:
> I've gone over to the dark side :-)

No, no, no. I went over to the dark side when I stuck with my team
after the organization switched to .NET. :)

Personally, I'd characterize going over to Rails as walking into the light :)

We have several other Struts committers that alternate between Rails
and Struts. I think everyone here admires Rails, the same way that we
admired WebWork. Sadly, technical and market realities don't allow
each of us to freely decide which framework to use on which project.

Who knows, maybe one day I'll get to switch to IronRails :)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Don Brown]

On 10/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> Why not make this "name.extension", and make it part of the core framework?
>
> Instead of just having one default result, we could have a default
> result for various extension types. Not just for this plugin, but for
> all XWork2 applications.

Not a bad idea, but it would need more thought and testing before I'd
put something like that in core.  Even if we did, the rest plugin
would still need to have its own ActionInvocation due to its automatic
result processing.

> I'd suggest that then we just call this the "Rails" plugin, but I
> believe that Rails is a protected mark. In any event, we might want to
> start thinking of this plugin as a way to run Rails-type applications
> in a Struts environment, and perhaps come up with a name that
> communicates that goal.

Right, the rails people would complain but even if they wouldn't there
is now way this plugin could be considered on par with Rails.  Rails
is much, much bigger than just a few Rest conventions and even if you
could replicate most of its functionality in Java, you still couldn't
match the benefits Ruby gives you. No, I'm very happy for Rails the
way it is and if you really want it on the JVM, use JRuby or even
Grails for a closer to Java match.

I barely have enough time to write a little plugin that lets you use
Rest conventions in Struts 2, so replicating something as big as Rails
is out of the question for me :)

> Oh, I don't know. Throw in JPA and some Maven archetypes, and you
> could hit the ground running for the common use cases. A key technique
> might be to develop archetypes that we could run for adding new
> pages/actions/entities/tests to existing applications. Between POJO
> Actions and codebehinds, we might be able to do useful CRUD with zero
> lines of Struts framework code.
>
> MyEclipse has some stunning DAO generation and JPA integration
> capabilities. For what we can't do with our plugins, we might be able
> to do with Eclipse plugins.

Heh, it is the cobbled-together Java solutions that drive many people
to Rails in the first place :)  I do think there is value in the
Appfuse approach and would like them to do more to encourage faster,
full-stack development.

In summary, this plugin is not about replicating Rails, but just
applying its Rest design to Struts apps. If folks want to try more,
feel free to start a new plugin based on this plugin, but I'd like to
keep the focus on the key components of Rest.

Don

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fixing theme inheritance

[Ian Roughley]

I have spend some time thinking about this problem - especially when I 
was working on the ajax code - but I can't come up with a good solution 
(or maybe its just I haven't thought about it enough). 

The problem is the bigger picture, and as I see it, is that you may want 
to re-use an entire parent template except for certain sections in the 
middle (say the ajax library-specific calls).  How can this be 
achieved?  The parent templates could look for other templates, or some 
other type of library file, but I think this would mean that a single 
template that is easy(ish) to read, would be split into multiple files 
making extending themes harder as well as understanding them.


/Ian

Ted Husted wrote:

The problem seems to be that we need a volunteer who is eager to work
on this feature. The patch was a start, but only a start, and the
comments indicate that there is still a lot of work to do.

-Ted.

On 10/19/07, Aymeric Levaux <[EMAIL PROTECTED]> wrote:
  

Hi,

At this time there is no way to extend a theme in a good way. See
https://issues.apache.org/struts/browse/WW-1328
It would be great to have this issue fixed for 2.1 as there is already a
patch which looks good and this fix would allow much more possibilities
for plugin development.

--
Aymeric Levaux



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  

Re: [s2] Proposal: Rest Plugin

[Ted Husted]

On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> Heh, it is the cobbled-together Java solutions that drive many people
> to Rails in the first place :)  I do think there is value in the
> Appfuse approach and would like them to do more to encourage faster,
> full-stack development.

I'm not sure that I'd call MyEclipse "cobbled-together" :)

With Java installed, MyEclipse is now a full stack out-of-the box. You
don't actually *need* to download anything else. Period. It's also an
AppFuse-style full-stack, in that you can choose to add and subtract
features like Struts 1, Spring, JPA, Hibernate and so forth.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[s2] Struts 2 to focus on Rest? (was Proposal: Rest Plugin)

[Don Brown]

I guess this is where we differ.  I think we absolutely shouldn't be
creating new conventions because:
 1. The Rails conventions have been used for years and have proven valuable
 2. The Rails conventions match what people think about when they
think of a Restful URL
 3. Conventions are already difficult to learn and remember, so one
set of them is always better than one frequently used set and another
rarely used
 4. Using the same conventions minimizes training
 5. The current URL patterns just aren't a good fit for Rest, so I
don't feel bad throwing them out.
 6. Struts 2 was all about not reinventing the wheel, and here is a
clear case where we can learn from another project

My ultimate goal is that Struts 2 realigns itself as the easiest, yet
most powerful way to write a Restful application, going head to head
with Rails and Restlets in this specific aspect.  I think we have a
tremendous opportunity to capitalize on how well our architecture fits
Rest applications to meet this growing demand and be a leader in the
field.

I can't say it enough - Rest could be _the_ thing Struts 2 is known to
dominate in the Java web framework world, but do make that happen, it
would take a strong, if not unanimous consensus from the Struts
development community. Other frameworks have less configuration
(Wicket), have a better UI component model (JSF, Wicket, Tapestry,
etc), and even other action-based frameworks have a tighter focus and
leaner, yet practical codebase (Stripes), but we could have the
premier Rest platform, which I believe delivers solid, scalable value
to developers.  I know that is where my applications are moving, and
I'd like Struts 2 to be the framework I use to write them.

Don

On 10/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> (From "Plugins gone Wild")
>
> On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > Also, I wouldn't include the rest plugin in core as it places some
> > strict requirements on the format of the url that won't be compatible
> > with most Struts 2 apps.
>
> That's a good point. I went over the Rails conventions for REST, and I
> would agree that they would tend to conflict with other trends in
> Struts development. To further the discussion, I put together some
> notes regarding some REST conventions that would better coincide with
> our own general direction.
>
>  * 
> http://cwiki.apache.org/confluence/display/S2PLUGINS/RESTful+CRUD+for+HTML+methods
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Don Brown]

Fair enough, I guess I was responding more to the little maven 2 here,
little JPA there comment.  I would love to see a truly end-to-end
solution like MyEclipse tie everything together.  Last I checked, they
weren't supporting Struts 2, but perhaps that's changed?

Don

On 10/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > Heh, it is the cobbled-together Java solutions that drive many people
> > to Rails in the first place :)  I do think there is value in the
> > Appfuse approach and would like them to do more to encourage faster,
> > full-stack development.
>
> I'm not sure that I'd call MyEclipse "cobbled-together" :)
>
> With Java installed, MyEclipse is now a full stack out-of-the box. You
> don't actually *need* to download anything else. Period. It's also an
> AppFuse-style full-stack, in that you can choose to add and subtract
> features like Struts 1, Spring, JPA, Hibernate and so forth.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Struts 2 to focus on Rest? (was Proposal: Rest Plugin)

[Ted Husted]

On 10/23/07, Don Brown <[EMAIL PROTECTED]> wrote:
> I guess this is where we differ.  I think we absolutely shouldn't be
> creating new conventions because:
>  1. The Rails conventions have been used for years and have proven valuable

Struts 1 has been used for years, and proven valuable. But that didn't
stop WebWork from improving on the original.


>  2. The Rails conventions match what people think about when they
> think of a Restful URL

Maybe I'm the odd duck, but they don't match the way I think. In fact,
they seem haphazard and arbitrary. I expect they make better sense in
the context of Rails, but we should use conventions that make sense in
the context of Struts. IMHO, if we are linking the operations to CRUD
terms, then we should use CRUD terms and not invent new vocabularies.


>  3. Conventions are already difficult to learn and remember, so one
> set of them is always better than one frequently used set and another
> rarely used

Agreed. The Struts 2 REST conventions should be based on our existing
conventions. We don't call it "edit", we call it "input". Why not call
"Read" read, "Create" create, and "Delete" delete?


>  4. Using the same conventions minimizes training

The documentation for the Rails conventions are bound to Ruby, and
we'd will have to recast it all anyway. There is absolutely savings to
be gained.


>  5. The current URL patterns just aren't a good fit for Rest, so I
> don't feel bad throwing them out.

I just don't see that at all. The patterns described seen like an even
better fit for REST.

 * http://cwiki.apache.org/S2PLUGINS/restful-crud-for-html-methods.html

>  6. Struts 2 was all about not reinventing the wheel, and here is a
> clear case where we can learn from another project

Agreed. But, that doesn't mean we can improve on what the other
project is doing, just as we have continued to improve the WebWork 2
codebase.


> My ultimate goal is that Struts 2 realigns itself as the easiest, yet
> most powerful way to write a Restful application, going head to head
> with Rails and Restlets in this specific aspect.  I think we have a
> tremendous opportunity to capitalize on how well our architecture fits
> Rest applications to meet this growing demand and be a leader in the
> field.

Mine too, but that doesn't mean we should blindly copy arbitrary
conventions that don't fit well with existing Struts design patterns,
without even considering alternatives.


> I can't say it enough - Rest could be _the_ thing Struts 2 is known to
> dominate in the Java web framework world, but do make that happen, it
> would take a strong, if not unanimous consensus from the Struts
> development community. Other frameworks have less configuration
> (Wicket), have a better UI component model (JSF, Wicket, Tapestry,
> etc), and even other action-based frameworks have a tighter focus and
> leaner, yet practical codebase (Stripes), but we could have the
> premier Rest platform, which I believe delivers solid, scalable value
> to developers.  I know that is where my applications are moving, and
> I'd like Struts 2 to be the framework I use to write them.

Agreed. But, again, RESTful resources and the Ruby conventions for
REST are not synonyms. I admire Ruby, but I don't suffer from API
envy.

If we want strong, unanimous consent from the Struts2 community, then
we should focus on developing conventions that Struts2 developers will
find intuitive, and will also serve the purpose of RESTful resources.

Though, I'm not sure if we are talking about RESTful resources as much
as we are talking about automatic, heuristic mappings. Some web
services can be truly RESTful when talking to the right server, but
true REST isn't even achievable in a general web application
framework. REST has some technical benefits in caching and such, but,
in and of itself, it's not the holy grail. IMHO, it's the notion of
automatic, heuristic mappings that make the real difference in web
development.

Anyway, talk is cheap. I'm more than willing to try a Ruby-RESTFul
MailReader and then try another using the Struts2-like conventions,
and then compare the results.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Piero Sartini]

Am Dienstag, 23. Oktober 2007 15:18:01 schrieb Ted Husted:
> With Java installed, MyEclipse is now a full stack out-of-the box. You
> don't actually *need* to download anything else. Period. It's also an
> AppFuse-style full-stack, in that you can choose to add and subtract
> features like Struts 1, Spring, JPA, Hibernate and so forth.

This sounds much like NetBeans ;-)

Piero

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Ted Husted]

On 10/23/07, Piero Sartini <[EMAIL PROTECTED]> wrote:
> This sounds much like NetBeans ;-)

Quite possibily. It's been awhile since I looked at NetBeans. Of
course, an advantage there is that you can also get Java in the same
download :)

I've been doing conducting a series of training classes for a client
that is using MyEclipse, and so that's what I've been using lately.

Does NetBeans bundle a database now? Along with Spring 2, Hibernate 3,
and Struts 1 (not to mention Tapestry), MyEclipse 6 also includes
Tomcat and Derby, so it is, in fact, an end- to-end, full-stack
solution.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.1.0 Build/Release Plan

[Ted Husted]

Argh!

I'm getting test-build errors on the HEAD. I don't know if these are
the same we were having before, or a new issue. I double my heap
setting to 2048, but no joy. So, it's probably looping.

---

[#attr.templateDir]
2007-10-23 10:13:37,090 WARN  [CommonsLogger.java:46] : Could not find property
[#attr.templateDir]
Tests run: 5, Failures: 2, Errors: 0, Skipped: 3, Time elapsed: 32.296 sec <<< F
AILURE!
Running org.apache.struts2.dispatcher.StreamResultTest
Tests run: 12, Failures: 1, Errors: 0, Skipped: 11, Time elapsed: 21.157 sec <<<
 FAILURE!
Running org.apache.struts2.views.jsp.ui.LabelTest
org.apache.maven.surefire.booter.SurefireExecutionException: Java heap space; ne
sted exception is java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 58 seconds
[INFO] Finished at: Tue Oct 23 10:14:49 EDT 2007
[INFO] Final Memory: 26M/47M
[INFO] 

---

I'm on my way to Boston for the AE today. I don't think I'll be able
to look into this myself, but someone else does, I should be able to
roll it on my laptop there.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [s2] Proposal: Rest Plugin

[Piero Sartini]

Am Dienstag, 23. Oktober 2007 16:02:01 schrieb Ted Husted:
> Does NetBeans bundle a database now? Along with Spring 2, Hibernate 3,
> and Struts 1 (not to mention Tapestry), MyEclipse 6 also includes
> Tomcat and Derby, so it is, in fact, an end- to-end, full-stack
> solution.

If you choose to install the Web&JavaEE part there is Tomcat 6 and Glassfish 
V2 bundled. JavaDB (Apache Derby) is used as a database. You may add Struts1, 
JSF or Visual Web Toolkit to your project (There are plugins for GWT and 
others in the plugin manager).

Together with Mobility Toolkit, UML, (J)Ruby and Rails and real good Maven2 
integration I would consider it an full end-to-end solution as well :-)
But I never looked at MyEclipse, so I cannot say much about the differences.

For a quick overview of the features of nb6 you may look at:
http://download.netbeans.org/netbeans/6.0/beta2/

Piero

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.1.0 Build/Release Plan

[James Mitchell]

I've got a little bit of time today, I'll take a look at it.


--
James Mitchell



On Oct 23, 2007, at 10:18 AM, Ted Husted wrote:


Argh!

I'm getting test-build errors on the HEAD. I don't know if these are
the same we were having before, or a new issue. I double my heap
setting to 2048, but no joy. So, it's probably looping.

---

[#attr.templateDir]
2007-10-23 10:13:37,090 WARN  [CommonsLogger.java:46] : Could not  
find property

[#attr.templateDir]
Tests run: 5, Failures: 2, Errors: 0, Skipped: 3, Time elapsed:  
32.296 sec <<< F

AILURE!
Running org.apache.struts2.dispatcher.StreamResultTest
Tests run: 12, Failures: 1, Errors: 0, Skipped: 11, Time elapsed:  
21.157 sec <<<

 FAILURE!
Running org.apache.struts2.views.jsp.ui.LabelTest
org.apache.maven.surefire.booter.SurefireExecutionException: Java  
heap space; ne

sted exception is java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
[INFO]  
-- 
--

[ERROR] BUILD FAILURE
[INFO]  
-- 
--

[INFO] There are test failures.
[INFO]  
-- 
--

[INFO] For more information, run Maven with the -e switch
[INFO]  
-- 
--

[INFO] Total time: 2 minutes 58 seconds
[INFO] Finished at: Tue Oct 23 10:14:49 EDT 2007
[INFO] Final Memory: 26M/47M
[INFO]  
-- 
--


---

I'm on my way to Boston for the AE today. I don't think I'll be able
to look into this myself, but someone else does, I should be able to
roll it on my laptop there.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Brian Pontarelli]

Ted Husted wrote:

On 10/22/07, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
  

True, but I was talking about APT, and in that case it's not really
making anything easier as far as I can tell... APT is already pretty
close to plug-and-play as you know... aside from making the config file
name a default, which would benefit both the plugin and APT outside of
S2, can you see any way to make it more useful as a plugin?



Dojo is plug-and-play too, but the Dojo plugin is powering Struts tags
behind the scenes.

 *  http://struts.apache.org/2.x/docs/ajax-tags.html
 *  http://struts.apache.org/2.x/docs/ajax-and-javascript-recipes.html
  
However, this is simple to switch out by tweaking the FreeMarker 
templates. Really it is the stock templates that are using Dojo and not 
Struts tags per se.


-bp

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Chris Pratt]

> My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> setter.  It might make more sense for this feature/annotation to be part
> of the annotations plugin.  Does anyone else see this as a useful
> feautre?  I'd rather annotate what I want to permit to be set than
> exclude my DAO/Services (which are required by the Spring plugin).

Actually, I'd turn it around a bit.  I'd rather annotate when
something should be hidden from Struts then to have to add an
annotation to every mutator in the system.

And, I'm actually don't know so this is a question, not a criticism,
but would checking those annotations on every field access slow down
the system?
  (*Chris*)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: 2.1.0 Build/Release Plan

[James Mitchell]

Hmmm ... it worked fine for me.

What errors are you getting?


I just did:

[EMAIL PROTECTED] ~/svn/STRUTS_2_0_X]$ mvn clean install -Pall

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Struts 2
[INFO]   Struts 2 Core
[INFO]   Struts Plugins
[INFO]   Struts 2 Codebehind Plugin
[INFO]   Struts 2 Configuration Browser Plugin
[INFO]   Struts 2 Jasper Reports Plugin
[INFO]   Struts 2 JFreeChart Plugin
[INFO]   Struts 2 JSF Plugin
[INFO]   Struts 2 Pell Multipart Plugin
[INFO]   Struts 2 Plexus Plugin
[INFO]   Struts 2 Sitegraph Plugin
[INFO]   Struts 2 Sitemesh Plugin
[INFO]   Struts 2 Spring Plugin
[INFO]   Struts 2 Struts 1 Plugin
[INFO]   Struts 2 Tiles Plugin
[INFO]   Webapps
[INFO]   Blank Webapp
[INFO]   Starter Webapp
[INFO]   Portlet Webapp
[INFO]   Showcase Webapp
[INFO]  
 


[INFO] Building Struts 2
[INFO]task-segment: [clean, install]
[INFO]  
 


[INFO] [clean:clean]
[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/target
[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/target/ 
classes
[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/target/ 
test-classes

[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/target/site
[INFO] [site:attach-descriptor]
[WARNING] Unable to load parent project from repository: Could not  
find the model file '/Users/jmitchell/svn/STRUTS_2_0_X/../pom.xml'.

[INFO] [install:install]
[INFO] Installing /Users/jmitchell/svn/STRUTS_2_0_X/pom.xml to /Users/ 
jmitchell/.m2/repository/org/apache/struts/struts2-parent/2.0.12- 
SNAPSHOT/struts2-parent-2.0.12-SNAPSHOT.pom
[INFO]  
 


[INFO] Building Struts 2 Core
[INFO]task-segment: [clean, install]
[INFO]  
 


[INFO] [clean:clean]
[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/core/target
[INFO] Deleting directory /Users/jmitchell/svn/STRUTS_2_0_X/core/ 
target/classes

...
...



...
...
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Assembling webapp struts2-showcase in /Users/jmitchell/svn/ 
STRUTS_2_0_X/apps/showcase/target/struts2-showcase
[INFO] Copy webapp webResources to /Users/jmitchell/svn/STRUTS_2_0_X/ 
apps/showcase/target/struts2-showcase
[INFO] Generating war /Users/jmitchell/svn/STRUTS_2_0_X/apps/showcase/ 
target/struts2-showcase.war
[INFO] Building war: /Users/jmitchell/svn/STRUTS_2_0_X/apps/showcase/ 
target/struts2-showcase.war

[INFO] [install:install]
[INFO] Installing /Users/jmitchell/svn/STRUTS_2_0_X/apps/showcase/ 
target/struts2-showcase.war to /Users/jmitchell/.m2/repository/org/ 
apache/struts/struts2-showcase/2.0.12-SNAPSHOT/struts2- 
showcase-2.0.12-SNAPSHOT.war

[INFO]
[INFO]
[INFO]  


[INFO] Reactor Summary:
[INFO]  

[INFO] Struts 2 ..  
SUCCESS [1.919s]
[INFO] Struts 2 Core .  
SUCCESS [2:00.786s]
[INFO] Struts Plugins   
SUCCESS [0.205s]
[INFO] Struts 2 Codebehind Plugin   
SUCCESS [2.152s]
[INFO] Struts 2 Configuration Browser Plugin .  
SUCCESS [0.802s]
[INFO] Struts 2 Jasper Reports Plugin   
SUCCESS [20.427s]
[INFO] Struts 2 JFreeChart Plugin   
SUCCESS [2.878s]
[INFO] Struts 2 JSF Plugin ...  
SUCCESS [0.873s]
[INFO] Struts 2 Pell Multipart Plugin   
SUCCESS [0.789s]
[INFO] Struts 2 Plexus Plugin   
SUCCESS [0.452s]
[INFO] Struts 2 Sitegraph Plugin .  
SUCCESS [2.944s]
[INFO] Struts 2 Sitemesh Plugin ..  
SUCCESS [0.524s]
[INFO] Struts 2 Spring Plugin   
SUCCESS [2.543s]
[INFO] Struts 2 Struts 1 Plugin ..  
SUCCESS [1.963s]
[INFO] Struts 2 Tiles Plugin .  
SUCCESS [0.744s]
[INFO] Webapps ...  
SUCCESS [0.720s]
[INFO] Blank Webapp ..  
SUCCESS [4.200s]
[INFO] Starter Webapp   
SUCCESS [2.381s]
[INFO] Portlet Webapp   
SUCCESS [2.752s]
[INFO] Showcase Webapp ...  
SUCCESS [10.384s]
[INFO]  

[INFO]  

Re: [S2] Plugins gone wild!

[Martin Gilday]

I think I would agree actually.  I'm not sure about the performance
implications.  I had only planned on preventing the parameters
interceptor setting to them, so it wouldn't be on every field access.


- Original message -
From: "Chris Pratt" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Date: Tue, 23 Oct 2007 09:06:07 -0700
Subject: Re: [S2] Plugins gone wild!

> My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the
> setter.  It might make more sense for this feature/annotation to be part
> of the annotations plugin.  Does anyone else see this as a useful
> feautre?  I'd rather annotate what I want to permit to be set than
> exclude my DAO/Services (which are required by the Spring plugin).

Actually, I'd turn it around a bit.  I'd rather annotate when
something should be hidden from Struts then to have to add an
annotation to every mutator in the system.

And, I'm actually don't know so this is a question, not a criticism,
but would checking those annotations on every field access slow down
the system?
  (*Chris*)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Brian Pontarelli]

This sounds more of a security level concern and is currently handled by 
ACEGI and I would assume other projects as well. Or am I missing something?


-bp


Martin Gilday wrote:

Where abouts is the annotations plugin housed?  I could not see it in
the struts2 trunk or sandbox trunk.  Following Don's comment in this
https://issues.apache.org/struts/browse/WW-2264 I was interested in
trying to created this feature "A new feature we could add would be a
new annotation so that a user could annotate which setters/getters can
be accessed, which is probably a good idea regardless.".  My initial
idea was another flag on the parameter interceptor which, when enabled,
would only set against the action when an annotation is present on the
setter.  It might make more sense for this feature/annotation to be part
of the annotations plugin.  Does anyone else see this as a useful
feautre?  I'd rather annotate what I want to permit to be set than
exclude my DAO/Services (which are required by the Spring plugin).


- Original message -
From: "Ted Husted" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Date: Tue, 23 Oct 2007 06:20:13 -0400
Subject: Re: [S2] Plugins gone wild!

So, to follow-up, the amended struts-core-plugins.jar list seems to be

  * annotations plugin (new)
  * codebehind plugin (including zero-config)
  * tags plugin (new)

I'd like to keep codebehind in the core, since I believe we are on
track for making XML-action-free Struts apps the recommended approach.

Though, when we say that, I don't think we need to excise the
struts.xml and go back to using struts.properties. Using the
struts.xml to set one-time global configuration parameters is very
different from using the struts.xml to describe all of the
application's actions.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Matt Raible]

I'm more than happy to provide these archetypes as part of AppFuse
Light (or putting them under the Struts umbrella). I plan on adding
support for Struts 2 + JSF Plugin in the near future.

Currently, I'm waiting for Maven to release their ArchetypeNG plugin
that allows you to create archetypes from projects.

Matt

On 10/23/07, Ted Husted <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Don Brown <[EMAIL PROTECTED]> wrote:
> > It might be interesting to have several "bundles":
> >  * Core - codebehind, dojo
> >  * Starter - codebehind, dojo, spring, jpa
> >  * Rest - codebehind, rest, dojo
>
> This might be a great role for AppFuse-style Maven prototypes!
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
http://raibledesigns.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2] Plugins gone wild!

[Martin Gilday]

Well I am looking at the Parameter Filter Interceptor
(http://cwiki.apache.org/WW/parameter-filter-interceptor.html) which I
am proposing we complement by allowing the same thing with annotations. 
Currently we have a wizard like section in one of our sites which we are
backing with Spring session scope beans.  So the Struts2 Spring plugin
injects it.  To allow this we have a setMySessionBeanName(), which is
public.  So a user could call an action with a parameter
mySessionBeanName.forename and change that value.  You can stop that
with the filter interceptor by defining mySessionBeanName as a blocked
parameter name,  I would prefer to mark it @NotAParameter.

We use Acegi to block Actions on a role basis.  I know you can also
block method invocations on POJO, but have never gone that far.  Could
Acegi help with the use case above?

Thanks,
Martin.


- Original message -
From: "Brian Pontarelli" <[EMAIL PROTECTED]>
To: "Struts Developers List" 
Date: Tue, 23 Oct 2007 13:13:24 -0600
Subject: Re: [S2] Plugins gone wild!

This sounds more of a security level concern and is currently handled by 
ACEGI and I would assume other projects as well. Or am I missing
something?

-bp


Martin Gilday wrote:
> Where abouts is the annotations plugin housed?  I could not see it in
> the struts2 trunk or sandbox trunk.  Following Don's comment in this
> https://issues.apache.org/struts/browse/WW-2264 I was interested in
> trying to created this feature "A new feature we could add would be a
> new annotation so that a user could annotate which setters/getters can
> be accessed, which is probably a good idea regardless.".  My initial
> idea was another flag on the parameter interceptor which, when enabled,
> would only set against the action when an annotation is present on the 
> setter.  It might make more sense for this feature/annotation to be part
> of the annotations plugin.  Does anyone else see this as a useful
> feautre?  I'd rather annotate what I want to permit to be set than
> exclude my DAO/Services (which are required by the Spring plugin).
>
>
> - Original message -
> From: "Ted Husted" <[EMAIL PROTECTED]>
> To: "Struts Developers List" 
> Date: Tue, 23 Oct 2007 06:20:13 -0400
> Subject: Re: [S2] Plugins gone wild!
>
> So, to follow-up, the amended struts-core-plugins.jar list seems to be
>
>   * annotations plugin (new)
>   * codebehind plugin (including zero-config)
>   * tags plugin (new)
>
> I'd like to keep codebehind in the core, since I believe we are on
> track for making XML-action-free Struts apps the recommended approach.
>
> Though, when we say that, I don't think we need to excise the
> struts.xml and go back to using struts.properties. Using the
> struts.xml to set one-time global configuration parameters is very
> different from using the struts.xml to describe all of the
> application's actions.
>
> -Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>   


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]