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. 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. > > > > > >>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? salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
