Thorsten Scherler wrote:
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.
I also think that it should belong to the view and not the actual
data. There can be many different views/maps of the actual data, just
as one has different maps in geography.
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.
agreed. I am not sure if some of the problems could be solved
by using the same principle as we currently solve with XMLHTTP, meaning
that stuff is being loaded incrementally. This makes sense especially
re scalability.
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
