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