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 08:00:54 GMT
Conal Tuohy wrote:
>>-----Original Message-----
>>From: Leszek Gawron []
>>assume you have a collection of Projects. Each project has a 
>>project.description property. This property contains a string 
>>that can 
>>be parsed by a wiki parser and generate html out of it. How would you 
>>implement that. Assume that your controller does NOT know what string 
>>properties should be wikified as there are hundreds of this kind of 
>>properties and you also have several orthogonal views which query 
>>different model parts.
> I think the idea is that your Java model should present these rich text properties in
an already-parsed form. Strictly speaking, you shouldn't have to _parse_ your Java model -
just _access_ it. This avoids computations in the view layer. If these properties have internal
structure relevant to the view, then the properties should be structured in the model (e.g.a
DOM or some kind of graph of Java beans, not just a String). That's the idea, anyway ... so
proponents of JXTG would tell you to add the parser to your model, not to the view templates.
Otherwise, you would be introducing aspects of your model into the view layer. 
I do not mean _parsing_, I mean _presenting in formatted way_. Same 
functionality as for jx:formatDate or jx:formatNumber. It is obvious 
that you will not preformat every date in your data model before view 
rendering. Maybe the problem is not such great when you build up your 
model out of primitives. But if you have a model tree that is build up 
automatically (like in hibernate).

> I agree with Joerg that JXTG is already too powerful. Adding extra parsers etc to it
may end up turning it into XSP. 
It is one big difference: you are not able to embed code in JXTG (but 
you are able to call any java method which I consider harmful).

> As a practical suggestion, maybe you could instantiate a Wiki-parser in the controller
script, and pass it to the view template, as another aspect of the model. 
It is really a pain in the ass to pass the wiki parser with every data 
model in every flowscript function. Error prone at least. In my 
applications basing on cocoon and hibernate this is my usual approach.

- as the model is not flat (hibernate gives me model graph really) I 
never assume which properties on which model level will be needed. Example:

class Project {}

class Task { private Project project; }

class Activity ( private Task task; }

having a showTaskDetails.jx template could reach only Activity object 
but as well reach up to project. The activity might have also some kind 
of collection of another entities that will be lazily loaded when I 
reference it.

- my entities CANNOT expose any formatting properties. This is something 
I learned from C++ previously: if you have some functionality that is 
orthogonal to class itself (like formatting, filling from external 
source, converting to xml, yada yada yada) never place it in your class 
but build a functor.

- if I cannot assume anything about the model (except the fact that in 
my example I have to pass the activity object to the view) I really do 
not know if my view will need to perform any data manipulation for 
presentational purposes. So I do not know what formatters will be used.

- I end up inserting a wiki parser in user session and referencing it in 
jx template via:
${cocoon.session.wikify( activity.task.project.description, 
cocoon.consumer) }
Same for any other formatter or presentational macro (like link decorator)

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.

I think that as long as my computations on view are read only and the 
results are presentational purpose only I do not break any concern.

How should I do that if my approach is wrong?

Leszek Gawron                            
Chief Technology Officer                           MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message