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]
