Hi, > | 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. > > Bergie asked me to remind people about MIDCOM_NAV_VISIBLE, > that is available in NAP. Basically all components should > check for true/false before displaying anything. This check > takes into account the ViewerGroups settings. But does it care about article approved? T > Cheers! > > ~ //Henri > > > | 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 > > > > > - -- > Henri Kaukola [EMAIL PROTECTED] > Consultant Tel: +358-20-198 6037 > Nemein Oy http://www.nemein.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFB+Lvr3xWc2AolrKgRAq/hAJ4tB7fNJ+S1vfSi/kDsPBUphggTNwCdFLIM > 4dOIfhng9RSGuXkRHw8jM4w= > =7sfL > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Tarjei Huse <[EMAIL PROTECTED]>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
