Things are going pretty good on this front. I've implemented the unknown
handler and it is handling requests thus far. I had to put in a hack in
order to get the unknown handler to support the old zero-config type of
ActionConfig creation. This is currently my largest stumbling block and
I'm going to start a new development thread to discuss it.
Other than that I have a number of new annotations and interfaces:
Annotations
--------------------
*ActionNames* - Array holder
*ActionName* - For handling non-standard action naming or different
methods or multiple actions per class
*Results* - Array holder
*Result* - Same as the Struts2 except the type is a string and it
handles multiple actions per class
*BaseResultLocation *- Used to change the root (prefix) within the web
application that contains the results for a specific action.
Interfaces
-----------------
*ActionConfigBuilder* - for building the ActionConfigs and adding them
to the XWork configuration
*ActionNameBuilder *- for handling different default naming based on the
class name (for SEO underscores and such)
*ResultMapBuilder *- for creating/finding the correct results for an
action based on resources in the web application and/or the annotations
I'm building out the tests for all this right now and should be done
today I'm hoping. I might be adding some other annotations and
interfaces as I go, we'll see.
-bp
Don Brown wrote:
Sounds great, keep us posted.
Don
On 4/26/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
After some thought, I'm actually going to try and write an
UnknownHandler that will do all of this for me instead of the
modifications to Struts itself. I should be able to handle everything
that codebehind and zero-config do with my additional annotations and
some other enhancements for handling "components" without diving into
Tapestry or GWT or the like...
If anyone has reasons to believe that this won't work, just let me know.
Otherwise, I'll hopefully get this running and then can submit it as a
plugin.
-bp
Brian Pontarelli wrote:
> I just got done writing an enhancement to the zero-configuration code.
> It provides a number of new features:
>
> - Support for action name mapping so that you can transform from
> SomeNamedAction to someNamed.action or some_named.action. This uses an
> interface so it can be extended however is required. I made two
> implementations, the first uses the existing code to lowercase and
> remove the action ending, the second is an SEO friendly implementation
> that handles camel case and adds in underscores.
>
> - Added the ActionName and ActionNames annotations for the action
> classes. These two annotations allow actions to provide non-default
> names as well as methods to invoke. You can also supply an array of
> ActionName annotations to allow a single action to handle multiple
> actions.
>
> I did not add support to the result annotation to allow for results to
> be associated with specific actions, but that should be trivial. This
> stuff makes SEO handling pretty easy and also allows for modifications
> to the zero-configuration URL handling via annotations in the same
> manner that results can be modified via annotations. I'll be using
> this stuff here locally, but I think it would be pretty beneficial to
> the community and would like to discuss putting it back into core.
>
> I can put together a patch file if anyone wants to look over the
> modifications.
>
> -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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
