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 <[email protected]> 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 <[email protected]>
>
> > 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>

Reply via email to