On Wed, 2008-01-30 at 16:11 -0500, Leonardo Uribe wrote:
>
> One useful example of why templates are better than abstract classes
> is this:
>
> This is the code of
> src/main/java-templates/org/apache/myfaces/custom/buffer/BufferTemplate.java
>
> public class Buffer extends UIComponentBase{
> {
> /**/private String _into = null;
>
> void fill(String content, FacesContext facesContext){
> ValueExpression intoVB;
>
> if (_into == null) {
> intoVB = getValueExpression("into");
> _into = intoVB.getExpressionString();
> } else {
> intoVB = facesContext.getApplication().
> getExpressionFactory().createValueExpression(
> facesContext.getELContext(), _into,
> Object.class );
> }
>
> intoVB.setValue(facesContext.getELContext(), content);
> }
> }
>
> Please take attention on this line:
>
> /**/private String _into = null;
>
> If you write an abstract class, you have to put this field as
> protected, which is bad. To make abstract class works for this code
> you have to write more code than shown here, or exclude component
> class generation for this guy.
Wouldn't using package scope for this variable work fine, if the
abstract class is generated in the same package as the concrete child
(which will always be the case)?
Yes it would expose the var to other classes in the same package, but
the external API remains clean.
>
> Trinidad view about how to develop components is that if we have some
> code that could be in renderer we have to put in the renderer. But the
> practice says that there are some situations when we need to write
> custom code on component class.
Doesn't that cause a problems when multiple renderkits are implemented?
>
> In tomahawk 1.2.x, the 80% of the components use template files to add
> custom code to use forceId, visibleOnUserRole, implements additional
> facets, define constants used on the renderer, or override
> processXXXXXX(FacesContext context) methods (and tomahawk is full of
> components created by users!).
You mean these templates are being used to implement aspect-oriented
programming? Then maybe we should consider using a proper
aspect-oriented-programming tool?
>
> Actually, the only code that breaks the templates is when you want to
> define restoreState and saveState methods. In that case you have to
> use abstract class or exclude the class for component generator, use
> the generator, generate some code and put this on the real component
> class.
>
> Not have code completion and other features on the IDE is a low price
> for we have with templates.
I think that's rather a high price personally.
But to me the real price is still when people look at the code and say:
what gets generated? where does it come from? how do I make the
generation happen? how do I set up my IDE to see the generated code?
See just today for example:
http://issues.apache.org/jira/browse/MYFACES-1225
I thnk that so far we all agree that:
* the old approach of files with "==do not edit this bit==" sucks. It is
inelegant and people *do* edit that bit.
* having artificial generated parent classes sucks; it distorts the true
hierarchy and simply cannot be applied to the API classes.
* generating source in general sucks, because it is not usual and is an
extra step that developers need to learn about; the more complicated the
process is, the worse the suckiness.
* generating source for files that other code depends on sucks, because
the code is not compilable after a checkout
* checking in generated source sucks.
* generating source into the src/main/java tree sucks, because it is
hard to tell generated code apart from non-generated stuff.
* generating source into the target tree sucks a bit, because you need
to explicitly add it to an IDE
* generating source for files that are frequently debugged sucks,
because you have to add the generated source path before using a
debugger.
* having code in templates sucks, because you don't have the normal IDE
support, and it leads to the above "generated code" suckiness.
Doesn't this all lead back to having annotations on normal classes, with
no code-generation except for classes that no-one really cares about
(tag handlers)?
On the pro side of templates, the ability to do AOP is possibly useful,
but again I think using a real AOP tool would be better.
The only direct alternative I can see is Matthias' view that components
should not be edited at all, and all custom logic should be in renderer
classes. However like Mario I am rather skeptical about that; it just
does not sound right to me. And in any case, that still qualifies for a
number of the above categories.
Regards,
Simon
