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
-~----------~----~----~----~------~----~------~--~---

Reply via email to