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
_______________________________________________
ECM mailing list
[email protected]
http://lists.nuxeo.com/mailman/listinfo/ecm
