Some ideas about new struts2 codes

[Miles Huang <mi...@surwing.com>]

Hi, here are some ideas about the newly created struts2 codes.
1) The new MenuHelper system looks much clearer than old tag version. Since
the tag version classes is special designed for JSP pages, and the JSP pages
are not using them any more, the MenuModel can switch to the same MenuHelper
system now. It's great no more complex tag methods and share same Velocity
context as whole page models in the Velocity menu templates.
2) MenuTab and MenuTabItem may share same super class. Most of their codes
are same. More meaningful, this makes it possible to define MenuTab’s item
as another MenuTab (multi-level menu), which may be presented like a real
menu or tree like widgets. Same case as the parsed menu classes.
3) There are currently 2 different locations to define an action's required
privileges, the action itself by code and the menu system. I guess they
should be always consistent and would be better if they can be defined at
single place outside the action code, and then inject the configuration
value into the action. There should be some special consideration for
actions not appeared in any menus. May be a never rendered menu define
gathers all those actions in it.

Miles.
-- 
View this message in context: http://www.nabble.com/Some-ideas-about-new-struts2-codes-tf3851828s12275.html#a10911385
Sent from the Roller - Dev mailing list archive at Nabble.com.

Re: Some ideas about new struts2 codes

[Allen Gilliland <al...@sun.com>]

Miles Huang wrote:
> Hi, here are some ideas about the newly created struts2 codes.

> 1) The new MenuHelper system looks much clearer than old tag version. Since
> the tag version classes is special designed for JSP pages, and the JSP pages
> are not using them any more, the MenuModel can switch to the same MenuHelper
> system now. It's great no more complex tag methods and share same Velocity
> context as whole page models in the Velocity menu templates.

Yes, I definitely want to remove the old MenuTag code very badly and 
using the new Menu stuff is what I hope to do.  The current problem 
though is that the old menu code had a programmatic way (via a struts1 
RequestUtils class) of building urls to actions while the new code does 
not.  The way the new Menu code is used it still relies on the struts2 
s:url tag to build the real urls to the actions and we don't have a way 
to do that in Velocity right now, but I am looking at how we can work 
around this.

This is something I am planning to fix pretty soonish since the old 
MenuModel stuff is broken now that the MenuTag can't build any real urls 
since our struts1 config is gone.


> 2) MenuTab and MenuTabItem may share same super class. Most of their codes
> are same. More meaningful, this makes it possible to define MenuTab’s item
> as another MenuTab (multi-level menu), which may be presented like a real
> menu or tree like widgets. Same case as the parsed menu classes.

Yeah, I wouldn't have a problem with that.  I don't envision us using a 
multi-level/tree like structure for the tab menu on the UI at any point, 
but if people want to modify the config to be multi-leveled then there 
isn't any real reason we can't support that.


> 3) There are currently 2 different locations to define an action's required
> privileges, the action itself by code and the menu system. I guess they
> should be always consistent and would be better if they can be defined at
> single place outside the action code, and then inject the configuration
> value into the action. There should be some special consideration for
> actions not appeared in any menus. May be a never rendered menu define
> gathers all those actions in it.

I had also shortly considered trying to find a way to make the 
permissions model actually work dynamically out of some kind of config 
file, but decided it wasn't something that I really thought we needed 
yet.  I am open to suggestions on how this would be done though.

-- Allen


> 
> Miles.