On Wed, 2010-12-29 at 15:42 -0800, Mike Orr wrote: > On Wed, Dec 29, 2010 at 1:28 PM, Marius Gedminas <mar...@gedmin.as> wrote: > > On Wed, Dec 29, 2010 at 10:56:29AM -0800, Seth wrote: > > The docs say that messages don't have to be strings, so you can do > > exactly that, if you push dicts like this: > > > > request.session.flash(dict(message='Hello!', queue='welcome')). > > > > Or you could push tuples. Or a custom subclass of unicode with a > > 'css_class' attribute -- just make sure it's pickleable. > > Hi there. I wrote the flash code for WebHelpers, then somebody (I > can't remember who) asked for categories and we expanded it, then I > adapted it forPyramid's central session object, and Chris modified it > to the current version. It has multiple queues because the WebHelpers > concept of multiple Flash objects is non-viable with the flash > integrated into he session. I initially kept categories, but then > Chris and I decided to drop them because queues cover almost the same > purpose. The only thing you can't do without categories is to mix them > (i.e., display an INFO then DEBUG then ERROR then INFO, in whatever > order the messages were pushed). It seemed unlikely people would want > to do that anyway for web display; rather they'd want to show all the > errors first, then the infos, then the debugs, which you can do with > multiple queues. > > The messages are intended to be strings, but this is not enforced. I > couldn't think of any specific use case for non-string messages, but > users always come up with unanticipated uses so I didn't want to > prevent those. (Queue names have to be strings because they're > concatenated to a constant string to create a session key.)
There is actually at least one immediate use case for nonstring values: Pyramid "translation strings" (which are a subclass of unicode, but carry around more info). As currently implemented, you can just jam one into the session and localization will "just work" when one is pulled out of flash and displayed within a template (at least a Chameleon template). I like the compromise we came up with so far, because it allows for a wide variety of use cases without requiring additional code. - C -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
