I could go either way. I would be happy to support both methods for
this, either in core or as a separate plugin via Google-Code.
Right now, I've called it smarturls-s2 and it is up in a Google-Code
SubVersion repository. The tests are working so they can give you some
sense of how it all works. Feel free to take a look at the code and let
me know if you want to move it into core or leave it where it is at. If
it stays over at Google, I'll add to the project anyone from the main
Struts2 contributor list that wants access.
One other thing is that for the component support I built in, I used
JAXB2 from JDK 1.6 for parsing and converting the component.xml files
into JavaBeans. If we move it back into core we'll need to change that
over to SAX or some other method of loading in the XML.
All that said, I'm also leaning towards moving it back into core and
fixing up some of the configuration tricks that it currently requires so
that it is part of the Struts2 initialization process rather than a
custom ConfigurationProvider that requires web.xml to have init
parameters for the FilterDispatcher in order to setup a custom
configuration provider.
-bp
Don Brown wrote:
This looks great Brian! Is the code anywhere we could take a look?
Do you
think it would be better to have this as a plugin or part of the
core? I'm
leaning towards putting in 2.1.x core, but would like to hear your
thoughts.
Don
On 5/3/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
I've finished the first pass at a plugin that collapses the zero-config
and code-behind as well as adds support for components that have actions
in other JAR files. Here are the highlights:
- Uses action packages to locate actions
- Pre-loads all the results it can find via the ServletContext and
Result(s) annotations. Before the unknown handler handled all the
results for zero-config that weren't in the annotations. I changed it so
that my configuration provider pre-loads results it can find using
servletContext.getResourcePaths(String). I also added support for
relative path handling for certain result types so that the Result
annotation doesn't have to point to a full path. When it finds a JSP or
other file in the web application that looks like a result it will
create a result for it. In addition, rather than only handling
<actionName>-<resultCode>.ext format, it will also creat results for
<actionName>.ext using the resultCodes input, error and success. This
will be the most common handling and this can easily be modified using
the annotations.
- Added support for ActionName(s) annotations that can allow a class to
have a different action name and/or multiple actions. It also supports
invoking different methods for different actions.
- Added a configurable interface for converting from the class name to
an action name. The default is an SEO friendly mechanism that converts
FooBarAction to foo_bar. This interface can be implemented and injected
into the configuration process to change action names by default.
Otherwise every action class will need ActionName(s) annotation(s).
- Added support for moving the base result location. This is the path
where the results are looked for. An action can have a different base
result location than other actions using the BaseResultLocation
annotation. Furthermore, the entire app can control this in the same
manner as the code-behind plugin did.
- Namespaces and parent packages are handled as they were before.
- Add component handling via an XML file anywhere in the classpath
called component.xml. This file defines the action packages for a
component and can also move the base result location for the component
as well as control the prefix of the namespace for each action package.
The configuration looks like this:
<?xml version="1.0"?>
<component>
<action_package>com.example.component.test</action_package>
<action_package
namespace_prefix="/test2">com.example.component.test2</action_package>
<base_result_location>/WEB-INF/component</base_result_location>
<parent_package>foo-bar</parent_package>
</component>
Actions and results are resolved the same for components as for the
application except with the base result location, parent package and
namespace_prefix tweaks.
- Everything is interfaced out so it can be extended, refactored or
replaced pretty easily. The entire configuration process is handled via
interfaces and injection, so nothing is hard-coded.
That's what I have thus far. It is working fine and the component
framework is working well. Everything thus far is pretty well unit
tested as well. Here's what I have left to complete:
- Add support for component unknown actions and results. This is
required because components can move the base result location, which
means that I need to figure out a way to infer that an action is in a
namespace of a component probably by walking over all the actions in all
packages to ensure that the component has an action in that same
namespace.
If folks have comments or thoughts let me know.
-bp
---------------------------------------------------------------------
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]
