Hi Daniel and cocoon folks :)
Leszek Gawron wrote:
- break whole entity tree
How does wrapping data with a renderer touch the model? What entity tree do you mean, actually?
- forget about lazy-loading
If you're pulling from the db each query you have a problem no matter what. God invented RAM for a reason ;)
- fetch data on each level separately
Not sure what you mean? I have a simple recursive walk of a hierarchical menu in my paper that works great.
- prepare some kind of DTOs that would apply "view needs" to data stored in
database
Not sure what you mean. The controller knows the locale and "paints" objects before they are sent to the view.
- build another object graph only for the sake of one view and above all:
Well, you need to store raw data somewhere and then change per locale. There is no way around this. Either you have IFs or you wrap data in a formatter, right?
- change my model every time I change view template
How so? Wrapping a model object does not affect the model.
Perhaps I specific examples perhaps to see your point.
sorry for such delay. A simple example:
public class Contractor {
private String name;
private String description;
private Set projects; //objects of type Project// constructor, getters, setters ommited }
public class Project {
private String name;
private String description;
private Contractor contractor;
private Set tasks; //objects of type Task
}public class Task {
private Calendar start;
private Calendar finish;
private String todo;
}With any mature O/R tool you can do something like:
Contractor c = ormSession.load( Contractor.class, new Long( 1 ) );
passing only this object into view allows the view to access any descendant:
var model = { contractor: c }
cocoon.sendPage( "contractorsProjects", model );same for: cocoon.sendPage( "contractorsProjectsWithTasks", model );
The model is lazy loaded meaning tasks will never load if you do not reference them in your view. Without any change to your controller you can change your view from displaying project list to project -> task list.
Now imagine you want :
* some properties pretty printed (project's description could be
pretty printed). Moreover: the user in his/hers preferences chooses
if he/she wants to pretty print projects' descriptions.
* in some views (only a part of them) some dates rendered red if date
is in past.1. I do not feel like introducing these kinds of methods: Project: public Node getPrettyPrintedDescription(); Task: public boolean hasStartDateExpired(); public Node getStartDateRed(); public boolean hasFinishDateExpired(); public Node getFinishDateRed(); public Node getPrettyPrintedTodo();
2. I also do not feel like implementing some DTOs. DTOs is created with some specific dataset in mind. So in this case DTOs with contractor data and projects data or another DTO with contractor, projects and tasks. Few more classes to implement and hell with view changes.
If you are able to plug rendering logic into the view itself you call your rendering tag/function on the property that you specify. The model is not having this knowledge and that is the cause of the problem.
Is my use case any clearer now?
my regards -- Leszek Gawron [EMAIL PROTECTED] Project Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
