The more I think about it the more I think the only possible solution
is 2) but that we should just not modify parseContent() implementation
till we drop the old rendering...
Need to explore more... If you have any idea let me know.
Thanks
-Vincent
On Aug 1, 2008, at 9:30 AM, Vincent Massol wrote:
Hi devs,
I need to take a decision on this. Right now parseContent() is used
to render some text using only Velocity and Groovy renderers. This
is used in several places:
* resource properties values
* TextArea class rendering if the type is "velocitycode"
* in sendValidationEmail() for rendering the content extracted from
an object property
* in the TOC generation for rendering the section titles -- BTW this
means no wiki syntax in section titles right now
* more...
The decision:
1) either I wrap the content passed to parseContent() in {{velocity}}
{{groovy}}{{nowiki}}...{{/nowiki}}{{/groovy}}{{/velocity}}
2) either I render it normally but in this case we change the values
used.
For examples in ApplicationResources.propeties this mean changing:
viewcodetitle=Wiki code for <em>$doc.displayTitle</em>
to:
viewcodetitle=Wiki code for ~~{{velocity}}$doc.displayTitle{{/
velocity}}~~
It also means removing the difference between "velocitycode" and
"fullyrendered" for TextAreas since they would be the same. Would
remain only "puretext" and "fullyrendered". This means that if you
have some TextArea for which you wish velocity rendering but no wiki
syntax rendering you would write: {{velocity}}{{nowiki}}...{{/
nowiki}}{{/velocity}}.
Basically it means deprecating parseContent() in favor of
getRenderedContent() since they would have the same behavior.
My preference goes to 2) but I'm not sure how to make that work
during the transition period where we have the 2 renderings. So I
think we don't have the choice and for the moment we should do 1).
WDYT?
Thanks
-Vincent