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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
