19 May
2009
19 May
'09
11:40 a.m.
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
19 May
19 May
1:52 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
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
1:57 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:03 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
On Tue, May 19, 2009 at 13:57, Anca Paula Luca <ancapaula.luca(a)xwiki.com> wrote:
--
Thomas Mortagne
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
2:04 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
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
2:12 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
+1 for 2.a)
On Tue, May 19, 2009 at 2:04 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>wrote;wrote:
On Tue, May 19, 2009 at 14:03, Thomas Mortagne
<thomas.mortagne(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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
On Tue, May 19, 2009 at 13:57, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>
wrote:
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
3:49 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
Thomas Mortagne wrote:
--
Thomas Mortagne
On Tue, May 19, 2009 at 14:03, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
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?
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
5:23 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
On Tue, May 19, 2009 at 15:49, Anca Paula Luca <ancapaula.luca(a)xwiki.com> wrote:
Thomas Mortagne wrote:
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.
On Tue, May 19, 2009 at 14:03, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
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}}
? 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:
> 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.
Am I missing something?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
> 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
--
Thomas Mortagne
2:17 p.m.
New subject: [xwiki-devs] [VOTE] What do we do about Object.get() Document.get() "api change"
+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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5602
days inactive
5602
days old
8 comments
5 participants
participants (5)
-
Anca Paula Luca -
Guillaume Lerouge -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol