You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/03/09 14:25:09 UTC
Include file extension in document ID / meta data?
Hi Lenya devs,
I suggested to allow custom DocumentIdToPathMappers for resource types,
but this isn't sufficient for the following reason:
Resource types should be able to support different file extensions.
(resource type "image" could support .gif, .png, .jpg, .bmp, ...)
Correct me if I'm wrong, but this would mean that only the document
(or asset, resp.) itself may know about its extension. This could
be solved in at least two ways:
1) add the extension to the document identifier
/foo/bar.xml
/hello/world.png
2) add the extension to the meta data
IMO option (1) is not really useful, because it would require to
add the file extension to the URL. This is fine for images etc.,
but rather unusual for XML files (which are typically rendered
as (X)HTML).
How about adding the extension to the meta data?
WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[heads-up] Change to DocumentIdToPathMapper interface (was: Re: Include
file extension in document ID / meta data?)
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Andreas Hartmann wrote:
>> Hi Lenya devs,
>>
>> I suggested to allow custom DocumentIdToPathMappers for resource types,
>> but this isn't sufficient for the following reason:
>>
>> Resource types should be able to support different file extensions.
>> (resource type "image" could support .gif, .png, .jpg, .bmp, ...)
>>
>> Correct me if I'm wrong, but this would mean that only the document
>> (or asset, resp.) itself may know about its extension. This could
>> be solved in at least two ways:
>>
>> 1) add the extension to the document identifier
>>
>> /foo/bar.xml
>> /hello/world.png
>>
>> 2) add the extension to the meta data
>
> I implemented this option, but in a not very nice way
> to avoid content migration.
BTW, this required a change to the DocumentIdToPathMapper.
If you have implemented a custom mapper class, you have to
update it:
- String getPath(String documentId, String language);
+ String getPath(String documentId, String language, String extension);
- File getFile(Publication publication, String area, String documentId,
- String language);
+ File getFile(Publication publication, String area, String documentId,
+ String language, String extension);
Sorry for the inconvenience,
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Include file extension in document ID / meta data?
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> I suggested to allow custom DocumentIdToPathMappers for resource types,
> but this isn't sufficient for the following reason:
>
> Resource types should be able to support different file extensions.
> (resource type "image" could support .gif, .png, .jpg, .bmp, ...)
>
> Correct me if I'm wrong, but this would mean that only the document
> (or asset, resp.) itself may know about its extension. This could
> be solved in at least two ways:
>
> 1) add the extension to the document identifier
>
> /foo/bar.xml
> /hello/world.png
>
> 2) add the extension to the meta data
I implemented this option, but in a not very nice way
to avoid content migration.
The meta data source URI is now calculated in
DefaultDocument.getMetaDataManager(), mimicking the behavior
of the DefaultDocumentIdToPathMapper:
String sourceUri = getPublication().getSourceURI() + "/content/" + getArea()
+ getId() + "/index_" + getLanguage() + ".xml";
source = (RepositorySource) resolver.resolveURI(sourceUri);
this.metaDataManager = source.getNode().getMetaDataManager();
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Include file extension in document ID / meta data?
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
>>> Anyway, I am as well happy to store the extension in the meta data. The
>>> only problem is something like:
>>> /hello/world.png
>>> /hello/world.pdf
>>> /hello/world.wav
>>> ...
>>>
>>> Would you then store all this extension in the meta?
>> This is currently not allowed. You can't have multiple documents
>> with the same document ID.
>
> means that I would need to call them:
> /hello/world-png
> /hello/world-pdf
> ...
>
> That is the reason why I think 1) is better then 2). Here we have unique
> ids.
If you use the whole request to determine the document ID, you have
to add another suffix for different presentation options:
/hello/world.xml.html
/hello/world.xml.pdf
>
>>> Further how would you request e.g. /hello/world.pdf?
>> /hello/world.pdf
>
> internal or http//
http://
>> At the moment, the suffix is not relevant for determining the document.
>>
>>> Do you want to pass the extension as param?
>> The extension is only used for presentation.
>>
>> Both URLs
>>
>> /hello/world.pdf
>> /hello/world.html
>>
>> would point to the same document.
>> The URL suffix is used to render it as PDF or HTML, respectively.
>
> Well not 100% true, you could store pdf and html that are not coming
> from lenya and should not edit with lenya. Like pdf and html assets that
> are not based on a xml. Look at the odt module.
ATM this is not supported. An exception would be thrown if you try
to add multiple documents with the same ID.
>>> Or do you want to keep the meta like:
>>> /hello/world.wav.meta
>> No, because we don't know about the ".wav" when we access the meta data :)
>>
>
> hmm I still not have it clear, sorry.
The meta data source URI is based on the document source URI which
contains the extension (.wav):
/foo/bar/index_en.wav
/foo/bar/index_en.wav.meta
You couldn't build the .meta URI without knowing the ".wav", which
can only be determined by reading the meta data :)
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Include file extension in document ID / meta data?
Posted by Thorsten Scherler <th...@wyona.com>.
El jue, 09-03-2006 a las 16:14 +0100, Andreas Hartmann escribió:
> Thorsten Scherler wrote:
> > El jue, 09-03-2006 a las 14:25 +0100, Andreas Hartmann escribió:
> >> Hi Lenya devs,
> >>
> >> I suggested to allow custom DocumentIdToPathMappers for resource types,
> >> but this isn't sufficient for the following reason:
> >>
> >> Resource types should be able to support different file extensions.
> >> (resource type "image" could support .gif, .png, .jpg, .bmp, ...)
> >>
> >> Correct me if I'm wrong, but this would mean that only the document
> >> (or asset, resp.) itself may know about its extension. This could
> >> be solved in at least two ways:
> >>
> >> 1) add the extension to the document identifier
> >>
> >> /foo/bar.xml
> >> /hello/world.png
> >>
> >> 2) add the extension to the meta data
> >>
> >> IMO option (1) is not really useful, because it would require to
> >> add the file extension to the URL. This is fine for images etc.,
> >> but rather unusual for XML files (which are typically rendered
> >> as (X)HTML).
> >>
> >> How about adding the extension to the meta data?
> >
> >
> > Well to the down sides of 1) I am not sure. The biggest limitation ATM
> > in lenya is exactly the fact that we tend to treat xml (xhtml) different
> > from the rest. What you call unusual I call normal. ;)
>
> Hmm, maybe we're talking about different things ...
> I mean http://foo.bar.com/hello.xml is a unusual URL for an HTML page.
hmm, that is the request, but we are talking about internal mappings. I
agree that it would need to be http://foo.bar.com/hello.html but the
underlying internal mapping would request /hello.xml.
Two different pairs of shoes. ;)
>
> > Anyway, I am as well happy to store the extension in the meta data. The
> > only problem is something like:
> > /hello/world.png
> > /hello/world.pdf
> > /hello/world.wav
> > ...
> >
> > Would you then store all this extension in the meta?
>
> This is currently not allowed. You can't have multiple documents
> with the same document ID.
means that I would need to call them:
/hello/world-png
/hello/world-pdf
...
That is the reason why I think 1) is better then 2). Here we have unique
ids.
>
> > Further how would you request e.g. /hello/world.pdf?
>
> /hello/world.pdf
internal or http//
>
> At the moment, the suffix is not relevant for determining the document.
>
> > Do you want to pass the extension as param?
>
> The extension is only used for presentation.
>
> Both URLs
>
> /hello/world.pdf
> /hello/world.html
>
> would point to the same document.
> The URL suffix is used to render it as PDF or HTML, respectively.
Well not 100% true, you could store pdf and html that are not coming
from lenya and should not edit with lenya. Like pdf and html assets that
are not based on a xml. Look at the odt module.
>
>
> > Or do you want to keep the meta like:
> > /hello/world.wav.meta
>
> No, because we don't know about the ".wav" when we access the meta data :)
>
hmm I still not have it clear, sorry.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Include file extension in document ID / meta data?
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> El jue, 09-03-2006 a las 14:25 +0100, Andreas Hartmann escribió:
>> Hi Lenya devs,
>>
>> I suggested to allow custom DocumentIdToPathMappers for resource types,
>> but this isn't sufficient for the following reason:
>>
>> Resource types should be able to support different file extensions.
>> (resource type "image" could support .gif, .png, .jpg, .bmp, ...)
>>
>> Correct me if I'm wrong, but this would mean that only the document
>> (or asset, resp.) itself may know about its extension. This could
>> be solved in at least two ways:
>>
>> 1) add the extension to the document identifier
>>
>> /foo/bar.xml
>> /hello/world.png
>>
>> 2) add the extension to the meta data
>>
>> IMO option (1) is not really useful, because it would require to
>> add the file extension to the URL. This is fine for images etc.,
>> but rather unusual for XML files (which are typically rendered
>> as (X)HTML).
>>
>> How about adding the extension to the meta data?
>
>
> Well to the down sides of 1) I am not sure. The biggest limitation ATM
> in lenya is exactly the fact that we tend to treat xml (xhtml) different
> from the rest. What you call unusual I call normal. ;)
Hmm, maybe we're talking about different things ...
I mean http://foo.bar.com/hello.xml is a unusual URL for an HTML page.
> Anyway, I am as well happy to store the extension in the meta data. The
> only problem is something like:
> /hello/world.png
> /hello/world.pdf
> /hello/world.wav
> ...
>
> Would you then store all this extension in the meta?
This is currently not allowed. You can't have multiple documents
with the same document ID.
> Further how would you request e.g. /hello/world.pdf?
/hello/world.pdf
At the moment, the suffix is not relevant for determining the document.
> Do you want to pass the extension as param?
The extension is only used for presentation.
Both URLs
/hello/world.pdf
/hello/world.html
would point to the same document.
The URL suffix is used to render it as PDF or HTML, respectively.
> Or do you want to keep the meta like:
> /hello/world.wav.meta
No, because we don't know about the ".wav" when we access the meta data :)
> ...
>
> If so what is with meta data (like title,...) that all this different
> extension may have in common?
?? - what do you mean?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Include file extension in document ID / meta data?
Posted by Thorsten Scherler <th...@wyona.com>.
El jue, 09-03-2006 a las 14:25 +0100, Andreas Hartmann escribió:
> Hi Lenya devs,
>
> I suggested to allow custom DocumentIdToPathMappers for resource types,
> but this isn't sufficient for the following reason:
>
> Resource types should be able to support different file extensions.
> (resource type "image" could support .gif, .png, .jpg, .bmp, ...)
>
> Correct me if I'm wrong, but this would mean that only the document
> (or asset, resp.) itself may know about its extension. This could
> be solved in at least two ways:
>
> 1) add the extension to the document identifier
>
> /foo/bar.xml
> /hello/world.png
>
> 2) add the extension to the meta data
>
> IMO option (1) is not really useful, because it would require to
> add the file extension to the URL. This is fine for images etc.,
> but rather unusual for XML files (which are typically rendered
> as (X)HTML).
>
> How about adding the extension to the meta data?
Well to the down sides of 1) I am not sure. The biggest limitation ATM
in lenya is exactly the fact that we tend to treat xml (xhtml) different
from the rest. What you call unusual I call normal. ;)
Anyway, I am as well happy to store the extension in the meta data. The
only problem is something like:
/hello/world.png
/hello/world.pdf
/hello/world.wav
...
Would you then store all this extension in the meta?
Further how would you request e.g. /hello/world.pdf?
Do you want to pass the extension as param?
Or do you want to keep the meta like:
/hello/world.wav.meta
...
If so what is with meta data (like title,...) that all this different
extension may have in common?
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org