Sorry for jumping that late into the thread since I am facing similar
issues currently I started to read it.
Leonardo Uribe schrieb:
Hi
I have made a wiki page for MyfaceBuilderPlugin here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
There is written the ideas present on the sample code, the comments on
the dev list and what I think that this plugin should looks like.
On Sat, Mar 15, 2008 at 4:11 PM, simon <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
In addition, the code in the myfaces-faces-plugin is really ugly. I
cannot believe that the "class generation" is done like this:
if (property.isLiteralOnly() || property.isTagAttributeExcluded()){
//If the property is literal or is tagAttributeExcluded,
//the default value goes on the definition of the field
out.println("private " + propertyClass + propertyGenerics + " "
+
fieldPropName + (def == null ? ";" : " = " + def +
";"));
}else{
//If is a primitive class, has a set field to check if this
//property is defined, so the default value goes on the
//getter method.
//If is a class, the same applies, because the check
//is against null
out.println("private " + propertyClass + propertyGenerics + " "
+
fieldPropName + ";");
}
This should really be template-based so that changes don't require
understanding, modifying and re-releasing the build plugin.
I think (and it's my personal opinion) that templates for generate
component classes, tag classes and other files are harder to maintain
with template tools that simple java code. I have done a work long time
ago with velocity for generate hibernate code from a xml model. One
small part could be seen below:
//Getter and Setter Methods for foreing key fields
#foreach( $field in $entity.getChild("fks").getChildren("field") )
#set ($name = $utils.lowerCase($field.getAttributeValue("target-table")))
#set ($type = $utils.capitalize($field.getAttributeValue("target-table")))
#set ($sql-name = $field.getAttributeValue("sql-name"))
#set ($target-col = $field.getAttributeValue("target-col"))
@ManyToOne #if
($field.getAttributeValue("pk").equalsIgnoreCase("multiple"))(fetch =
FetchType.LAZY)#end
@JoinColumn(name = "$sql-name",
referencedColumnName = "$target-col"
#if ($field.getAttributeValue("pk").equalsIgnoreCase("multiple"))
, nullable = false, insertable = false, updatable = false
#end
)
public $type get$utils.capitalize($name)(){
return $name;
}
public void set$utils.capitalize($name)($type $name){
this.$name = $name;
}
#end
The problem to understand the template starts when the different options
for generate one part of code starts to grow. What happen when a
property is literal? What happen when not? How to set a default value?
Do we have to cast or convert using valueOf to avoid compiler exception
on jdk 1.4? The same conditional should be written on java or velocity,
the question is what is more clean to write. I prefer /don't write the
same code twice / if I don't gain some in exchange.
Lenardo, I personally think that some problems cannot be resolved in a
clean way. I personally think that velocity still is one of the best
templating languages (I dont like freemarker too much due to its xmlish
syntax which is too close to webish languages like xml, html etc... to
keep the templates readable)
I dont think java code is really that easy to maintain, every time
someone applied a printwriter api to any technology people started to
curse the unmaintainability. I agree with this problem if you drop
templates you get java code bloat which is close to being unmaintainable.
I personally think a templating apporach is advicable, but
* keep the templates structured (aka apply different templates to
different domains)
* try to enhance reusability by introducing macro libraries or
something similar
* Keep a very strong mvc model dont mix too much logic into the
templates, a template with 15.000 branch conditions is pointless and a
maintenance nightmare
But if you apply all this you basically are way better off than using a
printwriter api.
In the end you probably will end with certain templates for serving core
components, serving parts of the renderers (with different templates for
trinidad tomahawk and tobago)
and all of them share common macros.
Werner
