You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@wyona.com> on 2006/03/06 17:20:41 UTC
Document interface and the real life
Hi all,
after spending some time on the resources and the content-dir, I am now
looking into making the openDocuments (oD) editable.
The plan is to have at least three basic usecases:
- new oD
- download oD (edit local)
- upload (after edit)
Now if you look into the default pub you will find that the sample is
stored in the content dir (/doctypes/opendocument/index_de.odt). We are
rendering the sample via the opendocument module.
In the sitemap we can find:
<map:generate
src="zip:context://lenya/pubs/{page-envelope:publication-id}/content/{page-envelope:area}/{page-envelope:document-id}/index_{page-envelope:document-language}.odt!/content.xml"/>
The first problem with this is that we cannot use opendocuments in
combination with an external content-dir, because it will not match
(since we are not using context:// but rather file:///).
The most logical would be to request it via the document interface but
this is not working either because DefaultDocument set
private String extension = "html";
and further IdentityDocumentIdToPathMapper.java assumes that we are
always using xml.
return languageSuffix + ".xml";
That are just *some* example classes where we have determined that we
are *always* using xml.
I am not getting tired to say that does not make sense.
In the case of opendocument the extension is .odt and it is a zip that
contains xml but still I cannot use it directly with the docu api. :(
Any ideas what the best way is to overcome this limitations of the docu
api?
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: Document interface and the real life
Posted by Jann Forrer <ja...@id.unizh.ch>.
On Tue, 7 Mar 2006, Andreas Hartmann wrote:
>
> [...]
>
>>> But that should be possible using a generic JCR browser
>>> or editing tool. IMO this argument is not sufficient for
>>> providing a filesystem-based implementation (which requires
>>> maintenance).
>>>
>>>
>>
>> everything needs maintenance ;-) So why did you start a(nother) generic
>> API in the first place and not use JCR directly within your suggested
>> API ;-)
>
> For the following reasons:
>
> - clarity (model exactly what the repository should be capable of)
> - ease of use (reduce flexibility)
> - protection (don't allow to tinker with the repository content directly)
>
+1 and +1 to the JCR approache
However in our daily (non perfect world) business ;-) we quite often have
to fix things in the FS. That means the customer has a problem and we usually
can fix it quite fast. And that should be possible independent of how you
store your data. Ohterwise the user will loose the confidence in the
system if not even the operator of the system can fix the problem in due
time.
>
>>> We once agreed on a JCR-only approach. I don't want to start
>>> the discussion again,
>>>
>>
[ ... ]
>
>
>>> but IMO we should focus
>>> on the JCR-based implementation to end up with a stable and
>>> performant product after a reasonable timespan.
>>>
>>>
>>
>> what is a reasonable timespan? Didn't we want to release 1.4 last autumn?
>
> Maybe we should release ASAP and defer the new repo API to 1.6.
>
I am not sure about that. If you want to use jcr then you have to migrate
your content twice. On the other hand the changes from 1.2 to 1.4 seems to
me quite big which would justify a release.
>>
>> But I can stand behind it with a FS based system, where we use a
>> Source/RepositoryFactory
>> and make it very simple to switch to JCR at any time (and other
>> repository implementations)
>> at any time. This is why I am working hard to get rid of all direct FS
>> dependencies which
>> will lead to a perfect world as you probably wish.
>
> I have more confidence in JCR than in the current file-system based
> repository layer in 1.4-dev. But maybe some automated tests will
> increase my confidence.
>
> Thanks for your comments! I have the feeling that there's really
> a light at the horizon re. 1.4 :)
>
:-)
Jann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> [...]
>>
>>
>>
>>>> But that should be possible using a generic JCR browser
>>>> or editing tool. IMO this argument is not sufficient for
>>>> providing a filesystem-based implementation (which requires
>>>> maintenance).
>>>>
>>>>
>>>>
>>> everything needs maintenance ;-) So why did you start a(nother) generic
>>> API in the first place and not use JCR directly within your suggested
>>> API ;-)
>>>
>>
>> For the following reasons:
>>
>> - clarity (model exactly what the repository should be capable of)
>> - ease of use (reduce flexibility)
>> - protection (don't allow to tinker with the repository content directly)
>>
>>
>
> very good reasons, but this doesn't prohibit to do a FS implementation
> of the API
Yes. I'm not against the existence of a FS implementation, I'd just
like to have a stable JCR-based implementation, and I won't manage
to finish that on my own.
>>>> We once agreed on a JCR-only approach. I don't want to start
>>>> the discussion again,
>>>>
>>>>
>>> I would, because I have realized there are still a lot of
>>> people wanting to use the FS and I think it makes a lot
>>> of sense in many cases and that's the situation many people are
>>> in.
>>>
>>> As said before we don't have any clue what problems lie ahead re JCR
>>> and although I am big fan of JCR and keep pushing it for some years now,
>>> I still want an alternative and Lenya is able to provide such an
>>> alternative
>>> very easily.
>>>
>>
>> I doubt that we can provide it "very easily", but this depends
>> on one's point of view what it should be capable of.
>>
>>
>
> this is why one introduces compliance levels, just as
> JCR has
I'm rather refering to stability, performance, and scalability.
>>>> I just wanted to point out the option
>>>> of implementing a file-system based repository (I'm sure that
>>>> would have been the next question). The (in)famous phrase
>>>> "feel free to implement this" applies,
>>>>
>>>>
>>> maybe you don't have to implement this, but please give other people
>>> the freedom to do so, especially if they are ready to invest
>>> the time and already invested a lot of time into this project.
>>>
>>
>> Agreed. I just expressed my priorities.
>>
>>
>>
>>
>>>> but IMO we should focus
>>>> on the JCR-based implementation to end up with a stable and
>>>> performant product after a reasonable timespan.
>>>>
>>>>
>>>>
>>> what is a reasonable timespan? Didn't we want to release 1.4 last
>>> autumn?
>>>
>>
>> Maybe we should release ASAP
>
> well, I think as long as we haven't removed all
> direct FS calls I don't think we should release.
Yes, I agree.
> But it seems to me that we are making quite some progress
> and hopefully have mostly done very soon.
>
> Also as I noted before I think we should introduce a minimal
> navigation framework using UUID to make sure that one can
> easily move stuff around.
+1
>> and defer the new repo API to 1.6.
>>
>>
>>
>>
>>> I see the light at the horizon, but not with a fully tested JCR where
>>> we can tell people with proper honesty, please rely your publications on
>>> this ...
>>>
>>> But I can stand behind it with a FS based system, where we use a
>>> Source/RepositoryFactory
>>> and make it very simple to switch to JCR at any time (and other
>>> repository implementations)
>>> at any time. This is why I am working hard to get rid of all direct FS
>>> dependencies which
>>> will lead to a perfect world as you probably wish.
>>>
>>
>> I have more confidence in JCR
>
> well, does it really perform and scale? Have
> you really tested it under real circumstances?
No, but the Jackrabbit list suggests that others do.
>> than in the current file-system based
>> repository layer in 1.4-dev. But maybe some automated tests will
>> increase my confidence.
>>
>>
>
> that's what we should do anyway ;-) and I will try hard
> to get these tests into Lenya (also with continuous integration,
> e.g. with cruise control)
That would be great. Maybe we can install cruisecontrol on our zone?
-- 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: Document interface and the real life
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
>[...]
>
>
>
>>>But that should be possible using a generic JCR browser
>>>or editing tool. IMO this argument is not sufficient for
>>>providing a filesystem-based implementation (which requires
>>>maintenance).
>>>
>>>
>>>
>>>
>>everything needs maintenance ;-) So why did you start a(nother) generic
>>API in the first place and not use JCR directly within your suggested
>>API ;-)
>>
>>
>
>For the following reasons:
>
>- clarity (model exactly what the repository should be capable of)
>- ease of use (reduce flexibility)
>- protection (don't allow to tinker with the repository content directly)
>
>
very good reasons, but this doesn't prohibit to do a FS implementation
of the API
>
>
>
>>>We once agreed on a JCR-only approach. I don't want to start
>>>the discussion again,
>>>
>>>
>>>
>>I would, because I have realized there are still a lot of
>>people wanting to use the FS and I think it makes a lot
>>of sense in many cases and that's the situation many people are
>>in.
>>
>>As said before we don't have any clue what problems lie ahead re JCR
>>and although I am big fan of JCR and keep pushing it for some years now,
>>I still want an alternative and Lenya is able to provide such an alternative
>>very easily.
>>
>>
>
>I doubt that we can provide it "very easily", but this depends
>on one's point of view what it should be capable of.
>
>
this is why one introduces compliance levels, just as
JCR has
>
>
>
>>>I just wanted to point out the option
>>>of implementing a file-system based repository (I'm sure that
>>>would have been the next question). The (in)famous phrase
>>>"feel free to implement this" applies,
>>>
>>>
>>>
>>maybe you don't have to implement this, but please give other people
>>the freedom to do so, especially if they are ready to invest
>>the time and already invested a lot of time into this project.
>>
>>
>
>Agreed. I just expressed my priorities.
>
>
>
>
>>>but IMO we should focus
>>>on the JCR-based implementation to end up with a stable and
>>>performant product after a reasonable timespan.
>>>
>>>
>>>
>>>
>>what is a reasonable timespan? Didn't we want to release 1.4 last autumn?
>>
>>
>
>Maybe we should release ASAP
>
well, I think as long as we haven't removed all
direct FS calls I don't think we should release.
But it seems to me that we are making quite some progress
and hopefully have mostly done very soon.
Also as I noted before I think we should introduce a minimal
navigation framework using UUID to make sure that one can
easily move stuff around.
>and defer the new repo API to 1.6.
>
>
>
>
>>I see the light at the horizon, but not with a fully tested JCR where
>>we can tell people with proper honesty, please rely your publications on
>>this ...
>>
>>But I can stand behind it with a FS based system, where we use a
>>Source/RepositoryFactory
>>and make it very simple to switch to JCR at any time (and other
>>repository implementations)
>>at any time. This is why I am working hard to get rid of all direct FS
>>dependencies which
>>will lead to a perfect world as you probably wish.
>>
>>
>
>I have more confidence in JCR
>
well, does it really perform and scale? Have
you really tested it under real circumstances?
>than in the current file-system based
>repository layer in 1.4-dev. But maybe some automated tests will
>increase my confidence.
>
>
that's what we should do anyway ;-) and I will try hard
to get these tests into Lenya (also with continuous integration,
e.g. with cruise control)
>Thanks for your comments! I have the feeling that there's really
>a light at the horizon re. 1.4 :)
>
>
me too :-) Let's just get it usable and that it really
works very well within the next couple of weeks and I am sure people
will love it.
Michi
>-- Andreas
>
>--------------------------------------------------------------
>Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
> Wyona AG, Hardstrasse 219, CH-8005 Zurich
>Open Source CMS http://www.wyona.org http://www.wyona.com
>--------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@apache.org>.
[...]
>>But that should be possible using a generic JCR browser
>>or editing tool. IMO this argument is not sufficient for
>>providing a filesystem-based implementation (which requires
>>maintenance).
>>
>>
>
> everything needs maintenance ;-) So why did you start a(nother) generic
> API in the first place and not use JCR directly within your suggested
> API ;-)
For the following reasons:
- clarity (model exactly what the repository should be capable of)
- ease of use (reduce flexibility)
- protection (don't allow to tinker with the repository content directly)
>>We once agreed on a JCR-only approach. I don't want to start
>>the discussion again,
>>
>
> I would, because I have realized there are still a lot of
> people wanting to use the FS and I think it makes a lot
> of sense in many cases and that's the situation many people are
> in.
>
> As said before we don't have any clue what problems lie ahead re JCR
> and although I am big fan of JCR and keep pushing it for some years now,
> I still want an alternative and Lenya is able to provide such an alternative
> very easily.
I doubt that we can provide it "very easily", but this depends
on one's point of view what it should be capable of.
>> I just wanted to point out the option
>>of implementing a file-system based repository (I'm sure that
>>would have been the next question). The (in)famous phrase
>>"feel free to implement this" applies,
>>
>
> maybe you don't have to implement this, but please give other people
> the freedom to do so, especially if they are ready to invest
> the time and already invested a lot of time into this project.
Agreed. I just expressed my priorities.
>> but IMO we should focus
>>on the JCR-based implementation to end up with a stable and
>>performant product after a reasonable timespan.
>>
>>
>
> what is a reasonable timespan? Didn't we want to release 1.4 last autumn?
Maybe we should release ASAP and defer the new repo API to 1.6.
> I see the light at the horizon, but not with a fully tested JCR where
> we can tell people with proper honesty, please rely your publications on
> this ...
>
> But I can stand behind it with a FS based system, where we use a
> Source/RepositoryFactory
> and make it very simple to switch to JCR at any time (and other
> repository implementations)
> at any time. This is why I am working hard to get rid of all direct FS
> dependencies which
> will lead to a perfect world as you probably wish.
I have more confidence in JCR than in the current file-system based
repository layer in 1.4-dev. But maybe some automated tests will
increase my confidence.
Thanks for your comments! I have the feeling that there's really
a light at the horizon re. 1.4 :)
-- Andreas
--------------------------------------------------------------
Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
>[...]
>
>
>
>>>>1) add a filesystem-based implementation if you don't want to rely on JCR
>>>>
>>>>
>>>>
>>>I think we should do that, because we don't know how JCR will behave in the
>>>first
>>>place for productive environments and with the FS we know exactly where the
>>>problems
>>>are and how we can fix them.
>>>
>>>
>>>
>>+1
>>In our daily lenya business it may happen that we have to fix
>>things up in the FS. Therefore having a FS based system too, seems
>>important to me.
>>As an alternative there should be tools to export and import Documents
>>out-of/into the repository outside of the cms like
>>
>>export documet to FS --> Fix error --> import into repo
>>
>>
>
>I see the point, we're not living in a perfect world ...
>
>
no, we aren't and that's the whole point.
>But that should be possible using a generic JCR browser
>or editing tool. IMO this argument is not sufficient for
>providing a filesystem-based implementation (which requires
>maintenance).
>
>
everything needs maintenance ;-) So why did you start a(nother) generic
API in the first place and not use JCR directly within your suggested
API ;-)
>We once agreed on a JCR-only approach. I don't want to start
>the discussion again,
>
I would, because I have realized there are still a lot of
people wanting to use the FS and I think it makes a lot
of sense in many cases and that's the situation many people are
in.
As said before we don't have any clue what problems lie ahead re JCR
and although I am big fan of JCR and keep pushing it for some years now,
I still want an alternative and Lenya is able to provide such an alternative
very easily.
> I just wanted to point out the option
>of implementing a file-system based repository (I'm sure that
>would have been the next question). The (in)famous phrase
>"feel free to implement this" applies,
>
maybe you don't have to implement this, but please give other people
the freedom to do so, especially if they are ready to invest
the time and already invested a lot of time into this project.
> but IMO we should focus
>on the JCR-based implementation to end up with a stable and
>performant product after a reasonable timespan.
>
>
what is a reasonable timespan? Didn't we want to release 1.4 last autumn?
I see the light at the horizon, but not with a fully tested JCR where
we can tell people with proper honesty, please rely your publications on
this ...
But I can stand behind it with a FS based system, where we use a
Source/RepositoryFactory
and make it very simple to switch to JCR at any time (and other
repository implementations)
at any time. This is why I am working hard to get rid of all direct FS
dependencies which
will lead to a perfect world as you probably wish.
But let's be real and get this thing going.
Michi
>-- Andreas
>
>--------------------------------------------------------------
>Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
> Wyona AG, Hardstrasse 219, CH-8005 Zurich
>Open Source CMS http://www.wyona.org http://www.wyona.com
>--------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@wyona.org>.
[...]
>>> 1) add a filesystem-based implementation if you don't want to rely on JCR
>>>
>>
>> I think we should do that, because we don't know how JCR will behave in the
>> first
>> place for productive environments and with the FS we know exactly where the
>> problems
>> are and how we can fix them.
>>
>
> +1
> In our daily lenya business it may happen that we have to fix
> things up in the FS. Therefore having a FS based system too, seems
> important to me.
> As an alternative there should be tools to export and import Documents
> out-of/into the repository outside of the cms like
>
> export documet to FS --> Fix error --> import into repo
I see the point, we're not living in a perfect world ...
But that should be possible using a generic JCR browser
or editing tool. IMO this argument is not sufficient for
providing a filesystem-based implementation (which requires
maintenance).
We once agreed on a JCR-only approach. I don't want to start
the discussion again, I just wanted to point out the option
of implementing a file-system based repository (I'm sure that
would have been the next question). The (in)famous phrase
"feel free to implement this" applies, but IMO we should focus
on the JCR-based implementation to end up with a stable and
performant product after a reasonable timespan.
-- Andreas
--------------------------------------------------------------
Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Jann Forrer <ja...@id.unizh.ch>.
On Tue, 7 Mar 2006, Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> [...]
>>
>>
>>> so, let's implement them ;-)
>>>
>>
>> That's the easy part ...
>>
>>
>>> What do we have to do to get them working?
>>>
>>
>> That's the hard part :)
>>
>> Things to do:
>>
>> 1) add a filesystem-based implementation if you don't want to rely on JCR
>>
>
> I think we should do that, because we don't know how JCR will behave in the
> first
> place for productive environments and with the FS we know exactly where the
> problems
> are and how we can fix them.
>
+1
In our daily lenya business it may happen that we have to fix
things up in the FS. Therefore having a FS based system too, seems
important to me.
As an alternative there should be tools to export and import Documents
out-of/into the repository outside of the cms like
export documet to FS --> Fix error --> import into repo
Jann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
>[...]
>
>
>
>>so, let's implement them ;-)
>>
>>
>
>That's the easy part ...
>
>
>
>>What do we have to do to get them working?
>>
>>
>
>That's the hard part :)
>
>Things to do:
>
>1) add a filesystem-based implementation if you don't want to rely on JCR
>
>
I think we should do that, because we don't know how JCR will behave in
the first
place for productive environments and with the FS we know exactly where
the problems
are and how we can fix them.
So even if it requires some extra work, I think we should follow the
"Apache httpd" strategy
of defensive programming.
>2) replace all references to the current publication API to the API declared
> by the repository module
>
>I once started with (2), but its more or less a re-write of Lenya, and I
>dropped it.
>
>Therefore I started to write some adapter classes (see package
>org.apache.lenya.cms.repo.Adapter in the repository module) to
>allow for a smooth transition. But this doesn't make much sense either,
>because the API is not really compatible.
>
>IMO the way to go is to
>
>1. add tests, more tests, and even more tests
> to allow refactoring and redesign
>2. break up the core into modules
>3. reduce dependencies between modules
>4. migrate modules step by step to the new API
>
>BTW, I already posted a lot of messages to this list about the API draft,
>you should find more info by searching for "repository".
>
>
ok, thanks, we will try to take a look at it.
Michi
>-- Andreas
>
>
>--------------------------------------------------------------
>Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
> Wyona AG, Hardstrasse 219, CH-8005 Zurich
>Open Source CMS http://www.wyona.org http://www.wyona.com
>--------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> 1) add a filesystem-based implementation if you don't want to rely on JCR
is that really necessary? seems like an awful lot of work for little to
no gain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@apache.org>.
[...]
> so, let's implement them ;-)
That's the easy part ...
> What do we have to do to get them working?
That's the hard part :)
Things to do:
1) add a filesystem-based implementation if you don't want to rely on JCR
2) replace all references to the current publication API to the API declared
by the repository module
I once started with (2), but its more or less a re-write of Lenya, and I
dropped it.
Therefore I started to write some adapter classes (see package
org.apache.lenya.cms.repo.Adapter in the repository module) to
allow for a smooth transition. But this doesn't make much sense either,
because the API is not really compatible.
IMO the way to go is to
1. add tests, more tests, and even more tests
to allow refactoring and redesign
2. break up the core into modules
3. reduce dependencies between modules
4. migrate modules step by step to the new API
BTW, I already posted a lot of messages to this list about the API draft,
you should find more info by searching for "repository".
-- Andreas
--------------------------------------------------------------
Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Michael Wechner <mi...@wyona.com>.
Josias Thöny wrote:
>On Mon, 2006-03-06 at 17:20 +0100, Thorsten Scherler wrote:
>
>
>>Hi all,
>>
>>after spending some time on the resources and the content-dir, I am now
>>looking into making the openDocuments (oD) editable.
>>
>>The plan is to have at least three basic usecases:
>>- new oD
>>- download oD (edit local)
>>- upload (after edit)
>>
>>Now if you look into the default pub you will find that the sample is
>>stored in the content dir (/doctypes/opendocument/index_de.odt). We are
>>rendering the sample via the opendocument module.
>>
>>In the sitemap we can find:
>><map:generate
>>src="zip:context://lenya/pubs/{page-envelope:publication-id}/content/{page-envelope:area}/{page-envelope:document-id}/index_{page-envelope:document-language}.odt!/content.xml"/>
>>
>>The first problem with this is that we cannot use opendocuments in
>>combination with an external content-dir, because it will not match
>>(since we are not using context:// but rather file:///).
>>
>>The most logical would be to request it via the document interface but
>>this is not working either because DefaultDocument set
>>private String extension = "html";
>>and further IdentityDocumentIdToPathMapper.java assumes that we are
>>always using xml.
>>return languageSuffix + ".xml";
>>
>>That are just *some* example classes where we have determined that we
>>are *always* using xml.
>>
>>I am not getting tired to say that does not make sense.
>>
>>In the case of opendocument the extension is .odt and it is a zip that
>>contains xml but still I cannot use it directly with the docu api. :(
>>
>>Any ideas what the best way is to overcome this limitations of the docu
>>api?
>>
>>
>
>Andreas already wrote a new API, see the o.a.l.cms.repo Package in the
>repository module.
>
>The Translation class has getInputStream(), getOutputStream(),
>getMimeType() etc., so there is no limitation to xml content anymore.
>
>However, there is no implementation of these interfaces yet AFAIK...
>
>
so, let's implement them ;-) What do we have to do to get them working?
Maybe Andreas can give some pointers ...
Michi
>Josias
>
>
>
>
>
>>salu2
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@wyona.org>.
[...]
> Andreas already wrote a new API, see the o.a.l.cms.repo Package in the
> repository module.
>
> The Translation class has getInputStream(), getOutputStream(),
> getMimeType() etc., so there is no limitation to xml content anymore.
>
> However, there is no implementation of these interfaces yet AFAIK...
A JCR-based implementation is located in the jcr module.
The jackrabbit module contains a Jackrabbit-based implementation of
the Repository and RepositoryFactory interfaces.
Some methods aren't implemented yet.
If you run one of those commands
./build.sh migrate-14
./build.sh modules.test
you see the JCR-based implementation in action.
-- Andreas
--------------------------------------------------------------
Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Andreas Hartmann <an...@apache.org>.
> On Mon, 2006-03-06 at 17:20 +0100, Thorsten Scherler wrote:
>> Hi all,
>>
>> after spending some time on the resources and the content-dir, I am now
>> looking into making the openDocuments (oD) editable.
>>
>> The plan is to have at least three basic usecases:
>> - new oD
>> - download oD (edit local)
>> - upload (after edit)
>>
>> Now if you look into the default pub you will find that the sample is
>> stored in the content dir (/doctypes/opendocument/index_de.odt). We are
>> rendering the sample via the opendocument module.
>>
>> In the sitemap we can find:
>> <map:generate
>> src="zip:context://lenya/pubs/{page-envelope:publication-id}/content/{page-envelope:area}/{page-envelope:document-id}/index_{page-envelope:document-language}.odt!/content.xml"/>
>>
>> The first problem with this is that we cannot use opendocuments in
>> combination with an external content-dir, because it will not match
>> (since we are not using context:// but rather file:///).
>>
>> The most logical would be to request it via the document interface but
>> this is not working either because DefaultDocument set
>> private String extension = "html";
>> and further IdentityDocumentIdToPathMapper.java assumes that we are
>> always using xml.
>> return languageSuffix + ".xml";
>>
>> That are just *some* example classes where we have determined that we
>> are *always* using xml.
>>
>> I am not getting tired to say that does not make sense.
>>
>> In the case of opendocument the extension is .odt and it is a zip that
>> contains xml but still I cannot use it directly with the docu api. :(
>>
>> Any ideas what the best way is to overcome this limitations of the docu
>> api?
>
> Andreas already wrote a new API, see the o.a.l.cms.repo Package in the
> repository module.
>
> The Translation class has getInputStream(), getOutputStream(),
> getMimeType() etc., so there is no limitation to xml content anymore.
>
> However, there is no implementation of these interfaces yet AFAIK...
>
> Josias
>
>
>
>>
>> salu2
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
--------------------------------------------------------------
Andreas Hartmann andreas.hartmann@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
--------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Document interface and the real life
Posted by Josias Thöny <jo...@wyona.com>.
On Mon, 2006-03-06 at 17:20 +0100, Thorsten Scherler wrote:
> Hi all,
>
> after spending some time on the resources and the content-dir, I am now
> looking into making the openDocuments (oD) editable.
>
> The plan is to have at least three basic usecases:
> - new oD
> - download oD (edit local)
> - upload (after edit)
>
> Now if you look into the default pub you will find that the sample is
> stored in the content dir (/doctypes/opendocument/index_de.odt). We are
> rendering the sample via the opendocument module.
>
> In the sitemap we can find:
> <map:generate
> src="zip:context://lenya/pubs/{page-envelope:publication-id}/content/{page-envelope:area}/{page-envelope:document-id}/index_{page-envelope:document-language}.odt!/content.xml"/>
>
> The first problem with this is that we cannot use opendocuments in
> combination with an external content-dir, because it will not match
> (since we are not using context:// but rather file:///).
>
> The most logical would be to request it via the document interface but
> this is not working either because DefaultDocument set
> private String extension = "html";
> and further IdentityDocumentIdToPathMapper.java assumes that we are
> always using xml.
> return languageSuffix + ".xml";
>
> That are just *some* example classes where we have determined that we
> are *always* using xml.
>
> I am not getting tired to say that does not make sense.
>
> In the case of opendocument the extension is .odt and it is a zip that
> contains xml but still I cannot use it directly with the docu api. :(
>
> Any ideas what the best way is to overcome this limitations of the docu
> api?
Andreas already wrote a new API, see the o.a.l.cms.repo Package in the
repository module.
The Translation class has getInputStream(), getOutputStream(),
getMimeType() etc., so there is no limitation to xml content anymore.
However, there is no implementation of these interfaces yet AFAIK...
Josias
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org