+1 for templating, whether it is velocity or freemarker(my vote is on freemarker btw:), it's a much better solution than using printwriter api.
Much easier to test and maintain. C.C. On Fri, Mar 28, 2008 at 2:07 PM, Werner Punz <[EMAIL PROTECTED]> wrote: > 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 > >
