Hi Thomas,
As you've understood, Stripes has no "intermediate object" between
controller and view, as you can find in SpringMVC (ModelAndView), or
apparently the PHP framework you mention. You just handle it your way, all
you have is the action bean.
For simple cases, I guess that ${actionBean.property} is enough. See the
Calculator example.
In the end, we all end up with intermediate objects, we often even expose
domain objects directly to the views. You don't extract the properties of
your domain model into each action bean, instead you reference the domain
objects direcly in your JSPs :
${actionBean.myDomainObject.myProp}
So in case you feel complexity's getting beyond the acceptable limit, create
a POJO that holds the state you need in your views. That's just good design
I think (object were meant to be modular they said :P). It could (read
should) also encapsulate some of the logic you apparenly have in the
Resolutions at the moment, making your application independant of any third
pary framework, easily testable, etc etc. In the end, action beans should
contain the less code as possible, they're only a bridge between the web and
your own POJOs.
Anyway, one thing is sure : the use of request attributes doesn't really
help, as you still don't know what request attrs are set by which event
handler. Go for the POJO :)
Note that it won't solve the "what property can I use in this view ?"
problem : you still have to ensure that properties you access in your views
are ready, and this can depend on the event handler used. AFAIK only good
engineering can save you there, as there's no strong way I know that can
enforce that.
Cheers
Remi
2011/6/20 Thomas Menke <stripe...@cipher-code.de>
> Hi,
>
> coming from the PHP world I am starting to get practice with Stripes.
> And I wonder how to best communicate between JSP and my ActionBean. In
> PHP I liked to use "smarty". There one just saves all the data the
> template needs into a large HashMap und the template will work with this
> map, after the lifetime of what was comparable to the ActionBean already
> exceeded its lifetime.
>
> I noticed that I can get the same behaviour with JSP by using
> getContext().getRequest().setAttribute("name", someObject);
> That works very well, but I doesn't feel like I am "supposed to do
> this". Am I? Is this a suitable approach? Or are there good reasons to
> keep hands away from this?
>
> The other way is obviously to have some getter-methods on my ActionBean
> that I call from the JSP file. That is what I used most of the time. But
> sometime I want to calculate values for the JSP in my event handler.
> Thus I have to save them in a property of the ActionBean and introduce a
> getter method for them. That works well for small ActionBeans, but with
> a rising number of event handlers within one action bean I easily loose
> the overview which property I introduced for which event handler.
>
> Another approach that I have seen is creating a POJO for each and every
> jsp page with all properties for that JSP page. Then this object is
> saved as a property of the actionBean and it is worked with from JSP
> (additionally this may save a little memory because only the properties
> that are actually needed by the current JSP need to be allocated).
>
> What would you say is "best practice" and why?
>
> Thank you,
>
> Thomas
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
