[EMAIL PROTECTED] schrieb:
[…]
I just read your (Andreas') JCR-related documents in the Wiki.
Learning about JCR and possibly integration into Lenya led to one
question:
What is Lenya?
Lenya 1.2 was:
1. XML file-based repository = transparent datastore.
2. Easy versioning of documents.
3. Easy multiple translations of documents.
4. Easy formatting of documents with XSL.
5. WYSIWYG editing of documents.
6. Functional expansion with XMAPs, XSLTs, Javascript (using JS Flow),
XSPs, and Java.
7. Security
8. Search
(Security and Search are listed last because they were
broken/incomplete when I first encountered Lenya.)
Lenya borrows #5 and #8 from other projects. (Technically, #6 derives
from Cocoon, but Lenya obviously adds enough value to be a separate
project.)
JCR would eliminate #1 and possibly take control of #2 and #7.
With "eliminate", do you mean that the feature is removed or that the
feature is moved out of the scope of the project? IMO only the latter
applies. IMO a JCR repository becomes more visible, since you can access
it through a standardized interface. There are plug-ins for Eclipse to
browse and manipulate JCR repositories, you can mount it via WebDAV,
there are web-based JCR browsers … IMO this provides a better visibility
than our proprietary repository (which only offers a Java API that's not
nearly as well documented as JCR).
But of course I have to admit that this only applies if you can treat
the repository as a black box which works as expected. Otherwise you'll
have to resort to the maintainers of the repository implementation.
Which in our case could be another Apache project, which is IMO quite a
fortunate situation.
Lenya 1.3 uses labels as in "Labelled Versions" from:
http://wiki.apache.org/lenya/JcrContentModelAreas
The other options trigger my "bad design" alert system. I can explain
at length if nobody is emotionally attached to the other systems. The
rest of this post assumes a revision/label approach rather than using
Areas.
Maybe you'd like to reply to this post?
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05812.html
I don't have experience with the labelled versions approach, so I'd
appreciate if the JCR/Sling gurus could express their opinions.
The following explains integrating Lenya 1.3 with JCR; hopefully most
applies with other versions:
1. Use JCR's versioning and labels for Translations. The only purpose
of Lenya 1.3's Translation files is to define which version applies to
which label.
2. Use JCR's security. Lenya 1.3 will allow different access control
for the same document accessed through different Publications. I am
uncertain if this can be implemented with multiple AccessManagers or
requires special naming convention e.g. "mypub-username".
Also (from http://wiki.apache.org/lenya/JcrAccessControl ):
"Can only grant permissions, not revoke them"
may require thought. What happens when the security changes in Lenya?
Do we discard the current AccessManager and reassign access to all
documents; hopefully not a major problem but requires thought and may
be a performance issue.
That is definitely an issue that has to be thoroughly considered. My
current opinion is that we should use the standard JCR methods to
discover access control settings, but provide our own methods to define
and store them. I'm not sure yet, though.
Lenya would handle formatting.
Lenya would handle editing (mostly. WebDAV?)
WebDAV should be an option among others. Does anyone know if there's a
product that allows to run a WebDAV server on top of an arbitrary JCR
repository? Sling supports it, but I'm not entirely sure if they use
plain Jackrabbit or add some WebDAV-related functionality.
Lenya would business functionality.
Points of uncertainty:
1. Do we have a node for each Resource and subnodes for each
Translation? Or is each Translation a node and we need something else
to relate the Translations to the Resource? I will assume the
former for the rest of this post (since the latter requires much more
thought and work.)
This needs to be decided. I have outlined some possible approaches:
http://wiki.apache.org/lenya/JcrContentModelTranslations
2. Named Resources (Content)
Mostly migration and synchronization issues. Can we use JCR's UUIDs
without losing functionality?
That's a fundamental and important question. We can't use them the same
way as in Lenya 2.0 because in Lenya UUIDs and translations are
orthogonal, but maybe it makes sense to reconsider this concept.
The repository should be transparent to
Lenya. We should be able to import/export between any two
repositories without notice.
+1, that's an important requirement.
Best is if we can synchronize between
any two repositories. JCR's UUID is sufficient for documents created
in JCR, but documents created elsewhere will need their Lenya UNID for
synchronization. Using the Lenya UNID for all purposes may be easier
than using the JCR UUID for special cases. How does this affect
"Automatic referential integrity checks"?
A possible solution (has its drawbacks, though):
- Allow same-name siblings
- Use UUIDs for internal links
This way, you could merge
/foo
/bar [uuid=1]
/foo
/bar [uuid=2]
to
/foo
/bar [uuid=1]
/bar [uuid=2]
This way, we could at least merge first and clean up the URL space later.
What are we losing by not using JCR's functionality? See
http://wiki.apache.org/lenya/JcrContentModel
3. Named Resource (Design) - Design Resources require names. From the
example code, this should not be an issue. Again, what do we lose by
not using JCR's "Automatic referential integrity checks"?
Here's a statement against references:
http://wiki.apache.org/jackrabbit/DavidsModel#head-ed794ec9f4f716b3e53548be6dd91b23e5dd3f3a
IMO it depends on what we use the references for. I wouldn't use them
for internal links (because this would prevent all broken links, which
we currently handle by removing them from the live area). A valid usage
scenario would be a link from a translation to a node containing the
language-independent meta data, which can't be removed unless all
translations are removed.
4. WebDAV - Any editor bypassing Lenya poses a risk.
Hopefully every edit creates a new version seen by Lenya.
Yes, that would be the case. We could even add a layer for XML
validation, link checks etc. to avoid that invalid content enters the
repository.
Just because someone can
create a new Revision should not automatically allow the person to
publish it; does JCR allow a document to be edited without granting
the ability to assign labels?
AFAIK this is completely separated. Assigning labels is actually an
operation on the version history of a node. It is therefore somewhat
outside the "normal" session-based content management, I'm not sure
about the access control implications yet.
- Can we disable document creation without Lenya? Or force documents
to align with Lenya's DTDs?
Yes, we can do this using node type definitions and maybe a validation
layer.
Documents must follow the /Resource (with
type, identifiers and access control)/Translations (with
labels)/Revisions (based on the DTD of the Resource type). Will other
editors corrupt Lenya?
The repository model (node type definitions) should prevent this. We
have to put a lot of thought into this, making it flexible enough for
all desired purposes and rigid enough to be safe on the other hand.
Proper research would answer most of my questions. Lenya 1.3 will
gain JCR support. JCR integration should require about one week of
work after Lenya 1.3 is completed. I am unlikely to have implement
this until sometime next year.
Back to the main question:
What is Lenya?
If JCR handles many functions of a CMS, what value does Lenya add?
I think it will be the combination of JCR, Cocoon and our experience
that will separate us from the rest of the CMS systems. My goal would be
to reduce the codebase for all standard functionality like storage
facilities and concentrate on providing a very good user experience in
the following areas:
- first of all, editing content (WYSIWYG editor integration)
- asset management
- flexible workflows
If Lenya only supports JCR, how is Lenya different than other JCR-based CMSes?
The front-end, the customizability and extensibility should make the
difference. There are not that many JCR-based WCMSs around, most systems
focus on document management. Lenya's strenghts lay in the management of
structured content. Thanks to Cocoon, we also have very flexible layout
and cross-media publishing capabilities.
(My last post explains why I feel keeping the file-based repository is
important, but the parent post implies this is an either/or decision
rather than additional functionality.)
Apart from the question of maintenance:
If we keep the file-based repository, we either have to limit the JCR
integration to the features offered by the file-based implementations
(for instance, what about SQL and transactions?) or we'd have to
introduce a concept of repository compliance. The latter option would
for example mean to throw an OperationNotSupportedException if a user
issues an SQL query on the file system repository.
To me, both of these options seem to be a serious limitation.
Particularly, I consider transaction support as crucial (especially
since we almost lost a potential customer because of the lack of this
feature).
What do the others think?
Hoping this post was not irrelevant or confusing,
On the contrary, the topic is far too complex not to consider all
thoughts and potential implications. Thanks for joining the discussion!
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
