myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Byrne" <den...@dbyrne.net>
Subject Re: Summer of Code
Date Wed, 03 May 2006 16:03:18 GMT
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: jacob@hookom.net [mailto:jacob@hookom.net]
>Sent: Wednesday, May 3, 2006 11:57 AM
>To: dev@myfaces.apache.org
>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.
>>
>



Mime
View raw message