On Jun 24, 2004, at 12:49 PM, Tim Reilly wrote:
I'll move this to it's own thread to avoid confusion, but for the sake of
discussion - what's wrong with using jsr-170 java content repository (jcr)
for the model that's been discussed here?
My position is that everything discussed can be implemented using the
jcr-api, and it's very well documented already. No wheel re-invention. It
would (or should) allow any jcr compliant repository to be plugged-in as a
replacement to the default implementation shipped with j2. Be it
file-system, xml, webdav, dbms, slide, some ibm product or whatever. (I
mention IBM since reportedly they'd be implementing the api:
http://www.cmswatch.com/News/Article/?308 )
I think its a great idea
Using jcr j2 could define in its namespace nt = node type's:
j2nt:folder [fill-in properties] j2nt:page [fill-in properties] j2nt:layout [fill-in properties] j2nt:fragment [fill-in properties] j2nt:external-link [fill-in properties] j2nt:decoration [fill-in properties] j2nt:menu-decoration inherts from j2nt:decoration [fill-in additional properties]
JCR already defines NodeType.SOFTLINK and NodeType.REFERENCE types which is
a ? that's been discussed.
Given a jcr ticket (workspace + credentials) you would get the workspace for
that user (even if the user is 'anonymous' - probably similar to the desktop
concept David or someone mentioned) I mention this since it's the one bit I
haven't seen much attention given in the menu discussion; basically the data
in the data model (workspace) would be different based on
ACL's/authorization I'd assume.
i18n under the jcr model - these can either be properties or nodes. For example as properties; MyFolder.label_en_US= or as nodes (my vote): MyFolder.getNode("labels/en/US/");
My opinion is the jcr api provides the ideal interfaces to work with.
Everything discussed thus far can be implemented as node types, and allows
further extensions by users/developers.
Quoting David Nuescheler at Day.com (spec lead):.. but it most certainly think that a repository has all the facilities that the portal would need with respect to content organization sooner or later... (sort-order, hierarchies, versioning, links, ...)*Note the spec is not final so that's something of a risk.
Implementing the interfaces in a default implementation is where the real
work would be IMHO. Not sure if PSML could/would be wrapped or still be
appropriate. I think it would be. The jsr discusses xml serialization, this
was in mind or important during the specifications development.
Thoughts?
On the other hand its a lot of work to implement this complex specification
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
