Andreas Hartmann wrote:
Doug Chestnut wrote:
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 could of course require that, but I wouldn't like to invest
the effort of creating a resource type for a document which contains
nothing ...
Hmm, I guess I don't really understand your usage.
Don't tell the catalogers at the library that metadata is nothing ;)
Examples I have in mind ( where the xml content might simply be <null/> ):
External link resource:
-ability to maintain a library of commonly used links in a publication
-live view gives a redirect
-addExtRes usecase gives users in an editor the ability to add a link to
their doc (which is stored as xinclude) and gives them the option to
pull meta from the link
-dc meta stores all the info for the external resource
Collection resource (although this could also contain content of it's own):
-ability to present other documents as a collection (html, rss,
slideshow, 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.
Well, it would have to be updated ...
It's always more complex to keep two redundant data stores in sync
than use a single data store.
I am not fixed on any one method, just throwing out an idea ;).
--Doug
-- 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]
