I have no objection to that, and I'll do the release prep this weekend and a beta early next week, so this will be another great feature to plug in our next beta.
On Sat, Jan 17, 2009 at 2:42 PM, Alberto Valverde <[email protected]> wrote: > > 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 > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
