struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Sutton <al.sut...@alsutton.com>
Subject Re: REST Showcase 2.1.2
Date Tue, 02 Sep 2008 05:58:17 GMT
Scott,

Annotations serve a very useful purpose, and unless you're using a JRE 
less than version 5 they're worth the effort.

I didn't think they were worth it until I had an opportunity to write a 
Struts2/Hibernate app from scratch and saw how it moved a lot of the 
config from a dis-associated file into the relevant section of the code.

Al.

P.S. As for your sister... well if it's some you want to do I won't hold 
you making a choice between the two.


Wes Wannemacher wrote:
> What's wrong with annotations, and more importantly - 
>
> How hot is your sister?!
>
> (sorry, couldn't resist)
>
> -Wes
>
> On Mon, 2008-09-01 at 08:57 -0500, stanlick@gmail.com wrote:
>   
>> Thanks Jeromy --
>>
>> I'd rather sleep with my sister than embed annotations in my code.  This
>> notwithstanding, I understand your reluctance to add yet another permutation
>> to that lookup scheme.  I poked around in the code back in 2.0 and nearly
>> got a nose bleed.  I hope there are a ton of unit tests around that baby!
>> I'm getting the feeling that REST is not ready for prime time.  I too
>> wondered why it was excluding edit, editNew.  I'm sure there was a reason.
>>
>> Peace,
>> Scott
>>
>> On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans <
>> jeromy.evans@blueskyminds.com.au> wrote:
>>
>>     
>>> stanlick wrote:
>>>
>>>       
>>>> Also, what is the naming convention for validation xml files using the
>>>> Code
>>>> Behind/REST plug-in?
>>>>
>>>> I've tried several combinations of naming, but none seem to work.
>>>>
>>>>
>>>>
>>>>         
>>> The short answer is: you can't. It doesn't work.
>>> Fortunately annotation validation works correctly in 2.1, so the approach
>>> I've used is:
>>>  - the action carries validation annotations on the applicable methods;
>>>  - the model's use XML validation
>>> as they can be used together and it's well suited to ModelDriven.
>>>
>>> The problem is that the DefaultValidatorFileParser in Xwork that reads the
>>> XML file has no way to specify which method it should be applied to.  It
>>> applies to the entire class.
>>> With wildcards in 2.0 you could get around this because the action "alias"
>>> included the method name.
>>>
>>> It's the same reason using "method='update'" spefied in struts.xml never
>>> worked properly with XML validation. The parameter was ignored by the XML
>>> validator. This had always frustrated me.
>>>
>>> Fortunately somebody fixed the annotation interceptor so it can distinguish
>>> between the methods being executed.  Unfortunately that fix
>>> (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default.
>>> Further compounding the problem is that rest plugin has disabled validation
>>> for the edit, editNew and other relevant methods. (I'm not sure why...there
>>> must have been a reason for that).
>>>
>>> What I've done is replace the rest default stack with one that includes the
>>> validation interceptor with better configuration:
>>>
>>> <interceptor-ref name="validation">
>>>  <param name="excludeMethods">input,back,cancel,browse,index</param>
>>>  <param name="validateAnnotatedMethodOnly">true</param>
>>> </interceptor-ref>
>>> <interceptor-ref name="restWorkflow">
>>>  <param name="excludeMethods">input,back,cancel,browse,index</param>
>>> </interceptor-ref>
>>>
>>>
>>> I've been tempted to delve in a fix this but so far I've stayed out of
>>> xwork. The rest plugin does the right thing setting up the ActionInvocation
>>> with the action name and method name; the XML validation config reader just
>>> needs to use the method name to select the file (eg. to load
>>> OrdersControler-<action>-<method>-validation.xml if it exists). 
But I feel
>>> it already searches for far too many combinations, so I've been reluctant to
>>> touch it.
>>>
>>> stanlinck also wrote:
>>>
>>>  Would you share the interceptor stack to fold paramsPrepareParamsStack
>>>       
>>>> capabilities into the restDefaultStack?
>>>>
>>>>         
>>> I haven't experimented with this much with the rest plugin as I try to
>>> avoid it .  It's reasonable logical...
>>>
>>> The actionMappingParams interceptor is the one responsible for setting the
>>> id, so it needs to appear before the prepare interceptor.
>>> If you need other params, before prepare, you also need params before
>>> prepare.
>>> The actionMappingParams and params are then required after prepare again.
>>>
>>> ie. set the id, load the object, set the id and params
>>>
>>> It's different because the ActionMapper obtained the id from URI.
>>> If you use other variables in the namespace you also need this interceptor
>>> before prepare.
>>>
>>> Hope that helps,
>>> Jeromy Evans
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>       
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>   


-- 
Al Sutton

W: www.alsutton.com
B: alsutton.wordpress.com
T: twitter.com/alsutton


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message