[xwiki-devs] [Proposal][New Model] Using a new Model API extending the JCR API
Hi, I've started working on our new model again (see http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20 for a reminder of what this is about). Right now I'm leaning towards having a typed API but that extends the JCR API. For example: public interface Server extends Repository { /** * @return the list of all wiki names inside this Server */ List<String> getWikiNames(); Wiki getWiki(String wikiName); Wiki createWiki(String wikiName); void addWiki(Wiki wiki); void removeWiki(String wikiName); } or public interface Document extends Node { /** * @return the list of object definitions defined inside this document */ List<ObjectDefinition> getObjectDefinitions(); List<Object> getObjects(); List<Attachment> getAttachments(); void setContent(String content); } As you can see these 2 interfaces extend the JCR interfaces (Repository and Node) which means you either use the typed APIs they expose of the underlying JCR API. For example you could write: $doc.setProperty("xwiki:content", "my new content"); <-- JCR API $doc.save() <-- JCR API or $doc.setContent("my new content"); <-- typed API $doc.save() <-- JCR API This means we'll be tied to the JCR API but I don't see this as a bad thing since this API is a generic document-oriented repository API and doesn't impose any implementation. The alternative would be to use our own API and copy 90% of the existing JCR API and then do the mapping in the implementing classes. Let me know what you think. I'll be committing some interfaces soon at http://svn.xwiki.org/svnroot/xwiki/sandbox/components/xwiki-model/ If you don't agree let me know quickly so that we can discuss it and come to an agreement. On a different but related topic I'm also interested in getting your feedback on the interface names I have created (ObjectDefinition instead of Class, Server for a wiki farm, etc). Thanks -Vincent
One things to note: * Workspace has the following methods: - ObservationManager getObservationManager() - QueryManager getQueryManager() This means we'll have to implement these APIs too and not xwiki- specific ones. In any case there's no choice if we decide to expose the JCR API. Similarly we won't need to expose a storage API since it's already exposed through the JCR API (for example: Node.save() or Session.save()). Thanks -Vincent On Apr 12, 2009, at 6:39 PM, Vincent Massol wrote:
Hi,
I've started working on our new model again (see http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20 for a reminder of what this is about). Right now I'm leaning towards having a typed API but that extends the JCR API. For example:
public interface Server extends Repository { /** * @return the list of all wiki names inside this Server */ List<String> getWikiNames();
Wiki getWiki(String wikiName);
Wiki createWiki(String wikiName);
void addWiki(Wiki wiki);
void removeWiki(String wikiName); }
or
public interface Document extends Node { /** * @return the list of object definitions defined inside this document */ List<ObjectDefinition> getObjectDefinitions();
List<Object> getObjects();
List<Attachment> getAttachments();
void setContent(String content); }
As you can see these 2 interfaces extend the JCR interfaces (Repository and Node) which means you either use the typed APIs they expose of the underlying JCR API. For example you could write:
$doc.setProperty("xwiki:content", "my new content"); <-- JCR API $doc.save() <-- JCR API
or
$doc.setContent("my new content"); <-- typed API $doc.save() <-- JCR API
This means we'll be tied to the JCR API but I don't see this as a bad thing since this API is a generic document-oriented repository API and doesn't impose any implementation.
The alternative would be to use our own API and copy 90% of the existing JCR API and then do the mapping in the implementing classes.
Let me know what you think. I'll be committing some interfaces soon at http://svn.xwiki.org/svnroot/xwiki/sandbox/components/xwiki-model/
If you don't agree let me know quickly so that we can discuss it and come to an agreement.
On a different but related topic I'm also interested in getting your feedback on the interface names I have created (ObjectDefinition instead of Class, Server for a wiki farm, etc).
Thanks -Vincent
Vincent Massol wrote:
Hi,
I've started working on our new model again (see http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20 for a reminder of what this is about). Right now I'm leaning towards having a typed API but that extends the JCR API. For example:
public interface Server extends Repository { /** * @return the list of all wiki names inside this Server */ List<String> getWikiNames();
Wiki getWiki(String wikiName);
Wiki createWiki(String wikiName);
void addWiki(Wiki wiki);
void removeWiki(String wikiName); }
or
public interface Document extends Node { /** * @return the list of object definitions defined inside this document */ List<ObjectDefinition> getObjectDefinitions();
List<Object> getObjects();
List<Attachment> getAttachments();
void setContent(String content); }
As you can see these 2 interfaces extend the JCR interfaces (Repository and Node) which means you either use the typed APIs they expose of the underlying JCR API. For example you could write:
$doc.setProperty("xwiki:content", "my new content"); <-- JCR API $doc.save() <-- JCR API
or
$doc.setContent("my new content"); <-- typed API $doc.save() <-- JCR API
This means we'll be tied to the JCR API but I don't see this as a bad thing since this API is a generic document-oriented repository API and doesn't impose any implementation.
I'll have to read more about JCR before I can comment on this.
The alternative would be to use our own API and copy 90% of the existing JCR API and then do the mapping in the implementing classes.
Let me know what you think. I'll be committing some interfaces soon at http://svn.xwiki.org/svnroot/xwiki/sandbox/components/xwiki-model/
If you don't agree let me know quickly so that we can discuss it and come to an agreement.
On a different but related topic I'm also interested in getting your feedback on the interface names I have created (ObjectDefinition instead of Class, Server for a wiki farm, etc).
+1 for ObjectDefinition Server is not perfect, since there are many deployment options that don't correspond to a single hardware server: cloud computing, clustering, virtualization... And Server is still pointing to hardware, at least that's how I feel. And I think we had this discussion in the past. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (2)
-
Sergiu Dumitriu -
Vincent Massol