Certainly!
I started doing a little prototyping with this today while waiting for another
build to finish. I'm trying the approach of having one annotation on the method
like this:
@ParamBinding({"aString", "aNumber"})
public Resolution myAction(String aString, int aNumber) { ... }
The question I'm currently thinking about is whether to add to the
implementation of DefaultActionBeanPropertyBinder or whether there should be
second type of binder, something like this:
public interface ActionHandlerParameterBinder extends ConfigurableComponent {
ValidationErrors bind(final Method handler, ActionBean bean,
ActionBeanContext context, boolean validate);
}
Thoughts?
Evan
On Oct 5, 2010, at 1:19 PM, Nikolaos Giannopoulos wrote:
> Evan / Christian / Remi et al.
>
> This thread is very interesting and I am enjoying it... and hope it
> continues...
> However, can we rename this thread to something more aligned to the
> discussion?
>
> If no one minds I have taken the liberty to rename it to the above ;-)
>
> Regards,
>
> --Nikolaos
>
>
>
>
> Evan Leonard wrote:
>> Here's an interesting approach from the waffle framework. It uses
>> annotations, but lists all the parameter names in a single annotation.
>>
>> @ActionMethod(parameters = {"firstNumber", "secondNumber"})
>>
>> Evan
>>
>>
>> On Oct 5, 2010, at 6:48 AM, Poitras Christian wrote:
>>
>>
>>> It's a problem that we faced in MyBatis when dealing with multiple
>>> parameters. We went with the annotation approach.
>>> I guess there are many workarounds for that and Spring is probably using
>>> one. Debug seems like a good workaround.
>>>
>>> Christian
>>>
>>> -----Message d'origine-----
>>> De : Freddy Daoud [mailto:[email protected]]
>>> Envoyé : October-05-10 8:40 AM
>>> À : Stripes Users List
>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>>
>>> Are you sure? I think that if you compile with debug info turned
>>> on, and your request parameters are named param1 and param2,
>>> they will be bound correctly without the need for the annotations.
>>>
>>> Or is that what you meant by "you will need the source code"?
>>>
>>> Cheers,
>>> Freddy
>>>
>>> On Tue, 5 Oct 2010 08:36:43 -0400, "Poitras Christian"
>>> <[email protected]> said:
>>>
>>>> A problem with the Spring approach is that parameter names are not
>>>> accessible by reflection.
>>>> The consequence is that if you have method like
>>>> public void substract(int param1, int param2)
>>>> It will be difficult to pass the parameters in the right order. You will
>>>> need either the source code to find the parameter names or an annotation
>>>> like
>>>> public void substract(@Param("param1") int param1, @Param("param2") int
>>>> param2)
>>>>
>>>> Stripes is not affected by that problem.
>>>>
>>>> Christian
>>>>
>>>> -----Message d'origine-----
>>>> De : Evan Leonard [mailto:[email protected]]
>>>> Envoyé : October-04-10 4:59 PM
>>>> À : Stripes Users List
>>>> Objet : Re: [Stripes-users] Stripes Development and its Future... (long)
>>>>
>>>> +1. Though it will take one of us being dissatisfied *enough* to
>>>> implement this ourselves :-)
>>>>
>>>>
>>>> On Oct 2, 2010, at 9:05 PM, Simon wrote:
>>>>
>>>>
>>>>>> In other words, in Stripes you'd have
>>>>>>
>>>>>> private User user;
>>>>>>
>>>>>> /* getters and setters */
>>>>>>
>>>>>> public Resolution save() {
>>>>>> // do something with user
>>>>>> }
>>>>>>
>>>>>> In Spring MVC you'd have
>>>>>>
>>>>>> public void save(User user) {
>>>>>> // do something with user
>>>>>> }
>>>>>>
>>>>>> The "do something"s in both Stripes action beans and Spring controllers
>>>>>> are
>>>>>> best left to injected helpers, daos, and so on, keeping the
>>>>>> action/controller
>>>>>> classes simple.
>>>>>>
>>>>>> So, in that respect, I'm not sure that using local variables leads to
>>>>>> more
>>>>>> complex procedural code, if you keep things simple in controllers.
>>>>>>
>>>>> The main drawback to the Stripes approach is that if you have multiple
>>>>> handlers on a single action it becomes ambiguous which bean properties
>>>>> are inputs to each action. When they are arguments to the handler
>>>>> method it is super clear what applies where. I wouldn't mind
>>>>> sometimes if Stripes supported either approach - why not just look for
>>>>> any method that returns Resolution and then if there are parameters,
>>>>> try to bind them, if you can? (yes, you probably need annotations to
>>>>> tell you the name to bind on, but I can live with that)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Simon
>>>>>
>>>>>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
