[
https://issues.apache.org/struts/browse/WW-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Schneider resolved WW-1197.
-------------------------------
Resolution: Won't Fix
Assignee: Tom Schneider
I'm going to pull rank and decide that we shouldn't do this. I think it would
add unnecessary complication to the existing hierarchy and only cause more
maintanence issues. Also, considering the fact that many people want to move
away from ftl driven tags, that only reinforces the decision. So unless
someone feels very strongly for this, I'm marking as Won't Fix.
> To have a few lighter weight parent objects for UI Components to inherit
> from when creating tags
> -------------------------------------------------------------------------------------------------
>
> Key: WW-1197
> URL: https://issues.apache.org/struts/browse/WW-1197
> Project: Struts 2
> Issue Type: Improvement
> Components: Plugin - Tags
> Affects Versions: WW 2.2
> Reporter: Nathan Sarr
> Assignee: Tom Schneider
> Priority: Minor
> Fix For: 2.1.1
>
>
> This is a copy and paste from the initial post. See full post at:
> http://forums.opensymphony.com/thread.jspa?threadID=18510&tstart=0
> For example webwork could have a TemplateBeanInterface with an
> interface for the Template* methods
> Then modify the TemplateContext and Template Engine to take a
> TemplateBeanInterface so that a Tag must only have the necessary
> TemplateBeanInterface to be used by the template engine and related
> classes.
> Following that a few other interfaces could be created:
> A BaseUiBeanInterface that has get and set methods for the following:
> class
> id
> style
> title
> see - http://www.w3schools.com/tags/ref_standardattributes.asp
> A FormEventBeanInterface that has get and set for the following:
> onchange,
> onsubmit,
> onreset,
> onselect,
> onblur,
> onfocus
> If we keep following the pattern we would have WindowEventUiBean,
> KeyboardEventUiBean ...
> see - http://www.w3schools.com/tags/ref_eventattributes.asp
> Finally webwork could create a few Base bean implementations like the
> following for tag developers:
> BaseTemplateUiBean implements TemplateBeanInterface{}
> BaseUiBean extends BaseTemplateUiBean implements BaseUiBeanInterface{}
> FormUiBean extends BaseUiBean implements FormEventBeanInterface{}
> That way tag developers can implement the interfaces themselves or grab
> one of the above implemented beans along the hierarchy that best meets
> their needs as well as create their own combinations of inherited
> classes and interfaces.
> *--------------------------------------------------------------------
> (NOTE: there was some concern about the performace of the following method
> in the post. Please see post for further details).
> I was also wondering about adding another method to one of the
> Base classes - something like
> public boolean addNonNullValue(String key, String value){
> boolean added = false;
> if( value != null ){
> added = true;
> addParameter(key, findString(value));
> }
> return added;
> }
> I noticed a lot of the following in the Component classes
> if (param != null) {
> addParameter("param", findString(param));
> }
> by adding the new method, I don't have to check for a null
> value every time I can just make the call
> addNonNullValue("param", param);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
