12 Dec
2009
12 Dec
'09
6:46 p.m.
On Dec 12, 2009, at 4:46 PM, Thomas Mortagne wrote:
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.
I agree.
[snip]
On Sat, Dec 12, 2009 at 16:02, vmassol
<contrib-notifications(a)xwiki.org
[snip]
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
[...] - 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) ? > + //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. 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