Hi Leonardo,
> If you want forceId feature works, you need to override getClientId(),and
> if you want to use visibleOnUserRole property, you need to override
> isRendered(). And also if you want that the component implements some
> interfaces you need to specify this on the template.
>
> In this case, we can use abstract classes to do this but the result is the
> same as with templates.
>
yes - but abstract classes are a lot easier to handle, and you can save the
generation step whenever you change the derived class - in the case of
changing the template you would need to regenerate.
> 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);
> }
> }
make it as Simon said - package private. or provide a protected getLocalInto
accessor (configurable). As long as we don't have Mix-Ins in Java, I am for
abstract base classes - when they are here, we can change back.
Not have code completion and other features on the IDE is a low price for we
> have with templates.
we severely disagree on this point - not having features of the IDE is
killing templates in my (and many others) eyes. You are a lot more efficient
if you have proper code-completion, search, refactoring at hand.
regards,
Martin
