Hi all
Been following this thread for a while.
Interesting. I believe in a simple approach to the binding which I believe is
done very good by Stripes as it is now. You could turn it around and say that
you want your domain object to be web enabled.
Would it be possible to reuse the converter approach and make a class that
takes parameters from the request and binds them into the bean using the
converter? The you would have something like: actionBean.domainBean.value -
just the way it is now, except the binding is encapsulated in a converter.
Regards
Søren
Den 07/10/2010 kl. 07.59 skrev Evan Leonard <evan.leon...@gmail.com>:
>
> Hi Remi,
>
> Good question about the views. There's a couple ways to consider going there.
>
> There's already got $actionBean in the request attributes, so I initially
> thought $actionParams could also be put in the request attributes. This would
> just be a map from paramName -> bound param value. Then I looked into the
> number of places that the request attribute key for "actionBean" is used and
> its quite a few (going in and out of flash scope for instance). This made me
> rethink my approach, and instead try to piggy-back on top of all of the
> moving around of the actionBean that Stripes already does.
>
> Where I'm at right now is that the parameter value map would be available on
> the ActionBeanContext as a new property. Then in your view you could do
> something like this:
>
> $actionBean.context.boundParams.myParam
>
> Its a little bit of a mouthful, but it would provide access to the parameters
> without having much impact on existing code. And you could always create a
> shortcut to it like its common to do with contextPath:
>
> <#assign contextPath = actionBean.context.request.contextPath/>
> <#assign params = actionBean.context.boundParams/>
>
> As a more of a general comment, the reason I'm interested in this is that
> when you first look at Stripes' competitors, action parameter binding is one
> of the first things that makes people go "oooh neat!". It gets back to that
> thread we had about the "perception" of being stale, stagnant, and old. I
> know that adding parameter binding might be perceived as a running counter to
> the KISS values that have made Stripes great, but I think the change might be
> worth the benefit.
>
> What do other's think?
>
> Evan
>
> PS, I basically have a working prototype of this. Here's a sample of a
> passing test using parameter binding:
>
>
>
> @UrlBinding("/ParameterResolverTests.action")
> public class ParameterBindingTests implements ActionBean {
>
> private ActionBeanContext context;
> private String bindingResult;
>
> public ActionBeanContext getContext() { return context; }
> public void setContext(ActionBeanContext context) { this.context =
> context; }
>
> @ParamBinding({"name","number"})
> public Resolution basicParams(String name, int value) {
>
> bindingResult = name + " " + value;
> return null;
> }
>
> public String getBindingResult() {
> return bindingResult;
> }
>
> // Start of Test Methods
>
> @Test(groups="fast")
> public void testBasicParamBinding() throws Exception {
> MockRoundtrip trip = new
> MockRoundtrip(StripesTestFixture.getServletContext(), getClass());
> trip.addParameter("name", "myname");
> trip.addParameter("number", "2");
> trip.addParameter(StripesConstants.URL_KEY_EVENT_NAME,
> "basicParams|name|number");
> trip.execute();
>
> ParameterBindingTests bean = trip.getActionBean( getClass() );
> Assert.assertEquals(bean.getBindingResult(), "myname 2");
>
> String s = (String) bean.getContext().getBoundParams().get("name");
> Assert.assertEquals(s, "myname");
> }
>
> }
>
>
>
>
> On Oct 6, 2010, at 3:06 PM, VANKEISBELCK Remi wrote:
>
>> Hi folks,
>>
>> There's one thing though, what about the views ?
>> One cool aspect of the stripes way is that you access the bean
>> directly from the view, usually using el, like "actionBean.myProp".
>> The values accessed are often bound by stripes on the bean.
>> Now, if you pass bound objects to a handler method, how will you
>> access those values from your jsps ?
>> If you have to use bean state for that, you still have your initial
>> problem : you'll need accessors, and you won't know easily where (in
>> views this time) props are used.
>> In spring there is the ModelAndView indirection : a kind of binding
>> passed to the view with all needed data. that doesn't exist in stripes
>> : views access the bean directly.
>> So imho the current system is sufficient, and most of all, it's simple.
>> In most cases, when your validation and binding becomes complex,
>> you'll probably make it much simpler by just breaking your one fat
>> action into several smaller ones...
>> Cheers
>> Remi
>>
>> 2010/10/6, Poitras Christian <christian.poit...@ircm.qc.ca>:
>>> It could be a good idea to keep both binders separate and have a aggregate
>>> binder that uses both sub-binders. That would allow full flexibility.
>>> What do you think?
>>>
>>> Christian
>>>
>>> -----Message d'origine-----
>>> De : Evan Leonard [mailto:evan.leon...@gmail.com]
>>> Envoyé : October-05-10 5:42 PM
>>> À : Stripes Users List
>>> Objet : Re: [Stripes-users] Associating Parameters to Specific Actions
>>>
>>>
>>> I was thinking it would be possible to use both. Either by adding a second
>>> type of binder to the configuration, so they both run, or potentially by
>>> subclassing the existing binder to overlay the functionality.
>>>
>>>
>>> On Oct 5, 2010, at 2:36 PM, Poitras Christian wrote:
>>>
>>>> The downside of using 2 binders is that it's difficult to mix both
>>>> approach.
>>>>
>>>> Still, it would seem bizarre to have both approach in the same program...
>>>>
>>>> -----Message d'origine-----
>>>> De : Evan Leonard [mailto:evan.leon...@gmail.com]
>>>> Envoyé : October-05-10 3:31 PM
>>>> À : nikol...@brightminds.org; Stripes Users List
>>>> Objet : Re: [Stripes-users] Associating Parameters to Specific Actions
>>>>
>>>>
>>>> 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: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
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>> --
>> Envoyé avec mon mobile
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
