You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Rene Gielen <rg...@apache.org> on 2013/09/18 10:35:27 UTC
Convention plugin and archetypes
Hi folks,
one of the key facts that people don't get about Struts 2 is that XML is
not needed for configuration. While I think that the Convention plugin
needs to be moved (and be the default) for Struts NEXT, we could do
something now to help our users.
My suggestion is to rearrange the maven archetypes, such that blank is
convention driven by default. Convention archetype could be dropped in
favor for a struts2-xml-config-archetype.
wdyt?
--
René Gielen
http://twitter.com/rgielen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Convention plugin and archetypes
Posted by Lukasz Lenart <lu...@apache.org>.
Maybe instead merging the Convention Plugin into Struts2 Core we
should extract XML based configuration into separated plugin? And then
basic configuration will be just via code - thus allow users to chose
what they want and even implement their own configuration mechanism
(DB based?)
There is one problem with that - XML configuration mechanism is
embedded into XWork, so the only way is to move it to Struts and XWork
will just provide configuration via code.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Convention plugin and archetypes
Posted by Ken McWilliams <ke...@gmail.com>.
>
> > There are a few interesting angles to explore from a database managed
> > configuration. Entities such as Interceptors, Interceptor Stacks,
> Actions,
> > etc. being associated means certain configuration aspects can be reduced
> > (an action and a package have a relation it would be a simple matter to
> > create another relation between that action and another package). It may
> be
> > possible to apply interesting run time manipulation to the struts2
> > configuration.
> MG>dirt simple configurationstruts> <package name="example"
> namespace="/example" extends="struts-default"> <action name="Login_*"
> method="{1}" class="example.Login">
> <result name="input">/example/Login.jsp</result>
> <result type="redirectAction">Menu</result>
> </action> </package>
> </struts>
> MG>MG>package namespace example with assigned namespace (relative URL) of
> /example contains
> MG>Action Name of Login_* with java implementor of example.Login contains
> these results:
> MG>input (redirect to /example/Login.jsp)
> MG>redirectAction (redirects to action defined as 'Menu'
> MG>How could an action such as action="Login_*" point to 'another package'
> (and thus another declared namespace)?
>
It will be easier to explain once I make it work =p
To answer how can the example action be in two namespaces at once: Actions
are defined in table "action" and packages are defined in table "package"
and the two are related via the join table "package_action". Should you
have a package called "example2" then to add action "Login_*" is as simple
as adding another entry to "package_action". You decide when writing the
xml if it is appropriate or not to have action X in package Y. This is no
different.
Using JPA we'll define an "after persist" callback to notify that there has
been a configuration change so the configuration can reload. The entire
configuration should be loaded into memory, as configuration is a read
often write seldom kind of thing.
And of course after experimenting, we could write the configuration back
out to XML.
> > But to address the thread, anything that supports alternate configuration
> > methods is good!MG>Agreed!
> MG>ActionPointingToMultiplePackages created thru an archetype would be a
> big help but who/what would handle these relationships?
>
>
The new configuration provider will expose it's service layer and entity
model. Plugins needing dynamic configuration manipulation could use this as
a dependency.
What I imagine is being able to program struts2 using the browser. Drag and
drop configuration of interceptor stacks, defining and aggregating actions,
and something that would be _really_ nice: Being able to construct a test
HTTP request and see how it gets routed. This would be a perfect solution
to the config browser issue of being able to determine the result path
through to result (even past regular result and wild card matching).
An example of a further plugin (getting way ahead of myself) would be a
Groovy_dynamic_action plugin, which would store it's action definitions
also in the DB.
Something that I'd love to see to is a similar tool to define Apache Tiles
configurations at run time (was playing with that too). Tiles too is a
little trick for people to understand (it _is_ really simple) but if you
could construct tiles definitions with a web UI I bet it could increase
acceptance.
Put it all together and you've got a primitive but interesting web
development platform that I'd expect would make it very easy to construct
very easy applications. The whole JEE thing I think is a little heavy for
non professional programmers. If struts2 were more accessible to the more
hobbyist crowd that would be nice.
Anyways it would create an interesting toy!
>
> > On Wed, Sep 18, 2013 at 4:12 AM, Johannes Geppert <jo...@gmail.com>
> wrote:
> >
> > > In general I like that Idea! The Question is, it is not better to
> leave the
> > > Convention Plugin as an Plugin
> > > and change all archetypes and example/blank apps to use it. So we are
> much
> > > more flexible in the future.
> > > May in some years we have an even better way to configure actions and
> we
> > > can simple add a new plugin
> > > without conflicts or support problems.
> > >
> > > But anyway +1 for rearrange all archetypes and example apps.
> > >
> > > Johannes
> > >
> > >
> > >
> > > #################################################
> > > web: http://www.jgeppert.com
> > > twitter: http://twitter.com/jogep
> > >
> > >
> > > 2013/9/18 Rene Gielen <rg...@apache.org>
> > >
> > > > Hi folks,
> > > >
> > > > one of the key facts that people don't get about Struts 2 is that
> XML is
> > > > not needed for configuration. While I think that the Convention
> plugin
> > > > needs to be moved (and be the default) for Struts NEXT, we could do
> > > > something now to help our users.
> > > >
> > > > My suggestion is to rearrange the maven archetypes, such that blank
> is
> > > > convention driven by default. Convention archetype could be dropped
> in
> > > > favor for a struts2-xml-config-archetype.
> > > >
> > > > wdyt?
> > > >
> > > > --
> > > > René Gielen
> > > > http://twitter.com/rgielen
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
> > > >
> > >
>
>
RE: Convention plugin and archetypes
Posted by Martin Gainty <mg...@hotmail.com>.
> Date: Wed, 18 Sep 2013 22:28:57 -0600
> Subject: Re: Convention plugin and archetypes
> From: ken.mcwilliams@gmail.com
> To: dev@struts.apache.org
>
> Conventions out of the box is very important to improve struts2 user
> experience. I don't know if there have been changes to the config browser
> plugin and/or the strut2-conventions plugin but the two didn't used to play
> nice together to the point I just gave up on config-browser. I think this
> is because conventions uses unknown result handler... so the information
> isn't in the configuration and thus config browser can't get what it needs.
> I think there were some other issues with conventions that would prevent
> accurate reporting of what action would be executed.
>
> On the note of a "better way to configure action" I was experimenting with
> the idea of a relational configuration. The idea was to allow for the
> editing of struts2 configuration at run time though a web interface. It
> will be a while before I can get back to it but I envisioned it as an
> excellent way to learn about struts2 configuration. You could manipulate an
> interceptor stack, reorder the interceptors and then "drop in" a test
> request and see what happens. If it could act as a tool to play with and
> see the effects of configuration changes that would be pretty nice.
>
> There are a few interesting angles to explore from a database managed
> configuration. Entities such as Interceptors, Interceptor Stacks, Actions,
> etc. being associated means certain configuration aspects can be reduced
> (an action and a package have a relation it would be a simple matter to
> create another relation between that action and another package). It may be
> possible to apply interesting run time manipulation to the struts2
> configuration.
MG>dirt simple configurationstruts> <package name="example" namespace="/example" extends="struts-default"> <action name="Login_*" method="{1}" class="example.Login">
<result name="input">/example/Login.jsp</result>
<result type="redirectAction">Menu</result>
</action> </package>
</struts>
MG>MG>package namespace example with assigned namespace (relative URL) of /example contains MG>Action Name of Login_* with java implementor of example.Login contains these results:MG>input (redirect to /example/Login.jsp)
MG>redirectAction (redirects to action defined as 'Menu'
MG>
MG>How could an action such as action="Login_*" point to 'another package' (and thus another declared namespace)?
>
> But to address the thread, anything that supports alternate configuration
> methods is good!MG>Agreed!
MG>ActionPointingToMultiplePackages created thru an archetype would be a big help but who/what would handle these relationships?
>
>
>
>
> On Wed, Sep 18, 2013 at 4:12 AM, Johannes Geppert <jo...@gmail.com> wrote:
>
> > In general I like that Idea! The Question is, it is not better to leave the
> > Convention Plugin as an Plugin
> > and change all archetypes and example/blank apps to use it. So we are much
> > more flexible in the future.
> > May in some years we have an even better way to configure actions and we
> > can simple add a new plugin
> > without conflicts or support problems.
> >
> > But anyway +1 for rearrange all archetypes and example apps.
> >
> > Johannes
> >
> >
> >
> > #################################################
> > web: http://www.jgeppert.com
> > twitter: http://twitter.com/jogep
> >
> >
> > 2013/9/18 Rene Gielen <rg...@apache.org>
> >
> > > Hi folks,
> > >
> > > one of the key facts that people don't get about Struts 2 is that XML is
> > > not needed for configuration. While I think that the Convention plugin
> > > needs to be moved (and be the default) for Struts NEXT, we could do
> > > something now to help our users.
> > >
> > > My suggestion is to rearrange the maven archetypes, such that blank is
> > > convention driven by default. Convention archetype could be dropped in
> > > favor for a struts2-xml-config-archetype.
> > >
> > > wdyt?
> > >
> > > --
> > > René Gielen
> > > http://twitter.com/rgielen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
Re: Convention plugin and archetypes
Posted by Ken McWilliams <ke...@gmail.com>.
Conventions out of the box is very important to improve struts2 user
experience. I don't know if there have been changes to the config browser
plugin and/or the strut2-conventions plugin but the two didn't used to play
nice together to the point I just gave up on config-browser. I think this
is because conventions uses unknown result handler... so the information
isn't in the configuration and thus config browser can't get what it needs.
I think there were some other issues with conventions that would prevent
accurate reporting of what action would be executed.
On the note of a "better way to configure action" I was experimenting with
the idea of a relational configuration. The idea was to allow for the
editing of struts2 configuration at run time though a web interface. It
will be a while before I can get back to it but I envisioned it as an
excellent way to learn about struts2 configuration. You could manipulate an
interceptor stack, reorder the interceptors and then "drop in" a test
request and see what happens. If it could act as a tool to play with and
see the effects of configuration changes that would be pretty nice.
There are a few interesting angles to explore from a database managed
configuration. Entities such as Interceptors, Interceptor Stacks, Actions,
etc. being associated means certain configuration aspects can be reduced
(an action and a package have a relation it would be a simple matter to
create another relation between that action and another package). It may be
possible to apply interesting run time manipulation to the struts2
configuration.
But to address the thread, anything that supports alternate configuration
methods is good!
On Wed, Sep 18, 2013 at 4:12 AM, Johannes Geppert <jo...@gmail.com> wrote:
> In general I like that Idea! The Question is, it is not better to leave the
> Convention Plugin as an Plugin
> and change all archetypes and example/blank apps to use it. So we are much
> more flexible in the future.
> May in some years we have an even better way to configure actions and we
> can simple add a new plugin
> without conflicts or support problems.
>
> But anyway +1 for rearrange all archetypes and example apps.
>
> Johannes
>
>
>
> #################################################
> web: http://www.jgeppert.com
> twitter: http://twitter.com/jogep
>
>
> 2013/9/18 Rene Gielen <rg...@apache.org>
>
> > Hi folks,
> >
> > one of the key facts that people don't get about Struts 2 is that XML is
> > not needed for configuration. While I think that the Convention plugin
> > needs to be moved (and be the default) for Struts NEXT, we could do
> > something now to help our users.
> >
> > My suggestion is to rearrange the maven archetypes, such that blank is
> > convention driven by default. Convention archetype could be dropped in
> > favor for a struts2-xml-config-archetype.
> >
> > wdyt?
> >
> > --
> > René Gielen
> > http://twitter.com/rgielen
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
Re: Convention plugin and archetypes
Posted by Johannes Geppert <jo...@gmail.com>.
In general I like that Idea! The Question is, it is not better to leave the
Convention Plugin as an Plugin
and change all archetypes and example/blank apps to use it. So we are much
more flexible in the future.
May in some years we have an even better way to configure actions and we
can simple add a new plugin
without conflicts or support problems.
But anyway +1 for rearrange all archetypes and example apps.
Johannes
#################################################
web: http://www.jgeppert.com
twitter: http://twitter.com/jogep
2013/9/18 Rene Gielen <rg...@apache.org>
> Hi folks,
>
> one of the key facts that people don't get about Struts 2 is that XML is
> not needed for configuration. While I think that the Convention plugin
> needs to be moved (and be the default) for Struts NEXT, we could do
> something now to help our users.
>
> My suggestion is to rearrange the maven archetypes, such that blank is
> convention driven by default. Convention archetype could be dropped in
> favor for a struts2-xml-config-archetype.
>
> wdyt?
>
> --
> René Gielen
> http://twitter.com/rgielen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>