Andreas Hartmann wrote:
Doug Chestnut wrote:
[...]
I prefer the "publishing single documents" approach. Even though the
sitetree file handles the mapping for us, I still see this as metadata
which belongs to the doc (doc has these parents, and has these children).
I also thought about storing the hierarchy information in the document
meta data, but discarded this for the following reasons:
- it wouldn't be possible to have non-document site nodes anymore,
which is quite convenient (e.g. to group media libraries, reusable
content items etc.)
Why try to make them "non-document"? Just make a doctype for them, and
then you can automagicly link to them from editors, index them with
lucene, map them in the navigation, etc...
- we would need sophisticated cache for performance reasons, and this
could be quite complex to implement
Right now our sophisticated cache is the sitetree file. why couldn't
this remain our cache for now with the possibility of upgrades to come.
It could be updated as docs are modified.
--Doug
The problem with this approach is when someone shuffles around the
sitetree in a really cool sitetree editor usecase, then they have to
publish each doc they moved individually. Perhaps if such a "sitetree
editor" usecase existed, the user could shuffle the site around, click
submit, and then get a list of changed docs with the option of
publishing.
Yes, I guess we would find a usable solution.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
