Hi Catalin,
On 8/18/07, Catalin Hritcu <catalin.hritcu(a)gmail.com> wrote:
Asiri,
I would go with 1, or 3 but done on the client instead of wasting time
writing emails. The xml-rpc interface is not only for XEclipse to use
and it will stay as general and clear as possible.
Hmmmm... That sounds like a good idea.
I think we could go with the third option but still on the client
side. And the amount of work to be done would be really less. I
didn't think about this before, thanks.... (still, i need to check
what needs to be changed).
But anyway, I'm waiting for Vincent's confirmation.
I haven't closely followed but Catalin is your man when it comes to
the XMLRPC interface :)
The only thing I'd like is that XEclipse works ASAP with both XWiki
1.1 and trunk so that I can release it (btw I'm on holiday now for 1
week but I'll try to find some time to the XEClipse release).
Thanks!
-Vincent
Catalin
On 8/17/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
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:
> > 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).
> >
> 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.
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.
> > 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.
Agreed.
> > 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.
Ok, didn't know about this. The word "key" always brings a cryptic
identifier to my mind....
> > 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.
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,
> 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
> > >
> >
> >
> >
>