On Tue, May 19, 2009 at 13:57, Anca Paula Luca <[email protected]> wrote:
Thomas Mortagne wrote:
Hi devs,
For 2.0 syntax we make XWikiDocument.display() enclose the result in {{html}}{{/html}} since it's supposed to generate html and that we should not have to use {{html}}{{/html}} in the syntax when we call $doc.display("somefield").
Now the issue is that public api Object and Document get() methods does not return the value but call display. But users (and us) used to access string value using $object.somefield instead of $object.getProperty("somefield").getValue() which is the correct form to access an object field value.
I feel that $object.fieldName is way more natural as $object.getProperty("somefield").getValue() than as $object.display().
Otherwise put, why can't we change getters to return $object.getProperty("somefield").getValue()?
Because if we do that we break all code using $object.fieldName to display the field like most of the code to edit a form in inline mode (like the default content we generate in the class manager in XE). As i said in a previous mail when Thomas raised the issue, i would prefer that $object.fieldName does not call display but whatever the change you make to the API it will break it for users.
Because of this wrong use of display() we have a big change in the api form user point so the question is what do we do ?
I can see the following solution: 1) it's not a real change in the API, user should use the right way. It's ok like that. 2) we "optimize" XWikiDocument.display() by generating {{html}}{{/html}} only when it's necessary (if the result really is html) 2.a) if it contains "<" or ">" 2.b) when it's not a BaseStringProperty/NumberProperty/DateProperty since theses properties does not really need to produce HTML 3) we clean the display result in Object/Document.get by removing the {{html}}{{/html}} when the result does not really contains html (more or less the same way to find it than 2))
WDYT ?
I'm +1 for 2.a) (I don't like b, i think the generic way is better) since i don't think we can "change" the API even if it's not a real change and this solution is not that much a hack, it makes display() return cleaner anyway. 3) as the advantage of fixing only the problematic API but it's really too crappy IMO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne