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. >> >
