>
> > 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 <joh...@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 <rgie...@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-unsubscr...@struts.apache.org
> > > > For additional commands, e-mail: dev-h...@struts.apache.org
> > > >
> > > >
> > >
>
>
