There I am trying to elaborate on what I want to have done in summer. Really
I had little time to work on this text. And now I am ill and have a
temperature of 37.6 C :( Not the best state to think about such things. The
full proposal I will compose and send later.
As for Faces Freeway I think the main our difference is templating. I like
that rules for dynamic components creation are just declarative templates.
You may start writing usual xml view definition and when you see similar
patterns you refactor it into templates to follow the DRY principle. That's
how it done in OO-languages like java, but now with declarative comfort.
My project is devided into two parts
1. data access generalization interfaces and implementations
2. flexible templating
They can be used independently.
about templates I've already written in general
1. data access generalization interfaces and implementations
I plan to provide some basic CRUD templates, which will use the data defined
by following requirements:
Data is represented in Maps and Lists. Lists can contain only Maps. Maps in
one List contain one set of keys. Most templates will use additional methods
defined in the next interfaces:
public interface Identifiable {
String getType();
String getId();
}
All maps and lists have type and id. We always can get a list of all maps of
particular type using DataProvider.
additional interfaces for Map:
public interface Abilities {
boolean isEditable(String key);
boolean isReadable(String key);
boolean isCreatable();
Map newInstance();
void save();
Object getSource();
}
newInstance() creates a blank Map that will be binded to form to create new
entity. The save method of that new Map will create a new entity.
public interface WithTypedValues {
String getType(String key);
}
Gets type of fields. Used for choosing representing components.
public interface Validatable {
void validate(K key);
}
Will be used by default validator.
public interface WithRelations {
String getRelationType(String key);
}
additional interface for List:
public interface Sortable {
void sort(K key);
}
Default DataProvider will get your object and wrap it into map/list
implementing these interfaces. Their methods will mostly delegate to other
pluggable objects. For default implementation I plan to use EJB3 annotations
for determining relation types, hibernate validation annotations for
validating and custom annotations for determining methods to use for CRUD
(more on that later).
To show the work done I will implement a sample auction application. Its
entities are User, Item, Category, Bid, Comment with different relations.
Actually usable CRUD view for application can be produced by lines
<su:data var="actualItems" method="#{itemsService.getActualItems}"/>
<su:insert template="dataTable" value="#{actualItems}"/>
Then I will show some steps to refine it.
Links (can be maked bookmarkable) to item details by default point to the
same view, but after clicking it the components for displaying item details
will be dynamically created in place of actualItems dataTable. And if you
need to fully customize the item details page - just create new view
itemDetails and add parameter action="itemDetails" to you links. I am saying
it to show that once you need to scale to use more jsf features you can
easily do it step by step.
What else was I thinking about?
I will implement MethodActionListener to call methods with parameters. I
think that you shouldn't create a backing bean for just delegation simple
method call to save your item or so. And if you need you can switch to call
the method through a backing bean.
<su:data> sets a var to list or map. Then you can navigate by calling get
method on them. But in default implementation actual loading of data is as
lazy as possible, i.e. when you navigate to non-wrapped values. It works
that way because it can be used in two scenarios - getting values or setting
them. And it is unnecessary to load actual data from datasource when we only
use these maps/lists to populate view with components, set some map values
and call save.
About extendability of data interfaces. Suppose you want to filter items by
field values. You can create backing bean of Item class, wrap it with
dataProvider, insert form template for editing it, add button to call filter
method on your service object, insert dataTable template for results.
Without such a framework there would be some more tedious work. But now you
have decided to simplify even more your future work. You can create a
template with filtering included. But what to do with used backing bean and
you filter method? You can extend your List implementation with filter
method (other templates will just work), annotate your service object's
filter methods (as I said more on that later). And you have filter template
with paging and sorting included. In place of former backing bean you can
use Map returned by newInstance.
I write a little chaotic. I hope main line of concepts and implementation
ideas is visible. I am going to sleep now and then try to arrange a
consistent proposal.
Feedback is appreciated. Would you use any of this?
--
View this message in context:
http://www.nabble.com/Re%3A-Summer-of-Code-t1551065.html#a4275003
Sent from the My Faces - Dev forum at Nabble.com.
