session.flash does only one think in web2py: it gets moved into
response.flash upon redirect. If you want you can do already
#in model
from gluon.storage import Storage
session.flash=Storage()
response.flash=Storage()
#in controllers
#before redirection
session.flash.warn='oops'
#or without redirection
response.flash.warn='oops'
and in your layout you do:
{{if response.flash.warn:}}<div class="warn">{{=response.flash.warn}}
<div>{{pass}}
etc.
I do not feel there is anything more that needs to be implemented in
web2py. It is already very general.
Massimo
On Apr 19, 1:08 am, Yarko Tymciurak <yark...@gmail.com> wrote:
> I think flash is different than hardcoded colors of layout in css...
> These are context-sensitive things, and logical (maybe you are right - in
> css) definitions seems appropriate.
>
> On Sat, Apr 18, 2009 at 8:28 PM, Iceberg <iceb...@21cn.com> wrote:
>
> > Nice brainstorming. Hope you don't mind I add some more summary.
>
> > 1. Hopefully we can at least have an agreement about controllers
> > should have easy way to express info, warn and error. This is about
> > logic and design.
>
> > 2. As to how to customize those three message's appearance, this is
> > about technical implementation. Yarko suggests an approach which
> > defines some response.warning (actually he means
> > response.warning_color) in model/0.py, that is fine. But to me, it is
> > slightly, unnecessarily complicated, it is not KISS enough. Because we
> > can easily customize the style.css when needed.
>
> > Hardcoded colors sounds stupid, I know. But after all, all the entire
> > web2py appearance are hardcoded in style.css, no one complains about
> > that. That is because, those kind of things are supposed to be in css
> > level, even hardcode.
>
> > On Apr19, 3:49am, Yarko Tymciurak <yark...@gmail.com> wrote:
> > > this too sounds good...
> > > In fact, controller should have some LOGICAL (name as opposed to hard
> > code)
> > > representation on level of / kind of "flash", and this is why in my
> > earlier
> > > post I took Iceberg's code, and changed to some name (flash.warning,
> > etc.)
> > > and commented: "defined in models/0.py" --- which structurally may not
> > be
> > > the right place - but mearly where things are always known to be read /
> > > loaded per-request (which is why in pycon registration we put a lot ... a
> > > LOT of configuration settings in 0.py)..
>
> > > Ignoring that models is all read as a mere technicality, as this (any
> > tool
> > > or common or configuration item) is not at all a model thing, there does
> > > need to be a place to hold common application variables and settings....
> > if
> > > not in variables, then in classes that encapsulate the variables and
> > > statically hold them.
>
> > > So - I'm now thinking that both Massimo's and Icebergs latest comments
> > need
> > > to be merged.
>
> > > Regards,
> > > - Yarko
>
> > > On Sat, Apr 18, 2009 at 10:32 AM, Iceberg <iceb...@21cn.com> wrote:
>
> > > > Well, I had similar thoughts as Massimo at the beginning, and that is
> > > > exactly why I "stop here", and even use hardcode magic color.
>
> > > > IMHO, a controller should be able to clearly express general info,
> > > > warning msg, and bad error. Because they are so commonly needed in
> > > > EVERY web app. If you think you don't need to separate them from each
> > > > other, you are wrong. I observed users of my app tend to ignore
> > > > warnings even errors because they just look same in a glance, all are
> > > > a long sentence of blah in an orange bar. If we change info to be in
> > > > green, warning in yellow, error in red, that will certainly catch
> > > > immediate attention.
>
> > > > As to the colors, I think they are not important in the controller.
> > > > Actually, from a traditional MVC angle of view, controller should not
> > > > care about color at all. So I leave them into the View part,
> > > > developers can change them via css and/or layout.html to customize
> > > > color, location, animation, background pic, round corner, ...
> > > > whatever.
>
> > > > So, please, at least we need a way to show info, warn and error. If
> > > > you don't like the convention (protocol) I suggested, how about these?
>
> > > > In controller:
> > > > response.info='OK, data is accepted'
> > > > response.warn='Input is unusual but anyway data is accepted'
> > > > response.error='Something is wrong'
>
> > > > In layout.html:
> > > > {{if response.info:}}
> > > > <div class='info'>{{=response.info}}</div>
> > > > {{pass}}
> > > > ... (you get the idea)
>
> > > > But sure in this way, Massimo need to change more than one file in
> > > > web2py. But if he agrees to do so, it is definitely better than my
> > > > original proposal. The only downside is these new controller code
> > > > will not work on older version of web2py, but who cares. //shrug
>
> > > > On Apr18, 11:36am, Yarko Tymciurak <yark...@gmail.com> wrote:
> > > > > Sounds good...
> > > > > Then the answer is: if you want to customize, make your own layout
> > for
> > > > your
> > > > > app, which is completely reasonable as far as I'm concerned.
>
> > > > > Simple is better.
>
> > > > > On Fri, Apr 17, 2009 at 10:07 PM, mdipierro <mdipie...@cs.depaul.edu
>
> > > > wrote:
>
> > > > > > This is not a simple one. This change implicitly defines a protocol
> > > > > > for customizing flash. I do not object to it but if we go this way
> > why
> > > > > > stop here? why only color and not location? type of flash
> > animation?
> > > > > > round corners?
>
> > > > > > Personally on the one side I want a default layout as simple as
> > > > > > possible so that pepole can use it as an example to buil others.
>
> > > > > > On the other side I would like a more complex and comprehensive
> > > > > > protocol for customizing various "optional" aspetcs of the layout
> > so
> > > > > > that people will be able to download layouts (like in Drupal) and
> > drop
> > > > > > components in it.
>
> > > > > > I think this needs more thought but I am happy yo hear more
> > opinions.
>
> > > > > > Massimo
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
