Stefan Guggisberg schrieb:
This is interesting as the CMS that I've designed for the company that I've worked before was working this way: Content was stored very fine grained and web applications could be structured and assembled by referencing these nodes. Finally you'll get something comparable to a native XML database...this post is becoming hard to read so i just listed the relevant parts and added my comments...
Daniel Florey wrote:
Ah, that works. There seems to be a bug in the webdav layer as I can't
see the uploaded files in my webdav client (konqueror). But it's all
there in the content view.
Are these nodes really stored as different nodes or are they only
displayed to the user as if it were many nodes?
all nodes that you see do actually exist.
the approach i've taken in the ri is to match 1:1 the ri's persistence model (node states & property states) with the content model of jsr 170 (nodes & properties). this makes the implementation imo a lot cleaner. the ri has e.g. no notion of specific node types (such as 'nt:file'). one of the benefits is that it can handle any node type that you declare.
the down side is that performance suffers when the state is stored in the file system because there are lots of small files in a lot of folders (the path is the node's uuid splitted in four parts).
i plan to provide an alternative persistence layer implemetation that uses a relational database. the current persistence model maps very nicely to a simple normalized db schema. i expect the performance to be a lot better.
another plan is to provide a way to define specific persistence groupings, i.e. what nodes & properties should be stored & loaded together.
You can have a look at
http://www.c1-fse.de/contell/c1web/c1fse/site/Contelligent/contelligent/index.html
It's very hard to manage especially caching, security, transactions, versioning when using this approach, so I'm very curious if this will work.
The hardest part might be to map the different DASL-searching languages to the jsr query language. Have a look at:I see. I would be great if we could achieve a 1:1 feature mapping
between jcr-170 and webdav, but I still don't know if this will work. I
would be bad if we would run into a situation that we currently have
regarding the Slide core api.
I expect some things to adjust in the area of locking, version,
searching, transaction handling and notifications.
my conception is that jsr 170 is a superset of webdav in terms of functionality, but i am not a webdav expert.
versioning & locking in jsr 170 were mainly spec'ed by geoff clemm (the spec lead of jsr 147) with the intention of syncing them functionality wise as closely as possible.
do you have specific webdav features in mind that you can not map to
jsr 170?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/spssdk/html/_search_request_format.asp
there you'll find some examples of exchange DASL.
The current WebDAV-protocols you can find at
http://greenbytes.de/tech/webdav/
I'm not an expert of the locking spec, but this might also be difficult to map (shared/exclusive locks)...
It would be a great benefit for Slide to support all of these standars, as content could then be accessed via all the tools that CMS-users prefer:
Outlook or Evolution for task management, Dreamweaver & co for layouters and XMLSpy, XMLMind, InfoPath and other for the editors.
CHeers,
Daniel
cheers stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
