Thorsten Scherler wrote:
El mié, 21-09-2005 a las 10:17 +0200, Felix Röthenbacher escribió:
Josias Thoeny wrote:
On Tue, 2005-09-20 at 17:17 +0200, Andreas Hartmann wrote:
Josias Thoeny wrote:
[...]
Or should there be no sitetree attributes at all, only meta data?
IMO yes, there should be only meta data.
One could argue that the sitetree is just a view of the data, and the
visibility is a property of the view, not of the data itself. But I
don't know...
I tend toward seeing the visibility of the data as a property of the
data itself and not as property of the view. There's the general
MVC concept, to separate the view and the model. Still, I think it's
viable to store the visibility in the model, rather than introducing
another model for the view.
I disagree. The model should be free from presentation logic. Visibility
is presentation logic which could be changed for certain roles or
workflow situation. I agree with Josias that it belongs to the view.
Maybe you mis-understand me: if a document should be visible or not is
a core attribute of a document, especially if the data model is a
CMS data model where it is all about document presentation.
Comparing the sitetree with a db table makes this clear. In a table you
will not define whether something is visible or not. You would include
the column in your SELECT statement of the view or not.
... based on a visibility row in your database table.
The problem about meta data is that they can't be resolved during
site structure traversal, e.g., in an XSLT that is applied to the
sitetree.
We could add a transformation to the sitetree which adds the meta data
as attributes (or a particular subset of the meta data). With JCR,
the performance issue might be secondary.
Our experience with the jcr sitetree (each sitetree node is represented
by a jcr node with properties) showed that the performance could be a
problem. The generation of navigation elements (e.g. the menu) was much
slower than with the in-memory dom sitetree. But it also depends on the
number of nodes.
The poor performance mentioned above was a problem of how the
jcr sitetree was implemented (every sitetree or sitetree node access
was translated to a call to the jcr node). The problem may be tackled
with an appropriate caching implementation. The acceptable performance
of today's sitetree implementation is mostly based on the caching
behaviour of the DOM implementation.
Can you extend a bit how you think we can introduce a caching mechanism?
Does it makes sense to use SAX instead?
I'm not up-to-date how much caching is done in JCR already. Maybe that
improved in the meantime. Another possibility would be to cache the
JCR node while registering an observer for the node to get notified
when the node has changed. Certainly, some more investigation is needed
for this topic.
- Felix
salu2
--
Felix Röthenbacher [EMAIL PROTECTED]
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
