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 ) 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? -TR --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
