Hi Alexander! > But more interesting task is to extract data straight from the > business layer. Data can come not only from RDBMS, but from > web-services or other place. I've been thinking that we can provide > access to data model for UI through general interface like extended > Maps and Lists. Add to them methods for sorting, validation, > extracting metadata about associations. We can use these maps and > lists for CRUD templates, but how do maps and lists know about > business layer. In business layer interface there usually may be > several contracts of woking with data. We annotate this layer's > methods with annotations describing what classes to use to deal with > data using this method. I dont get the point, anyway, I'll ask you to take a deeper look at Faces Freeway (an additional developer might be great :-) ) if it allows you to extend it as you need it. I think this might still be good enough for a SoC project.
E.g. the abstraction between the meta-model and the gui is already there. I do not use it only for ejb3 entities, but also for simple beans (for sure, with the help of ejb3 annotations and some custom ff annotations) or for birt reports - yes we extract metadata from them (this birt extractor is not in svn as it is very limited - just what we needed fast). Also the gui builder is abstracted, so in the end you could be able to generate JSF (is there), JSF with MyFaces extensions (is there, e.g. calendar), Swing or whatever. All this is done by using "namespaces". e.g having a jsf component <ff:form uri="ejb:org.to.entity.bean.po"> tell ff to use EjbExtractor and hibernate persistence to manage this po (configureable). If a one-record-page or a entity-list-page should be rendered will be decided by looking for an layout component. e.g. if ff:form has a dataTable child a entity list will be rendered. It is also possible to navigate form an entity-list-page to an detail-page and scroll through the entities on the detail-page too. A framework to create "search pages" is also in place. E.g there is a tag named ff:inputSearch where the component used to build the input control will also be extracted from the model - samples missing here. Also through tags you can override e.g. the component to use and some other aspects (readonly, lenght, .... ) It will be great if we find a community to make ff even better. Ciao, Mario
