I've been chatting with Gavin about this for some time-- the code generation vs. dynamic generation for scaffolding. I believe the tooling coming from seam/hbm is all code generation where I would think there would be advantages to having component sets that dynamically determine validators and converters based on metadata. Higher level components could be constructed to actually compose the CRUD pages as a droppable component.
>Please check out hbm2seam ( Hibernate Tools suite ) before a lot of hard work >is poured into this. There may be a large duplication of effort. The last I >checked, this was in alpha. > >Dennis Byrne > >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, May 3, 2006 11:57 AM >>To: [email protected] >>Subject: RE: Summer of Code >> >>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. >>> >> > >
