cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: why JXTG sucks? was: FreeMarker integration
Date Wed, 11 Aug 2004 23:10:03 GMT
Conal Tuohy wrote:
>>-----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)
> 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. 
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.

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                            

View raw message