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:xf2...@fastmail.fm]
>> 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"
>> <christian.poit...@ircm.qc.ca> 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:evan.leon...@gmail.com]
>>> 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
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
