On Apr 2, 11:31 pm, Massimo Di Pierro <mdipie...@cs.depaul.edu> wrote:
> Hi Yarko,
>
> thanks for all your work recently. I am particularly interested in
> your work about layout.html. It is already in trunk and it will be in
> stable but I face some recurrent problems (even with previous version)
> and perhaps we can do even better.
I'm very sure we could... in fact, I sent you some "really far out"
ideas privately ;-)
>
> every time I make a new app and change layout and or css I have to
> copy div.flash{} and div.error{} from base.css to the new style.css.
> This is getting annoying.
I see - yes.
> I am thinking about:
> 1) one file with just ez.css
==> yes, so we keep it "as distributed"
> 2) one file with div.flash, div.error
==> maybe ... what would be the abstraction, the "glue" that says
"this kind of thing should be in this file"? I'm not clear on your
intent, but go with it, say more...
> 3) one file with calendar.js
==> yes.
> 4) one file with everything else (base.css) to be replaced is a custom
> layout.html is used.
If you mean for base.css to not be "replaced", but possibly be
inherited form, over-ridden by a custom layout, yes.
Otherwise, I would want to be sure things that gluon might depend on
(e.g. css for form control) would be guaranteed to be there;
Would "base" and "std" make sense? std you could completely
replace; base should always be there.
Anyway, in practice this may prove unnecessary, but I would be more
comfortable if we start out with that concept: fundamentals that are
always there (you can override them but the classes / ID's there
should be guaranteed to be defined; and other stuff you can replace
if you want for new layouts.)
Does this sound like it makes sense?
I think this will enable "helpers" from gluon that manipulate css,
that we can depend on being there (similar to html helpers, perhaps
something for form control.... not sure what else there would be -
perhaps layout helpers too??? --- we'll see).
> This should use as much as possible of jquery.ui
> conventions.
==> yes.
>
> what do you think? how about we unify 1+2 or 1+2+3 or 2+3?
==? I'm not following; by unify, you mean combine these files? Well,
for development .... meh.... for deployment: a combiner / minimizer
tool might be nice. Thiink about updating css / layout from the web
admin interface, and then having a "compact" option; to have that,
you would have to have the un-compacted stuff there at some point,
no?....
>
> what about the css convetions in SQLFORM(formstyle=...)? If I commit
> this the canny be changed?
I very much like the idea of "layout / style" helpers for forms (form
as a visual entity) .... don't understand the end of your sentence,
sorry.... :-/
>
> Massimo
Yarko
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@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.
