[jira] Updated: (WW-2826) Make struts2 more component-friendly

["James Holmes (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/struts/browse/WW-2826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Holmes updated WW-2826:
-----------------------------

    Fix Version/s: Future

> Make struts2 more component-friendly
> ------------------------------------
>
>                 Key: WW-2826
>                 URL: https://issues.apache.org/struts/browse/WW-2826
>             Project: Struts 2
>          Issue Type: New Feature
>    Affects Versions: 2.1.2
>            Reporter: Sami Dalouche
>             Fix For: Future
>
>
> Contrary to component-oriented frameworks , Struts2 architecture does not try to ignore what the web is, it just tries to make web programming easier without introducing complex component lifecycles.
> However, there are a few things that the component-oriented frameworks got right, and I believe struts2 should build on its architecture to enable users to create UI components easily. 
> These needs arise from the project I am currently working on, and I describe the hacks that I currently do to 'simulate' components. I also try to envision the features that struts2 could add to make writing components easier. This 'request' should be seen as a meta-feature request that can be used as a basis for discussing what should be included. Once everybody agrees, we can create smaller issues that target individual concerns.
> So, let's define what a reusable UI component needs to work decently:
> - Markup template. (the view)
> - Custom CSS for the component
> - Custom JavaScript for the component
> - Access to helper Java code 
> - Access to a given model, expressed as a Java class that has to be pushed on the value stack, so that it can catch URL/form parameters related to the component
> - When the component displays part of a form, the action has to delegate part of the validation to the component's model, using @VisitorFieldValidator
> - a Custom interceptor to set parameters on the action
> - Custom properties file for I18N
> Frameworks such as tapestry have built-in features for all these concerns. Here is the struts2-way to achieve the same, with the current feature set :
> - Markup/View: Markup template expressed as FTL, either using the Struts2 Component / Taglib infrastructure, or just plain FTL files that have nothing to do with struts2
> - Custom CSS and JavaScript either sourced or included in a specific @component.head  tag. the developer is responsible for including head in the head section of the page.  The head macro has to be coded in a way that does not include JS / CSS directly, but first checks if it hasn't already be included, in case several components transitively depend on a given component and call it's head as part of the head tag/macro. Also, the tag is responsible to use either the real .css/.js file, or the one generated by the build system in case there are hooks to merge CSS and JS files in order to reduce the number of requests.
> - Helper java functions have to be registered using a Custom Freemarker Manager. Adding helpers to the freemarker context is pretty straightforward, but adding the services to the ValueStack too is a little tricky. You have to make sure you don't  push the same service twice in the same request, because populateContext() is called several times...
> - The component's java model has to be pushed by the action. pretty much like the action's view has to reference the head tag in the head section. I use a MultipleModelDrivenInterceptor that works like ModelDrivenInterceptor, except that is pushes a list of objects, instead of just one.  In case the component adds fields to the form, the action is responsible for adding @VisitorFieldValidator. 
> - For important parameters and session attributes that are considered globally accessible on the website, specific interceptors + *Aware interfaces can be used to ease the actions' job. Things like Users, etc, can be directly injected to the action to avoid boilerplate copy/pasted code.
> - Each component has its own properties file, that is registered in struts.xml as a global resource bundle.
> OK, now, why I think all this stuff is suboptimal :
> - There is no common concept in struts that defines what a component is. so all the pieces are available, but it looks like tricks and hacks that we try to get to work. It would definitely be less worrying for the developer if struts provided an 'official' way to do it.
> - the developer is responsible for adding head to the HTML head section, for creating the component's Java Model, for pushing it on the value stack, and for delegating validation to the component. WAO !!! In most cases, if you're not the one who developed the component, you will forget one of these steps.  
> - The developer is responsible for making sure keys are globally unique among components... Hum... Once again, this gives the impression of a mere hack...
>  Pushing some resource bundle using the I18N tag is not an option since it renders the use of <#nested> useless. For instance, if a component did :
> <@s.i18n name="myComponentResourceBundle>
>  <@s.text name="whatever.key.in.component.resource.bundle" />
>  <#nested />
> </...@s.i18n>
> then if the component is called with <@s.text /> code in the <#nested /> section, the <@s.text would not find its key in the component resource bundle, and would then fail. Implementing a fallback mechanism that would go down the value stack could partly work, but would still not fix the duplicate key problem. 
> - When we want to do some processing depending on the parameters, and inject some variables to the current action thanks to a custom interceptor, we don't have access to type converters, we basically need to do the job by hand (or probably instantiate the type converters, or do whatever hardcore low level struts or OGNL stuff to achieve the same). So, the only real way to bind parameters is to use a custom model class that is instantiated and pushed on the value stack by the action, but then the action has too much stuff to do regarding the component. See previous section regarding custom java component models.
> So, what I think struts could add in order to make writing components more consistent and easier :
> 1] A small wiki section that describes the 'preferred' struts approach to creating reusable components, whatever approach is chosen. Even if the wiki section is considered as a mere suggestion, it would allow users to realize that it is in fact possible to write components using struts2, and would certainly help struts2 beginners. 
> 2] A kind of generic behavior that would allow components (Struts 2 Tag Components) to register custom CSS and JS code, that would be printed in the default struts2 themes. (<@s.head />). In order to select which components are used on a page, I guess that parsing the FTL would be too weak ? So, it would be acceptable to force the action to declare the list of the components that are used. Do some people have an idea regarding this ?
> 3] A way for Struts2 components to declare :
> - A method to create the associated java model object, for every request where the component is used. This model object should be pushed to the value stack automatically.
> - the ModelDriven-validation.xml rules that should be included when the component is used. The main problem I see with that is that is to allow switching validation off, because the action would probably  want to validate the model for the execute() method, but not the input() one. 
> - An interface that an action could implement to receive the populated model (MyModelAware.class), as well as some callback method that is used to set the model on the implementing action. A generic interceptor could then use whatever ThreadLocal/request-scoped object to retrieve all the callback methods that have to be called on the current action, depending on the types implemented by the action.
> - The name of a spring/whatever IoC service that should be registered in the freemarker + OGNL context, so that FTL views can refer to it
> - The name of a .properties file to use for I18N keys lookup. To make this to work, my guess is that @s.text would need to be completly reworked to be component aware, since both global keys, and trying eveyr textprovider in the value stack both don't fix the duplicate key problems. Maybe some experts have a better idea to solve this issue ?
> That's it ! (I think) :p
> So yeah, still a lot of questions, it's definitely a tough problem, but I really believe it's worth thinking a little bit about that.
> In my project, I am progressively starting to extract abstractions to create components, so don't hesitate to bring your ideas to complement what I suggested. I would happily share the code that implements these ideas whenever it is available.
> Regards,
> Sami Dalouche

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.