[xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
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. 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
On May 19, 2009, at 11:40 AM, 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.
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
+1 for 2a. Thanks -Vincent
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 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
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
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
+1 for 2.a) On Tue, May 19, 2009 at 2:04 PM, Thomas Mortagne <[email protected]>wrote:
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
-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://guillaumelerouge.com/
Thomas Mortagne wrote:
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.
but solution 2a doesn't guarantee that it will work as it always worked. If one uses the $object.field expecting _only_ HTML, and the field is indeed html, it will get {{html}}field value{{/html}} instead of just the html field value he wants... If I do: #set($x = "this is a html field: ${obj.field1}") $x will be: this is a html field: {{html}} html field value {{/html}} ? Am I missing something?
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
On Tue, May 19, 2009 at 15:49, Anca Paula Luca <[email protected]> wrote:
Thomas Mortagne wrote:
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.
but solution 2a doesn't guarantee that it will work as it always worked. If one uses the $object.field expecting _only_ HTML, and the field is indeed html, it will get {{html}}field value{{/html}} instead of just the html field value he wants...
If I do:
#set($x = "this is a html field: ${obj.field1}")
$x will be:
this is a html field: {{html}} html field value {{/html}}
?
I don't see why someone would specifically want generated html if it's not to print it, display is supposed to return something to insert in the page and be able to view the field value in good condition which mean it's supposed to take care of escaping anything in the field value that could mean something in html as otherwise it will not be printed correctly obviously, some users wrongly use it to get the field value so we try to not break too much code by "optimizing" display a little but we can't make it perfect, what display() return still need to work in 2.0 syntax. We all agree that this api is not good and this is not THE solution, the solution is to have a proper API which will come with the new model but in the meantime we have to make 1.0 API work as much as possible with 2.0 syntax without breaking anything or as less as possible. If we have html we need the {{html}} macro around it for it to work in 2.0 syntax, we can't do much about it but we can try to make the other use cases behave as user expect this API to behave. The radical solution would be to force user to take care of putting the {{html}} himself depending of what he expect the display() to return and we discussed several time about it and decided that it was too much a pain for user.
Am I missing something?
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
-- Thomas Mortagne
+1 for 2a) Thanks, Marius 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.
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
participants (5)
-
Anca Paula Luca -
Guillaume Lerouge -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol