On Dec 12, 2009, at 4:46 PM, Thomas Mortagne wrote:
On Sat, Dec 12, 2009 at 16:02, vmassol <[email protected]
wrote: Author: vmassol Date: 2009-12-12 16:02:21 +0100 (Sat, 12 Dec 2009) New Revision: 25768
Added: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Persistable.java Removed: contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/internal/ contrib/sandbox/xwiki-model/src/main/resources/ contrib/sandbox/xwiki-model/src/test/ Modified: contrib/sandbox/xwiki-model/ contrib/sandbox/xwiki-model/pom.xml contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Attachment.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Document.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Object.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ ObjectDefinition.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ ObjectDefinitionProperty.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Server.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/ Space.java contrib/sandbox/xwiki-model/src/main/java/org/xwiki/model/Wiki.java Log: Continuing work on the new Model. The idea is to do step1, which is about designing the interfaces and implementing them with the old model FTM.
* Remove dependencies on JCR since we now want to create interfaces for the new model that are independent of JCR (for a start). I'm still unsure whether we should base these interfaces on JCR or not but it seems easier not to for the moment. * Several questions asked in comments
[...]
[snip]
- String setContent(String content); + + void setParent(Document document); + + Document getParent(); + + // Note: In order to make modifications to the document's content, modify the returned XDOM + // Default language + XDOM getContent(); + XDOM getContent(Locale locale); + + // get/setSyntax(Syntax syntax) + + // Q: Should we have this or should we force users to use a Parser for a given syntax, ie make Document + // independent of the Syntax?
Sounds nicer to only work with XDOM but what does it mean for the storage ? Is the way to store the document content (a string in some syntax, directly in the database with each block type having its own table, etc...) become an implementation details (good idea IMO) ?
Re storage it means storing the content in a syntax indep way indeed, in some serialization format for Blocks (Having a table for each block type sounds way too complex - in order to load a given document's content you'd need to do tons of SQL queries). Note that storing in some serialized block format means faster load time since there's no need to perform syntax parsing. One pb with using syntax-indep storage though is that we need to migrate existing content to the new format. It also means some questions to support the 1.0 syntax since 1.0 syntax is rendered using the old rendering which doesn't know about XDOM blocks.
+ //String setContent(String content); + + boolean hasObject(String objectName); + + // Q: Is this ok? + DocumentName getDocumentName();
[snip]
void removeWiki(String wikiName); + + boolean hasWiki(String wikiName); + + // Q: Should the methods below be moved into some other class, such as a DocumentQuery component which would + // be less generic than using the Query Manager?
Yes it's looks too much like a helper for something that should be in some generic query api to me. Or having something more generic, see at the end of the mail.
I agree. [snip]
Some quick comments about the model: * I think we should have something more generic that DocumentName that support anything from Wiki to objet or class property. Some WikiResourceName that target anything in XWiki and that you can use with the query api. Then we can provide different parser/serializer for WikiResourceName (URIParser/serializer used in REST, WikiSyntaxParser/Serialize commonly used in the document content as link/attachment/image reference, etc...).
+1 for XWikiResourceName, similar to what we already have in xwiki-url module: XWikiURL, XWikiDocumentURL, XWikiAttachmentURL, etc. So we can keep DocumentName and AttachmentName but transform them so that they extend WikiResourceName and create other names for Objects, Properties, etc. <brainstorm mode - Note: below you can replace Document with WikiResource everywhere> Re the Query API, yes we could probably find a way to reuse the existing API, for example by having DocumentQuery (implements Query), AttachmentQuery (implement Query), etc. So you'd write something like: Document document = (Document) new DocumentQuery(DocumentName).execute().get(0); It may still be slightly too complex (not sure) so we might still need to have some higher-level API, such as DocumentQueryManager.createQuery(DocumentName). Or maybe simply add a new method in DocumentQuery such as: Document DocumentQuery.getDocument(); That would give: Document document = new DocumentQuery(DocumentName).getDocument(); This is probably still too complex and we should use some singleton object instead of doing a new query every time... The name Query isn't nice too. So instead something like: class: WikiResourceFinder<T> method: T findResource(T resource); internally WikiResourceFinder could use the Query Manager to find the resource. <brainstorm mode>
* Persistable should maybe also contains something like copy() or clone(), we generally know what we are copying but having in at Persistable make sure this is posible for anything in the model tree
+1 too Thanks -Vincent