Hi! I'll comment on ways how you can convert your current infrastructure to AxKit, but I do not claim universal truth - there are other ways of doing these things.
On Thursday, 13. June 2002 07:31, Ward W. Vuillemot wrote: > I have a basic templating system. . .with the separation of content, > layout, and language in an infinitely nested manner so I can build quite > complex layout from basic components. Content is typ. supplied from a > db connection, layouts utilize HTML and language (e.g. English, > Japanese, etc) is in simple text files that I parse into memory using > Config::Simple::Extended. Nothing fancy, but it is a work in > progress. . .and a project to learn db, mod_perl, et cetera. Content from DB can be accessed via XSP using the ESQL taglib or using DBI directly. Alternatively, if your db queries are very uniform, you can write a provider which executes these queries and generates some kind of XML document from the results. That way, you get cache control (by telling AxKit if the cached document is still valid). XSP, OTOH, is always uncached. A request of an XSP based solution would look like: http://foo.bar/view.xsp?entry=123&page=2 while a provider-based solution can be made to look like: http://foo.bar/view/123.xml?page=2 (lots of different interpretations of the URL are possible here) Layouts are best kept as XSLT style sheets, which finally outputs XHTML. XSLT needs getting used to, though. Alternatively, you can use XPathScript, which is more Perlish, not so XMLish, but I don't know how performance is in long transformation pipelines. Language can be done via style sheets as well, maintaining a translation mapping in XSLT is easy once you have a skeleton XSLT for that. If you want to reuse your current data files as-is, XPathScript can be made to read and use them. Once you are this far, you can setup any transformation pipeline you want, layering as many style sheets as you need, even dynamically (to some extent). > On top of this, I have very nice authentication and authorization models > that work on multiple levels to restrict/grant access to users, > userlevels, groups, and ip addresses to apps, tables, and table > fields. . .and I do _not_ want to lose this. :) You should definitely look into the Session plugin, as it comes with a very flexible authen/authz framework. Out-of-the-box, it supports access control via httpd.conf/.htaccess based on users, groups and levels. Adding a new authorization scheme (e.g., your IP-addresses based one) is as easy as subclassing and implementing 3 methods (check access, serialize, deserialize). Implementing different privilege storage is easy as well, subclass and override two methods (load, store). As a result, you get various fields in $r->pnotes telling you what the user is authorized for which you can access freely. And to make that even more useful, you also get a taglib which deals with all the auth data, query, modify, test access. I will help you in any of these steps if you want to try it, since I am curious myself how well it works in a real-life case - I only ever used the defaults, never subclassed it. -- CU Joerg PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
