19 May
2009
19 May
'09
2:04 p.m.
On Tue, May 19, 2009 at 14:03, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
--
Thomas Mortagne
On Tue, May 19, 2009 at 13:57, Anca Paula Luca
<ancapaula.luca(a)xwiki.com> wrote:
The only thing we can do is keep the old model working as it always
worked and take care of all theses problems found for the new model.
Thomas Mortagne wrote:
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. 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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs