JSF *really* needs this agility with CRUD scaffolding. I've been thinking though with JEE 5 and the EJB 3 adoption, that you couldn't produce something similar to your proposal that works off of pure EJB 3 metadata define the pages. Something like:
<ejb:form> <ejb:field> <ejb:dataTable> <ejb:filter> This way, you could have your EJB 3 annotated model and without doing any model wiring, these components would work by Class type to handle persistence/UI concerns directly without hand-holding. As for templating with Facelets, Rick Hightower published something similar at IBM: http://www-128.ibm.com/developerworks/java/library/j-facelets/index.html He says he has another article on the topic coming out soon. Overall, the need you are describing is obviously there. I wish JBoss would've pursued this route more actively with Seam's UI library. -- Jacob > >Hello. It is not a comlete proposal, but I rather want to know your opinion >on the project i'm working on. It is not straight myfaces codebase related, >but you seem as most appropriate mentor. I planned to work on it before I >knew that there is SoC. But may be you will convince me of its uselessness. > >Recently I have been writing application using jsf. The application is >mostly CRUD. I think that there is much glue code that can be eliminated. >All that identical CRUD backing beans, forms, dataTables, navigation rules. >It is all powerful, but it should be possible to eliminate it until you need >something not very trivial. This is the principle which the Ruby on Rails >growing popularity came from. > >There arises a need to define rules of generating it all based on >information about a data model. Code generation tools are insufficient. >Imagine, you have generated all the beans and views, than provided some >changes to some of them and than you want to add small change to the >template or, say, add a field to the domain object. Now you are left on your >own to manually change it everywhere it is used. > >I propose to extend facelets templating abilities to be able to encapsulate >all that routine tasks into templates. See: >1) <template name="templateName"> marks any part of view definition as a >template. >2) <insert name="insertName"> marks parts of the template as redefinable. >3) <define name="insertName"> redefines redefinable parts during particular >template usage. ><insert template="templateName"> inserts template and if it is being used >inside another template definition it automatically marks redefinable part. >It can contain only <define> tags. Other tags inside it are treated as tags >inside <define> without name property defined. >With <insert name="insertName"> used during particular template usage you >can insert part of template marked as redefinable. > >Than we should generalize data CRUD interfaces and provide implementations >for technologies/contracts we use to implement business layer. I plan to use >very simple and extendable interfaces. > >Let's assume that ><data provider="reflectionDataProvider" var="lastItem" >object="#{itemsService}" methodName="getLastItem"/> >will get the Item object from getLastItem method and set lastItem variable >to Map containing Item object properties as keys and their values as values. > >Now the dream is to use ><insert template="map" data="#{lastItem}"/> >to create simple edit form. > >See how we can create such a template: > ><template name="map"> > <c:forEach items="#{data}" var="pair"> > <insert template=".field" name="#{pair.key}" dataMap="#{data}"/> > </c:forEach> ></template> > ><template name="map.field"> > #{key}: > <isType name="bool" var="#{dataMap[key]}"><insert >template=".bool"><insert name="validator"/></insert></isType> > <isType name="java.lang.String" var="#{dataMap[key]}"><insert >template=".string" name="validator"/></isType> > <isType name="html" var="#{dataMap[key]}"><insert template=".html" >name="validator"/></isType> > <isType name="java.util.Map" var="#{dataMap[key]}"><insert >template=".object" name="validator"></isType> ></template> > ><template name="object.field.bool"> > <h:selectBooleanCheckbox value="#{value}"><insert/></h:inputBoolean> ></template> ><template name="object.field.string"> > <h:inputText value="#{value}"><insert/></h:inputText> ></template> ><template name="object.field.html"> > <t:inputHtml value="#{value}"><insert/></h:inputHtml> ></template> ><template name="object.field.map"> > <insert template="map" data="#{value}"/> ></template> > >where for <isType> there is a helper TagHandler, which evalutes its body if >var is of pointed type. It is decided based on user-provided algorithm. It >allows to do such things as automatically providing textarea for long texts >and so. > >It is not necessary to divide all this functionality to many templates, it >can reside in only one. > >Now you can, for example, define special validator for itemUrl field of >lastItem object: ><insert template="map" data="#{lastItem}"> > <define name="itemUrl.validator"> > <t:validateUrl/> > </define> ></insert> >And for other fields we can add into template default validator, which will >validate them using hibernate validator annotations. > >Or we can redefine all components used to represent itemUrl property: ><insert template="map" data="#{lastItem}"> > <define name="itemUrl"> > #{lastItem.itemUrl} - url of item description > </define> ></insert> >Or we can extend or partially redefine map.field template to differently >handle some types. > >Actually, for short it is display only sample. It is not a comprehensive >description of my ideas. We will be able to write ><data var="actualItems" object="#{itemsService}" >methodName="getActualItems"/> ><insert template="object" data="#{actualItems}"/> >to represent a complete CRUD interface for caveatemptor.hibernate.org data >model with an ability to drill down to assotiated objects. And you still >have an ability to partially redefine default templates behavior. I call it >Smart UI. And important point that it does not impose any requirements to >your other view code. You can use it anywhere in facelets pages definitions. >And than you can easily scale introducing backing beans, navigation rules or >anything else only when you need it. > >Feedback is appreciated. >-- >View this message in context: >http://www.nabble.com/Summer-of-Code-t1550695.html#a4212272 >Sent from the My Faces - Dev forum at Nabble.com. >
