On Jul 6, 3:40 pm, Aaron Watters <[email protected]> wrote: > > 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. > > 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.
in js a page can consist of more then one request, so you display the page and then ask the server for the secret word depending if he is logged in. What i think would produce overhead in WHIFF is "can i get you some coffee while you wait" pages where there is a multi threading js interaction running multiple things at the same time like for example uploading a file and showing a progress bar http://code.google.com/p/appwsgi/source/browse/trunk/appwsgi/www/lib/upload.as > I'd also like to note that by using javascript > or XSLT you are not really making the page > language independent -- instead you are becoming > dependent on languages which are sometimes > implemented in different ways on different > browsers. And you are also usually making it harder > for search engines to scrape your pages. js / as3 interpreters are evolving very fast right now and all do there are still browser issues, all mayor players are on the right track. Search engines can be redirected to raw data. > "XSLT: a bad idea, poorly designed, > inconsistently implemented." -- stolen from somewhere For me XSLT is CSS the wrong way. <xsl:for-each select="catalog/cd"> <tr> <td><xsl:value-of select="title"/></td> <td><xsl:value-of select="artist"/></td> </tr> </xsl:for-each> Conclusion i am sure you can do everything in WHIFF but i am also sure i can do everything in js :-) So its all up to the photoshop flash silverlight javafx and html guys what they like, so don't forget to ask them, because they are the people who are going to use it the most. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
