-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Guys,
Henri Kaukola wrote: | We've been thinking about a new component that would list | the latest changes on the whole site/part of a site. | It would be a great feature to this component to offer | a dynamic_loadable interface (i.e. /mytopic/latest/5) which | could be used on frontpage or sidebar of a site. | | The content tree traversing would be similar to the | d.l.sitemap, which still lacks some crucial features | like ViewerGroups support. | | So, I'd vote for making a helper function for traversing | a content tree. Then both d.l.sitemap and the "latest updates" | components could use it as the basis (to build a gigantic array | or something). | | Another alternative would be to make NAP be aware of the | latest documents (articles/topics) in the given tree | (this could be from the site root or any topic in the tree). | This might be the most efficient way to do it, since NAP | has to traverse the tree all the time anyways. | | Torben, any comments?
Yeah, you think I want to loose my nitpicker image? ;-)
First of all, NAP is the helper function of traversing a content tree. It was built for that, and just does that. That it does not inherently support viewer groups, is a NAP problem, not one of the elements build on NAP. Again, instead of building these checks into each and every place, NAP should check this even when loading NAP data, so that the Sitemap would only see what its allowed to see.
For this to work, we'd need: ~ * A central place where Authentication and Authorization is done (again). ~ Yes, I know that I still owe you an mRFC for that one. ~ * A reworked and cleaned up NAP, that does honor these checks. Needs some OO ~ rewrite, which will be done within the next few months while I mess around ~ with NAP anyway. ~ * Finally, an NAP cache. This gets more and more important as NAP information ~ grews more and more complex.
Especially when the 3rd point of the above list is done, one new thing gets really interesting:
What would be helpful, are functions that give you various "ordered" lists of all NAP objects, so that you f.x. can tell NAP "give me a list of all NAP objects ordered by creation date". This will give then a flat list of all objects ordered by any valid NAP key (including Metadata at a later stage). Of course, this will take a bit of time, which is why caching gets really important.
A "show latest changes / new articles" component wouldn't be bad, in fact I've been looking for somebody build it for quite some time now ;-). I don't think that it is feasible on sites which are uncached or have a high change frequency (so that the cache is ineffecitve), but otherwise it should be fine. Some requirements: ~ * All component styles could have some kind of a "teaser" substyle, as the ~ normal page style will most probably not be suitable for such a listing ~ * Alternativly, you could just show the NAP title, some kind of ~ "$article_name in $topic_name" listing ~ * The (power?)user might be able to select between these two behavoirs. ~ * You need to be able to exclude items from the traversal, mainly to hide ~ stuff like the Homepage or some special topics. ~ * The ViewerGroups implementation (or any additional access checks) should, ~ as written above, be made by NAP already, but we don't live in an ideal ~ world. We might need some intermediate helper code therefore.
Just some thoughts.
Live long and Prosper! Torben Nehmer
- -- Torben Nehmer, Guenzburg, Bavaria, Germany http://www.nathan-syntronics.de, mailto:[EMAIL PROTECTED] PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB+JtaJPh4Kn6d5FYRAiNgAKDbHY4jtRDY2rE5wQlqbybntC6rVACfYNSp UKGWac0kvnjTFmoGGc3ZMbU= =gEOM -----END PGP SIGNATURE-----
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
