Extension persistence is certainly a possibility, but I was thinking
of juste dumping the presets in XML as is done for the rest of the
theme.
Florent
On 8 Mar 2007, at 09:38, Jean-Marc Orliaguet wrote:
Bogdan Stefanescu wrote:
Jean-Marc Orliaguet wrote:
Florent Guillaume wrote:
Very nice!
So there will also eventually be an interface to modify the
presets themselves I assume?
Thanks,
Florent
Hi,
presets are currently registered as runtime extensions (located
on the file-system). So the question is whether nxruntime
components can be persisted. Of course if it possible to register
new presets programmatically and export them to the file-system,
but that's not persistence really.
thinking about it, w.r.t. nxruntime, I think there is a need for:
- local extensions (local presets specific to a site). If
deployment is isolated, that's by default.
- shared extensions (i.e. common presets shared between sites),
using nxruntime remoting.
- persistable extensions?
Yes we could envisage extension persistence - I think we will have
use cases for this (for example defining a new document type from
the web client).
But there are several problems that need to be clarified in order
to be able to do this:
For example you have an extension A contributed by jar J in the
persistence storage and jboss is restarted - how extension A
should be deployed from jar J? It will overwrite the extension A
from the persistent storage?
But what if you remove the jar J from the system? You restart
jboss but the extension A is still in the persistent storage.
So we need a mechanism to synchronize the persistent storage with
extensions declared inside bundles.
Or may be even an extension versioning system to be able rollback
to a previous extension or things like this.
Extensions already have an ID that could be used to uniquely
identify an extension (but the id is optional and it is not used
by existing extensions)
Components also have a version attribute that could be used for
versioning.
These may be used to synchronize persistent storage with bundle
extensions.
Bogdan
I was thinking more about persisting the "content", the values of
the extensions, i.e. when you define your extension, you also
specify that the storage is persistent, but the object that
represents the extension in Java needs not be persisted.
so if your have extension A by jar J, it is a serialized version of
A that is persisted and not J itself, using something like a
storage adapter that intercepts getters and setters.
if you remove the jar from the system, what is left in the system
is the content of A, not A itself.
that's just for brainstorming, but definitely I have a use case for
persisting themes.
/JM
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
