16 Aug
2007
16 Aug
'07
9:40 a.m.
Hi,
I updated the xml-rpc implementation on trunk. There are big changes
so be careful when updating since some of the changes are
incompatible.
- all non-string primitive types (like date and int) are now encoded to strings
the easiest to adapt to this is to start using swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
17 Aug
17 Aug
4:39 p.m.
Hi All,
Sorry about the late response. Busy with academic work :(
The patch attached will fix the XMLRPC issue related to XEclipse. Please
verify it and let me know what you think.
I tested XEclipse with this patch and everything is normal now.
Regards,
- Asiri
On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hi,
I updated the xml-rpc implementation on trunk. There are big changes
so be careful when updating since some of the changes are
incompatible.
- all non-string primitive types (like date and int) are now encoded to
strings
the easiest to adapt to this is to start using swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
5:56 p.m.
Hi Asiri,
Why don't you use the space key? It used to be that the title was
always set to this key. If you were setting a title different then the
key then this title was just discarded and the key was returned. That
was not normal.
Now about space titles being empty, this is a possible situation in
XWiki (document titles can also be empty). If you want to treat this
situation differently why not do it on the client side ? And if you
need to use the space key, then just use the space key and forget
about the title.
Regards,
Catalin
On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
Hi All,
Sorry about the late response. Busy with academic work :(
The patch attached will fix the XMLRPC issue related to XEclipse. Please
verify it and let me know what you think.
I tested XEclipse with this patch and everything is normal now.
Regards,
- Asiri
On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hi,
I updated the xml-rpc implementation on trunk. There are big changes
so be careful when updating since some of the changes are
incompatible.
- all non-string primitive types (like date and int) are now encoded to
strings
the easiest to adapt to this is to start using
swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
7:56 p.m.
Hi Catalin and all,
On 8/17/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hi Asiri,
Why don't you use the space key? It used to be that the title was
always set to this key. If you were setting a title different then the
key then this title was just discarded and the key was returned. That
was not normal.
Now about space titles being empty, this is a possible situation in
XWiki (document titles can also be empty). If you want to treat this
situation differently why not do it on the client side ? And if you
need to use the space key, then just use the space key and forget
about the title.
This is the issue, at the beginning of XEclipse, we thought a key was
something that should be used to refer to documents within programs (not
displayed to users) - This is the purpose of a key (a unique identifier). I
think it is necessary we keep this terminology since otherwise we'll violate
the whole purpose of a key (please someone correct me if this is not the
purpose of a key). Now titles on the other hand are what users understand
(what we should display to them) and I think we should not allow them to be
empty - but in case if a title is not available, we can use the key (since
there is no other option).
So in summary, XEclipse was developed with the assumptions,
1. Keys should be used whenever we refer to documents within programs (like
when invoking XMLRPCs).
2. Keys should be mapped into titles (or names) when a document is presented
to a user.
We can change XEclipse to use keys only and forget about titles, but that
will take some more time. And most importantly, this might affect XEclipse
on XWiki 1.1.
Anyway, in my personal opinion, i think it's necessary we keep the
distinction between keys and titles intact.
What do others think ?
Regards,
- Asiri
Regards,
Catalin
On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
Hi All,
Sorry about the late response. Busy with academic work :(
The patch attached will fix the XMLRPC issue related to XEclipse. Please
verify it and let me know what you think.
I tested XEclipse with this patch and everything is normal now.
Regards,
- Asiri
On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
> Hi,
>
> I updated the xml-rpc implementation on trunk. There are big changes
> so be careful when updating since some of the changes are
> incompatible.
> - all non-string primitive types (like date and int) are now encoded
to
strings
the easiest to adapt to this is to start using
swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
8:14 p.m.
Hi Asiri,
On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
Hi Catalin and all,
On 8/17/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Yes, a key does identify a space, but it is not cryptic like the IDs
used in the API (the IDs are numbers in confluence, and opaque strings
in XWiki). You can display a key to an user without problems. So yes,
keys are identifiers, and no keys are not supposed to be hidden from
the user like the PageID, CommentID etc.
Hi Asiri,
Why don't you use the space key? It used to be that the title was
always set to this key. If you were setting a title different then the
key then this title was just discarded and the key was returned. That
was not normal.
Now about space titles being empty, this is a possible situation in
XWiki (document titles can also be empty). If you want to treat this
situation differently why not do it on the client side ? And if you
need to use the space key, then just use the space key and forget
about the title.
This is the issue, at the beginning of XEclipse, we thought a key was
something that should be used to refer to documents within programs (not
displayed to users) - This is the purpose of a key (a unique identifier). I
think it is necessary we keep this terminology since otherwise we'll violate
the whole purpose of a key (please someone correct me if this is not the
purpose of a key).
Now titles on the other hand are what users
understand
(what we should display to them) and I think we should not allow them to be
empty - but in case if a title is not available, we can use the key (since
there is no other option).
Yes, titles (or space names) can be more expressive. In particular
they can contain spaces, be longer etc. In XWiki they are displayed in
a special field on top of the edit box (which btw is empty by
default).
Most important these two properties of a space can be changed
independently, and the value of one should not influence the value of
the other. This is what the current implementation does.
So in summary, XEclipse was developed with the
assumptions,
1. Keys should be used whenever we refer to documents within programs (like
when invoking XMLRPCs).
2. Keys should be mapped into titles (or names) when a document is presented
to a user.
I think you make a major confusion between space keys and IDs. They
are not the same, see above. Your statements here are true only for
IDs not for space keys.
We can change XEclipse to use keys only and forget
about titles, but that
will take some more time. And most importantly, this might affect XEclipse
on XWiki 1.1.
Not true. On XWiki 1.1 the title/name was always equal to the key, so
whenever you thought you were using the title/name you were actually
using the key. Now you would use the key explicitly.
Anyway, in my personal opinion, i think it's
necessary we keep the
distinction between keys and titles intact.
This is exactly what i did. They used to be the same, now there is a
clear distinction between the two.
Regards,
Catalin
On 8/17/07,
Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
> Hi All,
>
> Sorry about the late response. Busy with academic work :(
>
> The patch attached will fix the XMLRPC issue related to XEclipse. Please
> verify it and let me know what you think.
> I tested XEclipse with this patch and everything is normal now.
>
> Regards,
>
> - Asiri
>
>
> On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
> > Hi,
> >
> > I updated the xml-rpc implementation on trunk. There are big changes
> > so be careful when updating since some of the changes are
> > incompatible.
> > - all non-string primitive types (like date and int) are now encoded
to
strings
the easiest to adapt to this is to start using
swizzle which makes the
translation automatic
- the way all identifiers are built has changed
anyway, ids should be treated as opaque handlers, so if you ever find
yourself parsing them then you are doing something wrong.
- the way the page history is different now
only old versions of the page are considered, and they can be accessed
like regular pages
There are other smaller fixes, but these are the most important ones.
Regards,
Catalin
9:48 p.m.
Hi Catalin,
On 8/17/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Hi Asiri,
On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
Isn't the whole point of having a space name / title is to display it
whenever possible ? I mean, if we use space keys in XEclipse, that means
we're not being user friendly - assuming titles are more expressive than
keys.
Hi Catalin and all,
On 8/17/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
identifier). I
Hi Asiri,
Why don't you use the space key? It used to be that the title was
always set to this key. If you were setting a title different then the
key then this title was just discarded and the key was returned. That
was not normal.
Now about space titles being empty, this is a possible situation in
XWiki (document titles can also be empty). If you want to treat this
situation differently why not do it on the client side ? And if you
need to use the space key, then just use the space key and forget
about the title.
This is the issue, at the beginning of XEclipse, we thought a key was
something that should be used to refer to documents within programs (not
displayed to users) - This is the purpose of a key (a unique think it is necessary we keep this terminology
since otherwise we'll
violate
the whole purpose of a key (please someone
correct me if this is not the
purpose of a key).
Yes, a key does identify a space, but it is not cryptic like the IDs
used in the API (the IDs are numbers in confluence, and opaque strings
in XWiki). You can display a key to an user without problems. So yes,
keys are identifiers, and no keys are not supposed to be hidden from
the user like the PageID, CommentID etc. Now titles on the other hand are what users
understand
Agreed.
(what we should display to them) and I think we
should not allow them to
be
empty - but in case if a title is not available,
we can use the key
(since
there is no other option).
Yes, titles (or space names) can be more expressive. In particular
they can contain spaces, be longer etc. In XWiki they are displayed in
a special field on top of the edit box (which btw is empty by
default).
Most important these two properties of a space can be changed
independently, and the value of one should not influence the value of
the other. This is what the current implementation does. So in summary, XEclipse was developed with the
assumptions,
Ok, didn't know about this. The word "key" always brings a cryptic
identifier to my mind....
1. Keys should be used whenever we refer to documents within programs
(like
when invoking XMLRPCs).
2. Keys should be mapped into titles (or names) when a document is
presented
to a user.
I think you make a major confusion between space keys and IDs. They
are not the same, see above. Your statements here are true only for
IDs not for space keys. We can change XEclipse to use keys only and forget
about titles, but that
will take some more time. And most importantly,
this might affect
XEclipse
on XWiki 1.1.
Not true. On XWiki 1.1 the title/name was always equal to the key, so
whenever you thought you were using the title/name you were actually
using the key. Now you would use the key explicitly. Anyway, in my personal opinion, i think it's
necessary we keep the
I too thought of them separately and expected them to be different. Anyway,
with the current scheme, we cannot use space names / titles alone on
XEclipse since some names can be empty (as you said). So now there are three
possibilities,
1. Use space keys only in client (for everything) - Then what is the use
of space names / titles ? <-- have to answer if we are to go with this
option. And this requires XEclipse to be changed.
2. Enforce spaces to have a title (a.k.a not ""). <-- Ideal scenario.
3. Use titles / names whenever they are available and switch to space keys
otherwise - this should be done on server (see my patch). <-- This is
possible since space keys and titles / names can be changed independently.
The only disadvantage of this scheme is that sometimes users get to see a
title / name of a space which is not the actual title (when actual title is
"").
I would go with the third option.
What would you think ?
Regards,
- Asiri
Regards,
distinction between keys and titles intact.
This is exactly what i did. They used to be the same, now there is a
clear distinction between the two. Catalin
> On 8/17/07, Asiri Rathnayake
<asiri.rathnayake(a)gmail.com> wrote:
> > Hi All,
> >
> > Sorry about the late response. Busy with academic work :(
> >
> > The patch attached will fix the XMLRPC issue related to XEclipse.
Please
> > verify it and let me know what you
think.
> > I tested XEclipse with this patch and everything is normal now.
> >
> > Regards,
> >
> > - Asiri
> >
> >
> > On 8/16/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
> > > Hi,
> > >
> > > I updated the xml-rpc implementation on trunk. There are big
changes
> > > so be careful when updating since
some of the changes are
> > > incompatible.
> > > - all non-string primitive types (like date and int) are now
encoded
to
> > strings
> > > the easiest to adapt to this is to start using swizzle which makes
the
> > > translation automatic
> > > - the way all identifiers are built has changed
> > > anyway, ids should be treated as opaque handlers, so if you ever
find
> > > yourself parsing them then you are
doing something wrong.
> > > - the way the page history is different now
> > > only old versions of the page are considered, and they can be
accessed
> > > like regular pages
> > >
> > > There are other smaller fixes, but these are the most important
ones.
>
> Regards,
> Catalin
>
6293
days inactive
6294
days old
5 comments
2 participants
participants (2)
-
Asiri Rathnayake -
Catalin Hritcu