Details
- Type:
New Feature
- Status: Open
- Priority:
Major
- Resolution: Unresolved
- Affects Version/s: 2.0.1
-
- Component/s: Plugin - Tags
- Labels:None
Description
The url and param tags are very flexibile, but the most common case of a single parameter link.
<s:url
<s:paramen</s:param>
</s:url>
<s:a href="%
">English</s:a>
is verbose (to the point of being silly).
It is worthwhile to have a streamlined link tag, a al Struts 1, to cover the single-parameter case.
<s:linkEnglish</s:link>
In the interest of brevity, I would suggest that includeContext default to "false" for the single-parameter case.
Or, with a message resource key, from
<a href="<s:url">%{getText('"sign_on"')}
</a>
to
<s:link
Activity
- All
- Work Log
- History
- Activity
- Transitions
OK, I'm willing to take a crack at this but it seems worthy of some discussion. It seems that the end goal is a "fusion" of the AnchorTag and the URLTag.
My plan is to extend AnchorTag and copy its TLD so as to continue to support all of its attributes. Then, as Ted suggested, add
param
paramValue
(I'd consider also having something like paramMap as an alternative, if people thought it was a good idea, but if no one argues for it, I'd probably leave it out for now.)
the URL tag has the following attributes:
protected String includeParams;
protected String scheme;
protected String value;
protected String action;
protected String namespace;
protected String method;
protected String encode;
protected String includeContext;
protected String portletMode;
protected String windowState;
protected String portletUrlType;
protected String anchor;
Obviously we need to support "action" and "value" or we haven't achieved anything. The main reason I want to use it is to have the "includeContext" behavior that the url tag gives – so I dont think I understand why Ted wants it to be false?
Should we drag all of these across?
Are there any extant tags which hold on to an additional Component instance besides their "primary one"?
Any other things to think about?
At one point, includeContext was stacking up the the parameters if used in a get, so the query string just got longer and longer if the link lead back to the same page. But, that behavior changed between 2.0.2 and 2.0.3, and so true would be fine now.
Earlier, I asked:
Are there any extant tags which hold on to an additional Component instance besides their "primary one"?
I'm still getting familiar with the architecture of the component tags, but it kind of seems to me that it will be pretty hacky to use two components. If I want to extend AnchorTag but also have a URL component then I kind of need to construct the URL object in getBean(stack,req,res). I can do this, but it seems like a "side effect" to requesting the bean. And if I'm not returning the URL object, then I also need to replicate the dependency injection behavior for the URL which is done for the "primary" component bean in doStartTag() after getBean is called.
I am not saying I think it would be horrible to do this, but it's not that elegant either, so especially because i'm new to the tag architecture, I didn't want to act without input.
Also, since I can only extend one tag, I would have to duplicate the "populateParameters()" behavior from URLTag to initialize my URL component. Would it be crazy to have component beans have a populateParameters(Object source) method? I am not sure I love that, but it crossed my mind as one possible solution.
Including the paramMap functionality could really clean up JSP code if the map can be built in the Action, although it might be nice if you could still add params via the s:param tag.
Ted recently upgraded this one to "critical" and slated it for the next release.
If I'm going to keep it assigned to me, I'd really appreciate at least a little opinion from someone with more investment in the UI tag architecture on the questions noted above....
anyone?
All too often, the only way to get anyone to comment on anything is to commit something
Sometimes, a "dodgy" commit is better than none, since then people have something concrete to discuss.
I like the feature, but moving to Future until someone signs up to implement it