Alberto Valverde wrote: > Jorge Vargas wrote: > >> On Fri, Jan 16, 2009 at 9:58 AM, Mark Ramm <[email protected]> >> wrote: >> >> >>> I think this is a good idea. It adds a little bit of complexity to >>> the template side of things, but we can use a widget in the >>> master.html to do the flash message via javascript so things can just >>> work out of the box. >>> >>> If it's done right away, it can go into tg 2.0, if it takes a bit I'd >>> support a switch from the current flash implementation to this in >>> 2.1. >>> >>> I wonder if it could be put into webhelpers rather than into a seprate >>> library, since its a generally useful pattern.... >>> >>> >>> >> am I the only one concern by the fact that this will require JS on ALL >> TG2 apps to be enable? >> > I think that nowadays all *webapps* (as opposed to *webpages*) require > JavaScript anyway. Flash is mostly used in the former so I think that > the advantages (cacheability, making servers state-less (or avoid having > to sign marshalled sessions in cookie)) fairly outweight the minor > disadvantages that requiring JS imposes. > >> How about make it a "second implementation" in a configurable way? so >> you could either use the session or js thing, kind of like how beaker >> swaps backends? >> > That is easier said than done ;). Anyway, the interface I've implemented > [1] can be extended to support fetching the cookie from the request > (please keep it a simple cookie so no sessions are needed) so... I'd > happily accept a patch to add a ServerFlash subclass to add that > functionality. But please: don't add new dependencies (currently only > the stdlib is required if python 2.6 is used + a response object that > has a set_cookie(name, value) method (eg: webob's)) and keep it portable > across any WSGI framework. > >
I've finally integrated WebFlash (that's the name of the library I've release implementing this) into TG2 at: http://trac.turbogears.org/changeset/6112 Some notes: * Released at PyPI, should be added to TG2's private index (http://pypi.python.org/pypi/WebFlash/) * Due to popular demand, I've added support for flash without JS. * The transport mechanism has changed to be a plain old cookie instead of the session. This enables users to display the message more easily from JS code and allows the use of TG2 without sessions. * Code is unit-tested (both the JS part and the python part) and documented. * The JS part has been tested to work under under IE6, IE7, Safari, mobile Safari (aka: iphone), Chrome, Opera and Firefox 3) * All of TG2's unit-tests pass without any modification. So, in theory, no backwatds incompatible change has been introduced Instructions: To enable JS-only flash (recommended, but YMMV) you need to change your master template: Change: <div id="${tg.flash_status}" py:if="tg.flash" class="flash" py:content="tg.flash"> </div> To: ${flash.render_genshi("some_id")} <div id="some_id" /> That's all, the 1318 of minified JS code to support that will be inlined in a <script> tag. If you don't want this code inlined you should: a) Add a controller method that serves the file whose path is stored at flash.js_path and add a <script> link to it. b) Add this somewhere in your <head>: <script type="text/javascript" content="XML(flash.js_call('some_id'))" /> b) Tweak the CSS since the DOM structure the JS version generates is slightly different. If someone wants to cook a widget or something for this or add a config option so TG can use one or the other or something the community will appreciate it (hint, Jorge, hint ;) One more thing: I'd finally like to change the DOM structure and CSS of the quickstart template to match the structure generated by the JS version. Mainly so both versions can be used interchangeably and because the current one sucks ;) Why? Because: 1) The class of the message should be conveyed in a... class attribute. The current implementation makes impossible to refer to the *unique* div that holds the flash in a reliable way from JS code. The id should remain static, the class should vary with the kind of message (not the other way around) 2) If the flash message is wrapped in a div inside the "flash" div then one can implement floating centered messages easily. To make it easy to visualize, the dom structure that the js code generates is like this: <div id="some_id_of_your_liking"> <div class="status_code">Message</div> </div> So the CSS style this could be something like: #some_id_of_your_liking { display: none; /* Recommended so a conditional can be avoided, the JS code will make it visible */ ... } #some_id_of_your_liking .ok { ....} #some_id_of_your_liking .warn { ....} #some_id_of_your_liking .error { ....} Please strip the status_X prefix from the status code names, it is redundant to say: flash("lalalala", status="status_ok") much nicer (IMHO) and less typing (mathematically provable): flash("lalala", status="ok") If no one object I'll implement these *slightly* breaking changes (for existing users) tomorrow. Note that the default will still be non-js flash messages, I'm just proposing to change the dom structure and CSS to keep both in sync so it is easy to change between them. Enjoy, Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
