> > [...I like WHIFF configuration templates because] > > > > 1) It is tightly bound to WSGI features. > > 2a) A configuration template defines a WSGI app with > > any number of named arguments. > > 2b) It permits "includes" for WSGI middlewares and apps > > with any number of named arguments which may be > > defined by other templates either embedded or included. > > 3) It doesn't overload the HTML <tag> syntax which always > > leads to unreadable catastrophe in my experience. > > I like the Django templating system for pretty much the same reasons
The Django templating system is very nice and a lot easier to use for many purposes than WHIFF configuration templates. As I said before and wrote in the WHIFF docs, it would probably be a good idea to use other template engines with WHIFF for other/simpler purposes. I plan to implement WHIFF middleware to make it easy to use Mako where appropriate, for example. Nevertheless, the "include" and "using" directives from the WHIFF config templates are quite a bit more powerful than the "include" and "extend" constructs from the Django templates (and other template systems that I know of) which is especially useful for *configuring* middleware (hence the name *configuration* template). Taking an example modified from http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1500.who which authenticates the user and then sends different content based on whether the user is logged in or not: {{include "who"}} {{include "onStatus"}} {{using loggedIn}} You are logged in as {{include "uid"/}}: <a href="login_url/logout_handler_path"> logout or log in as a different user. </a> <br> THE SECRET WORD OF THE DAY IS "APPROBIUM" {{/using}} {{using unknown}} You are not logged in: <a href="login_url/form?came_from={{get-env whiff.app_path/}}"> login. </a> {{/using}} {{/include}} {{/include}} Here the "who" middleware does the authentication and after authentication delegates the reponse to its argument which is implemented by the "onStatus" middleware which decides whether the user is logged in and then delegates to its response to either the "loggedIn" argument or its "unknown" argument. The "loggedIn" and "unknown" arguments are "middleware streams" which include literal text and other directives. I don't know how to implement this functionality in a simple way using other template engines, including the Django engine -- but this may well be due to my ignorance. Please inform. -- Aaron Watters PS: By the way, you can't implement the above functionality in a comparative way using XSLT because if you did you would have to send text to the client that *shouldn't* be sent to the client because the client is not *authorized* to see it -- clients which are not logged in should not see the secret word. === I want to achieve immortality by not dying. -- Woody Allen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
