This comes from the application architecture. 2 years ago I would do what you say because my model would be prepared to fit the view exactly. Now I code my persistence in hibernate. As a result of this my model is a graph of entities initialized when needed. I do not have to worry about performance - if my view needs only the most simple data only a few queries will be made. Someday my view will evolve and maybe reference more entities in the model tree.-----Original Message-----
From: Leszek Gawron
My question is: why do you call a wiki parser a "model aspect" if in my example I have to pass it for EVERY model? It looks more like a view plugin really.
Where should you draw the line between model and view?
In the case of JXTG, it is really only convenient if the view (JXT) can access the full structure of the model programmatically. If the model includes structured text, then the model would have to expose that structure programmatically.
For example, I think you have properties (such as your project/description) which contain structured text (in Wiki markup) but are actually just defined as Strings. IMHO the wiki syntax is not an appropriate model for JXT because it is not a _Java_ model but a textual (markup) model.
To present Wiki text in Cocoon, you would normally convert it to XML and then style it as HTML, FO, etc. The first step is parsing (convert to XML infoset, whether a DOM or SAX stream), the second step is presentation. I think the first step should be in the model, the second in the view.
Why should your "project/description" property type be "Wiki-text" rather than "DOM"? A DOM is no more "presentational" than the Wiki-text is it? It's just a way of representing the logical structure of the document.
If I follow what you propose my model would have to covert every wikified string property even if view does not need it. This would be a dramatic loss of performance and SoC:
- lazy loading would be broken
- unnecessary text processing would be involved
- controller would be dependent on my view - I change the view, have to make appropriate changes in model preparation.
Second thing is that my wiki parser (radeox) does not provide any intermediate xml format that should be converted to xml. It exposes simple html tags that I can style with CSS stylesheets. It's enought for me.
The line between model and view is drawn considering:
- the tools you use. If I used plain JDBC I would be more willing to accept your approach. I would find useless to create unnecessary entries in my data model. I would query only for those things that my view would use. I would write lot more lines of code as every view would have to be handled separately. With hibernate I place only a few entities on a root level of my data model but if the view needs it it can query even for half of my database if only it is available via referencing from root level.
- the domain of projects you implement. Looks like your experience comes more from publishing/authoring projects rather web applications that expose a lot of dynamic views and big data model underneath. A data model for me is not DOM, not documents, these are POJO entities mapped from database relations. Any computation that readonly processes those entities for some presentational purposes is view logic - not some model aspect. Model for me is something that lasts. A model property formated as date, number, html markup from wiki text is just a presentation that can be just thrown away without any harm to the model itself. The original property is still there. You can access it and present it any way you wish. You may for example want to present it in two forms on the same page: raw for editing, and pretty printed for WYSIWYG.
If some MVC document tells me to draw my separation line somewhere else so my application becomes:
- more complex
- harder to understand
- less elastic
- harder to scale
and doesn't give me anything in return then I say - burn the document. EJB persistence was also created based on some egghead specification. Then OR frameworks came and suddenly it turned out that something simpler that comes out of real experience works better than EJB ever did. After people saw another possibility to implement functionality with lightweight containers and OR frameworks some of J2EE patterns became anti-patterns in fact.
-- Leszek Gawron [EMAIL PROTECTED]
