Doug Chestnut wrote:
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)
Almost forgot another doctype todo on my list. It would have data, but
I need it to be able to add multiple nodes to the sitetree:
Flickr resource
-add flickr key, list image search criteria in the editor.flickr usecase
-each image is treated as a node in the sitetree (ability to add image
to a document via the insert.Image/Asset usecase)
-map a flickr set as a collection node
This resource would have to be able to extend the sitetree with an
external sitetree (no live/authoring area, pulls from flickr).
I can hack this together, but it would be cool if we could have a way to
add external services to our site structure.
- we would need sophisticated cache for performance reasons, and this
could be quite complex to implement
Would this really be a performance hog?
To get the path of any document:
getPath(doc) {
path = "/" + doc.getName();
parentdoc = doc.getFirstParentDoc();
if (parentdoc.exists()) {
parentdocpath = getPath(getPath(parentdoc));
path = parentdocpath + path;
}
return path;
}
I guess that there wouldn't be a large performance hit as long as each
doc knew all of its parents and children. This mapping would probably
be complex to maintain though. Is there something that I am missing?
As a site gets large, the single sitetree map becomes a performance hog
as well.
--Doug
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
