On Tue, May 19, 2009 at 14:03, Thomas Mortagne
<[email protected]> wrote:
> 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.
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.
>
>>
>>
>>
>>>
>>> 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
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
