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).-----Original Message----- From: Leszek Gawron [mailto:[EMAIL PROTECTED]
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.
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).
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 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 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.
- 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 [EMAIL PROTECTED] Chief Technology Officer 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
