You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Richard Frovarp <Ri...@sendit.nodak.edu> on 2007/05/31 06:04:40 UTC
Using UUIDs in the URL
Is there a way to call a page via it's UUID from a browser? My issue is
that we translate from UUIDs to URLs when a page is being edited. If an
object being targeted (image or link) changes path while the page is
being edited, it then becomes lost. Links really don't matter if they
are left as lenya-document as they aren't rendered. However, images need
to be rendered. If there is some way of accessing a document via HTTP
using it's UUID, a pre-processing instruction can be put in to handle
creating those URLs, and things will be good.
I hope this make sense.
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Bob Harner <bo...@gmail.com>.
On 5/31/07, Andreas Hartmann <an...@apache.org> wrote:
> Richard Frovarp schrieb:
> > Is there a way to call a page via it's UUID from a browser? My issue is
> > that we translate from UUIDs to URLs when a page is being edited.
>
> That's a very good point.
>
> > If an
> > object being targeted (image or link) changes path while the page is
> > being edited, it then becomes lost. Links really don't matter if they
> > are left as lenya-document as they aren't rendered. However, images need
> > to be rendered. If there is some way of accessing a document via HTTP
> > using it's UUID, a pre-processing instruction can be put in to handle
> > creating those URLs, and things will be good.
>
> We should certainly introduce such a URL space. It will also be helpful
> for debugging. Should we use a particular prefix, or does the UUID space
> itself provide enough safety from name clashes?
>
> /{pubId}/{area}/{uuid}.png
>
> In theory, this would be sufficient:
>
> - It is very unlikely to have a URL with this syntax which is
> not a UUID.
>
> - If the "natural" URL space uses UUIDs, there is no risk for clashes
> because UUIDs are unique.
>
> The problem is that we'd need to check if a document with this
> UUID exists for each call which matches
>
> /{pubId}/{area}/????????-????-????-????-????????????
>
> to avoid masking the "natural" URL space of the publication.
> Considering this, it might make sense to use a particular prefix, e.g.:
>
> /{pubId}/{area}/lenya-uuid/{uuid}.png
>
> WDYT?
>
> -- Andreas
>
>
> --
> Andreas Hartmann, CTO
> BeCompany GmbH
> http://www.becompany.ch
I think using a prefix should result in simpler xmaps and with reduced
dependencies on the particular UUID implementation. (I don't like the
idea of matching on a ????????-????-????-????-???????????? pattern, it
seems hacky somehow.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> Bob Harner wrote:
>> On 5/31/07, Richard Frovarp <Ri...@sendit.nodak.edu> wrote:
>>> Andreas Hartmann wrote:
>>> > Richard Frovarp schrieb:
>>> >
>>> >> Is there a way to call a page via it's UUID from a browser? My
>>> issue is
>>> >> that we translate from UUIDs to URLs when a page is being edited.
>>> >>
>>> >
>>> > That's a very good point.
>>> >
>>> >
>>> >> If an
>>> >> object being targeted (image or link) changes path while the page is
>>> >> being edited, it then becomes lost. Links really don't matter if they
>>> >> are left as lenya-document as they aren't rendered. However,
>>> images need
>>> >> to be rendered. If there is some way of accessing a document via HTTP
>>> >> using it's UUID, a pre-processing instruction can be put in to handle
>>> >> creating those URLs, and things will be good.
>>> >>
>>> >
>>> > We should certainly introduce such a URL space. It will also be
>>> helpful
>>> > for debugging. Should we use a particular prefix, or does the UUID
>>> space
>>> > itself provide enough safety from name clashes?
>>> >
>>> > /{pubId}/{area}/{uuid}.png
>>> >
>>> > In theory, this would be sufficient:
>>> >
>>> > - It is very unlikely to have a URL with this syntax which is
>>> > not a UUID.
>>> >
>>> > - If the "natural" URL space uses UUIDs, there is no risk for clashes
>>> > because UUIDs are unique.
>>> >
>>> > The problem is that we'd need to check if a document with this
>>> > UUID exists for each call which matches
>>> >
>>> > /{pubId}/{area}/????????-????-????-????-????????????
>>> >
>>> > to avoid masking the "natural" URL space of the publication.
>>> > Considering this, it might make sense to use a particular prefix,
>>> e.g.:
>>> >
>>> > /{pubId}/{area}/lenya-uuid/{uuid}.png
>>> >
>>> > WDYT?
>>> >
>>> > -- Andreas
>>> >
>>> >
>>> >
>>>
>>> I think /{pudId}/{area}/lenya-uuid/{uuid} would be preferable. I don't
>>> think that the extension is necessary. If the extension is left off, the
>>> necessary manipulations can be done by XSLT alone.
>>
>> If we do decide to use a prefix, I wonder if we should maybe use
>> :lenya-document" instead of "lenya-uid". As
>> http://lenya.apache.org/docs/1_4/reference/link-management.html
>> describes, the lenya-document protocol allows you to retrieve a
>> document using its UUID, albeit in a pipeline, not an external URL.
>> But the two concepts are so similar that the use of the same word
>> ("lenya-document") seems to me like a good idea. This might also
>> allow us to unify the documentation on these two concepts. Just a
>> thought.
>
> Good point.
+1
--
Jörn Nettingsmeier
Kurt is up in heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Bob Harner wrote:
> On 5/31/07, Richard Frovarp <Ri...@sendit.nodak.edu> wrote:
>> Andreas Hartmann wrote:
>> > Richard Frovarp schrieb:
>> >
>> >> Is there a way to call a page via it's UUID from a browser? My
>> issue is
>> >> that we translate from UUIDs to URLs when a page is being edited.
>> >>
>> >
>> > That's a very good point.
>> >
>> >
>> >> If an
>> >> object being targeted (image or link) changes path while the page is
>> >> being edited, it then becomes lost. Links really don't matter if they
>> >> are left as lenya-document as they aren't rendered. However,
>> images need
>> >> to be rendered. If there is some way of accessing a document via HTTP
>> >> using it's UUID, a pre-processing instruction can be put in to handle
>> >> creating those URLs, and things will be good.
>> >>
>> >
>> > We should certainly introduce such a URL space. It will also be
>> helpful
>> > for debugging. Should we use a particular prefix, or does the UUID
>> space
>> > itself provide enough safety from name clashes?
>> >
>> > /{pubId}/{area}/{uuid}.png
>> >
>> > In theory, this would be sufficient:
>> >
>> > - It is very unlikely to have a URL with this syntax which is
>> > not a UUID.
>> >
>> > - If the "natural" URL space uses UUIDs, there is no risk for clashes
>> > because UUIDs are unique.
>> >
>> > The problem is that we'd need to check if a document with this
>> > UUID exists for each call which matches
>> >
>> > /{pubId}/{area}/????????-????-????-????-????????????
>> >
>> > to avoid masking the "natural" URL space of the publication.
>> > Considering this, it might make sense to use a particular prefix,
>> e.g.:
>> >
>> > /{pubId}/{area}/lenya-uuid/{uuid}.png
>> >
>> > WDYT?
>> >
>> > -- Andreas
>> >
>> >
>> >
>>
>> I think /{pudId}/{area}/lenya-uuid/{uuid} would be preferable. I don't
>> think that the extension is necessary. If the extension is left off, the
>> necessary manipulations can be done by XSLT alone.
>
> If we do decide to use a prefix, I wonder if we should maybe use
> :lenya-document" instead of "lenya-uid". As
> http://lenya.apache.org/docs/1_4/reference/link-management.html
> describes, the lenya-document protocol allows you to retrieve a
> document using its UUID, albeit in a pipeline, not an external URL.
> But the two concepts are so similar that the use of the same word
> ("lenya-document") seems to me like a good idea. This might also
> allow us to unify the documentation on these two concepts. Just a
> thought.
Good point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Bob Harner <bo...@gmail.com>.
On 5/31/07, Richard Frovarp <Ri...@sendit.nodak.edu> wrote:
> Andreas Hartmann wrote:
> > Richard Frovarp schrieb:
> >
> >> Is there a way to call a page via it's UUID from a browser? My issue is
> >> that we translate from UUIDs to URLs when a page is being edited.
> >>
> >
> > That's a very good point.
> >
> >
> >> If an
> >> object being targeted (image or link) changes path while the page is
> >> being edited, it then becomes lost. Links really don't matter if they
> >> are left as lenya-document as they aren't rendered. However, images need
> >> to be rendered. If there is some way of accessing a document via HTTP
> >> using it's UUID, a pre-processing instruction can be put in to handle
> >> creating those URLs, and things will be good.
> >>
> >
> > We should certainly introduce such a URL space. It will also be helpful
> > for debugging. Should we use a particular prefix, or does the UUID space
> > itself provide enough safety from name clashes?
> >
> > /{pubId}/{area}/{uuid}.png
> >
> > In theory, this would be sufficient:
> >
> > - It is very unlikely to have a URL with this syntax which is
> > not a UUID.
> >
> > - If the "natural" URL space uses UUIDs, there is no risk for clashes
> > because UUIDs are unique.
> >
> > The problem is that we'd need to check if a document with this
> > UUID exists for each call which matches
> >
> > /{pubId}/{area}/????????-????-????-????-????????????
> >
> > to avoid masking the "natural" URL space of the publication.
> > Considering this, it might make sense to use a particular prefix, e.g.:
> >
> > /{pubId}/{area}/lenya-uuid/{uuid}.png
> >
> > WDYT?
> >
> > -- Andreas
> >
> >
> >
>
> I think /{pudId}/{area}/lenya-uuid/{uuid} would be preferable. I don't
> think that the extension is necessary. If the extension is left off, the
> necessary manipulations can be done by XSLT alone.
If we do decide to use a prefix, I wonder if we should maybe use
:lenya-document" instead of "lenya-uid". As
http://lenya.apache.org/docs/1_4/reference/link-management.html
describes, the lenya-document protocol allows you to retrieve a
document using its UUID, albeit in a pipeline, not an external URL.
But the two concepts are so similar that the use of the same word
("lenya-document") seems to me like a good idea. This might also
allow us to unify the documentation on these two concepts. Just a
thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Andreas Hartmann wrote:
> Richard Frovarp schrieb:
>
>> Is there a way to call a page via it's UUID from a browser? My issue is
>> that we translate from UUIDs to URLs when a page is being edited.
>>
>
> That's a very good point.
>
>
>> If an
>> object being targeted (image or link) changes path while the page is
>> being edited, it then becomes lost. Links really don't matter if they
>> are left as lenya-document as they aren't rendered. However, images need
>> to be rendered. If there is some way of accessing a document via HTTP
>> using it's UUID, a pre-processing instruction can be put in to handle
>> creating those URLs, and things will be good.
>>
>
> We should certainly introduce such a URL space. It will also be helpful
> for debugging. Should we use a particular prefix, or does the UUID space
> itself provide enough safety from name clashes?
>
> /{pubId}/{area}/{uuid}.png
>
> In theory, this would be sufficient:
>
> - It is very unlikely to have a URL with this syntax which is
> not a UUID.
>
> - If the "natural" URL space uses UUIDs, there is no risk for clashes
> because UUIDs are unique.
>
> The problem is that we'd need to check if a document with this
> UUID exists for each call which matches
>
> /{pubId}/{area}/????????-????-????-????-????????????
>
> to avoid masking the "natural" URL space of the publication.
> Considering this, it might make sense to use a particular prefix, e.g.:
>
> /{pubId}/{area}/lenya-uuid/{uuid}.png
>
> WDYT?
>
> -- Andreas
>
>
>
I think /{pudId}/{area}/lenya-uuid/{uuid} would be preferable. I don't
think that the extension is necessary. If the extension is left off, the
necessary manipulations can be done by XSLT alone.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Bob Harner <bo...@gmail.com>.
On 6/7/07, solprovider@apache.org <so...@apache.org> wrote:
> On 6/7/07, Richard Frovarp <Ri...@sendit.nodak.edu> wrote:
> > solprovider@apache.org wrote:
> > > On 5/31/07, Andreas Hartmann <an...@apache.org> wrote:
> > >> Richard Frovarp schrieb:
> > >> > Is there a way to call a page via it's UUID from a browser? My
> > >> issue is
> > >> > that we translate from UUIDs to URLs when a page is being edited.
> > >>
> > > This feature was implemented in 1.3. The design used one protocol
> > > (cleverly named "content:") for access to all documents and resources.
> > > The protocol finds the resource by testing a variety of formats
> > > including the UUID. (UUIDs are strictly formatted UNIDs.) See the
> > > second half of 13HELP for the specs:
> > > http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/13HELP.txt
> > >
> > >
> > > XMAPs can just pass the resource identifier portion of the URL to the
> > > protocol and retrieve the correct resource. That avoids issues about
> > > needing a special prefix. The protocol works fine internally so no
> > > other code cares whether the identifier is a path or UNID.
> > >
> > > Links should always be stored as UNIDs. Editors must translate
> > > path-based identifiers to UNIDs before storing documents. The "Add
> > > link" and "Add image" functions should display resource titles to hide
> > > UNIDs from users.
> > >
> > > solprovider
> >
> > There is a protocol in 1.4, lenya-document. I want to use HTTP(S) and
> > provide the UUID. Upon save, the path-based identifiers are converted to
> > UUIDs for storage. Links really don't matter too much as they are links
> > and render properly if their URL is of the lenya-document protocol.
> > Images however, currently have to be translated from UUID to path-based
> > when the page is loaded into the editor, so that they display. When
> > saved out they are converted back to UUID. The problem here is if the
> > image is moved (or anything referenced by a path inside of Lenya) while
> > a page referencing it is being edited, the reference could be lost. This
> > is what I hope to prevent from happening.
> >
> > How do you handle displaying images in the editors?
> >
> > Richard
>
> I was working on integrating an editor when I went on sabbatical. I
> was hacking Kupu and finally realized Kupu was not designed for
> flexibility. I will return to the 1.3 in mid-August and integrating
> an editor is the highest priority.
>
> Importing a new image from the editor creates a new resource and places an
> <img src="/pub/unid.ext"/>
> in the document. That is translated to
> <LLINK TAG="img" UNID="unid" {other atributes}/>
> upon saving. Other links are handeled similarly:
> <LLINK TAG="a" UNID="unid" {other atributes}/>
> These tags are translated back to a browser-readable path when
> retrieving the document for any purpose.
>
> 1.3 distinguishes between three basic resource types: XML, text, and
> binary. XML resources are usually called documents. Text resources
> will allow browser editing of CSS, JS, and other configuration files.
> (1.3.1 will move almost everything into the datastore.) Binary
> resources can only be displayed (at least with the current plans.)
> Extensions are handled so a binary resource named "logo" can easily be
> changed from a GIF to a JPG to a PNG without updating any documents.
>
> I return to developing Lenya in August. I do not want to continue
> with Kupu. We used Fckeditor at my job, and it should work. Is there
> a list of Apache-approved editors?
By "Apache-approved" do you mean compatible with the Apache license?
kupu and bxe are the only ones I know of. FCKeditor and TinyMCE are
both unfortunately LGPL (although the latter will apparently
re-license for a fee --
http://wiki.moxiecode.com/index.php/TinyMCE:FAQ#I_don.27t_like_LGPL.2C_is_there_a_commercial_license_available_for_me.3F).
I've looked pretty hard and haven't found anything else of quality
that is cross-browser compatible and Apache-license-compatible. Maybe
FCKeditor or TinyMCE will eventually adopt GPLv3
(http://uk.news.yahoo.com/cwire/20070605/ttc-fsf-announces-gpl-apache-license-com-78e70a2.html)
and then we can possibly consider bundling one with Lenya.
>
> solprovider
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by so...@apache.org.
On 6/7/07, Richard Frovarp <Ri...@sendit.nodak.edu> wrote:
> solprovider@apache.org wrote:
> > On 5/31/07, Andreas Hartmann <an...@apache.org> wrote:
> >> Richard Frovarp schrieb:
> >> > Is there a way to call a page via it's UUID from a browser? My
> >> issue is
> >> > that we translate from UUIDs to URLs when a page is being edited.
> >>
> > This feature was implemented in 1.3. The design used one protocol
> > (cleverly named "content:") for access to all documents and resources.
> > The protocol finds the resource by testing a variety of formats
> > including the UUID. (UUIDs are strictly formatted UNIDs.) See the
> > second half of 13HELP for the specs:
> > http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/13HELP.txt
> >
> >
> > XMAPs can just pass the resource identifier portion of the URL to the
> > protocol and retrieve the correct resource. That avoids issues about
> > needing a special prefix. The protocol works fine internally so no
> > other code cares whether the identifier is a path or UNID.
> >
> > Links should always be stored as UNIDs. Editors must translate
> > path-based identifiers to UNIDs before storing documents. The "Add
> > link" and "Add image" functions should display resource titles to hide
> > UNIDs from users.
> >
> > solprovider
>
> There is a protocol in 1.4, lenya-document. I want to use HTTP(S) and
> provide the UUID. Upon save, the path-based identifiers are converted to
> UUIDs for storage. Links really don't matter too much as they are links
> and render properly if their URL is of the lenya-document protocol.
> Images however, currently have to be translated from UUID to path-based
> when the page is loaded into the editor, so that they display. When
> saved out they are converted back to UUID. The problem here is if the
> image is moved (or anything referenced by a path inside of Lenya) while
> a page referencing it is being edited, the reference could be lost. This
> is what I hope to prevent from happening.
>
> How do you handle displaying images in the editors?
>
> Richard
I was working on integrating an editor when I went on sabbatical. I
was hacking Kupu and finally realized Kupu was not designed for
flexibility. I will return to the 1.3 in mid-August and integrating
an editor is the highest priority.
Importing a new image from the editor creates a new resource and places an
<img src="/pub/unid.ext"/>
in the document. That is translated to
<LLINK TAG="img" UNID="unid" {other atributes}/>
upon saving. Other links are handeled similarly:
<LLINK TAG="a" UNID="unid" {other atributes}/>
These tags are translated back to a browser-readable path when
retrieving the document for any purpose.
1.3 distinguishes between three basic resource types: XML, text, and
binary. XML resources are usually called documents. Text resources
will allow browser editing of CSS, JS, and other configuration files.
(1.3.1 will move almost everything into the datastore.) Binary
resources can only be displayed (at least with the current plans.)
Extensions are handled so a binary resource named "logo" can easily be
changed from a GIF to a JPG to a PNG without updating any documents.
I return to developing Lenya in August. I do not want to continue
with Kupu. We used Fckeditor at my job, and it should work. Is there
a list of Apache-approved editors?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
solprovider@apache.org wrote:
> On 5/31/07, Andreas Hartmann <an...@apache.org> wrote:
>> Richard Frovarp schrieb:
>> > Is there a way to call a page via it's UUID from a browser? My
>> issue is
>> > that we translate from UUIDs to URLs when a page is being edited.
>>
>> That's a very good point.
>>
>> > If an
>> > object being targeted (image or link) changes path while the page is
>> > being edited, it then becomes lost. Links really don't matter if they
>> > are left as lenya-document as they aren't rendered. However, images
>> need
>> > to be rendered. If there is some way of accessing a document via HTTP
>> > using it's UUID, a pre-processing instruction can be put in to handle
>> > creating those URLs, and things will be good.
>>
>> We should certainly introduce such a URL space. It will also be helpful
>> for debugging. Should we use a particular prefix, or does the UUID space
>> itself provide enough safety from name clashes?
>> /{pubId}/{area}/{uuid}.png
>>
>> In theory, this would be sufficient:
>> - It is very unlikely to have a URL with this syntax which is
>> not a UUID.
>> - If the "natural" URL space uses UUIDs, there is no risk for clashes
>> because UUIDs are unique.
>>
>> The problem is that we'd need to check if a document with this
>> UUID exists for each call which matches
>> /{pubId}/{area}/????????-????-????-????-????????????
>> to avoid masking the "natural" URL space of the publication.
>> Considering this, it might make sense to use a particular prefix, e.g.:
>> /{pubId}/{area}/lenya-uuid/{uuid}.png
>>
>> WDYT?
>> -- Andreas
>
>
> This feature was implemented in 1.3. The design used one protocol
> (cleverly named "content:") for access to all documents and resources.
> The protocol finds the resource by testing a variety of formats
> including the UUID. (UUIDs are strictly formatted UNIDs.) See the
> second half of 13HELP for the specs:
> http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/13HELP.txt
>
>
> XMAPs can just pass the resource identifier portion of the URL to the
> protocol and retrieve the correct resource. That avoids issues about
> needing a special prefix. The protocol works fine internally so no
> other code cares whether the identifier is a path or UNID.
>
> Links should always be stored as UNIDs. Editors must translate
> path-based identifiers to UNIDs before storing documents. The "Add
> link" and "Add image" functions should display resource titles to hide
> UNIDs from users.
>
> solprovider
There is a protocol in 1.4, lenya-document. I want to use HTTP(S) and
provide the UUID. Upon save, the path-based identifiers are converted to
UUIDs for storage. Links really don't matter too much as they are links
and render properly if their URL is of the lenya-document protocol.
Images however, currently have to be translated from UUID to path-based
when the page is loaded into the editor, so that they display. When
saved out they are converted back to UUID. The problem here is if the
image is moved (or anything referenced by a path inside of Lenya) while
a page referencing it is being edited, the reference could be lost. This
is what I hope to prevent from happening.
How do you handle displaying images in the editors?
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by so...@apache.org.
On 5/31/07, Andreas Hartmann <an...@apache.org> wrote:
> Richard Frovarp schrieb:
> > Is there a way to call a page via it's UUID from a browser? My issue is
> > that we translate from UUIDs to URLs when a page is being edited.
>
> That's a very good point.
>
> > If an
> > object being targeted (image or link) changes path while the page is
> > being edited, it then becomes lost. Links really don't matter if they
> > are left as lenya-document as they aren't rendered. However, images need
> > to be rendered. If there is some way of accessing a document via HTTP
> > using it's UUID, a pre-processing instruction can be put in to handle
> > creating those URLs, and things will be good.
>
> We should certainly introduce such a URL space. It will also be helpful
> for debugging. Should we use a particular prefix, or does the UUID space
> itself provide enough safety from name clashes?
> /{pubId}/{area}/{uuid}.png
>
> In theory, this would be sufficient:
> - It is very unlikely to have a URL with this syntax which is
> not a UUID.
> - If the "natural" URL space uses UUIDs, there is no risk for clashes
> because UUIDs are unique.
>
> The problem is that we'd need to check if a document with this
> UUID exists for each call which matches
> /{pubId}/{area}/????????-????-????-????-????????????
> to avoid masking the "natural" URL space of the publication.
> Considering this, it might make sense to use a particular prefix, e.g.:
> /{pubId}/{area}/lenya-uuid/{uuid}.png
>
> WDYT?
> -- Andreas
This feature was implemented in 1.3. The design used one protocol
(cleverly named "content:") for access to all documents and resources.
The protocol finds the resource by testing a variety of formats
including the UUID. (UUIDs are strictly formatted UNIDs.) See the
second half of 13HELP for the specs:
http://svn.apache.org/repos/asf/lenya/branches/revolution/1.3.x/13HELP.txt
XMAPs can just pass the resource identifier portion of the URL to the
protocol and retrieve the correct resource. That avoids issues about
needing a special prefix. The protocol works fine internally so no
other code cares whether the identifier is a path or UNID.
Links should always be stored as UNIDs. Editors must translate
path-based identifiers to UNIDs before storing documents. The "Add
link" and "Add image" functions should display resource titles to hide
UNIDs from users.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Using UUIDs in the URL
Posted by Andreas Hartmann <an...@apache.org>.
Richard Frovarp schrieb:
> Is there a way to call a page via it's UUID from a browser? My issue is
> that we translate from UUIDs to URLs when a page is being edited.
That's a very good point.
> If an
> object being targeted (image or link) changes path while the page is
> being edited, it then becomes lost. Links really don't matter if they
> are left as lenya-document as they aren't rendered. However, images need
> to be rendered. If there is some way of accessing a document via HTTP
> using it's UUID, a pre-processing instruction can be put in to handle
> creating those URLs, and things will be good.
We should certainly introduce such a URL space. It will also be helpful
for debugging. Should we use a particular prefix, or does the UUID space
itself provide enough safety from name clashes?
/{pubId}/{area}/{uuid}.png
In theory, this would be sufficient:
- It is very unlikely to have a URL with this syntax which is
not a UUID.
- If the "natural" URL space uses UUIDs, there is no risk for clashes
because UUIDs are unique.
The problem is that we'd need to check if a document with this
UUID exists for each call which matches
/{pubId}/{area}/????????-????-????-????-????????????
to avoid masking the "natural" URL space of the publication.
Considering this, it might make sense to use a particular prefix, e.g.:
/{pubId}/{area}/lenya-uuid/{uuid}.png
WDYT?
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org