On Jul 4, 2009, at 4:36 PM, Yarko Tymciurak wrote:
> this seems obtuse...
>
> If arguments aren't used in this form of "helpers" then why not just
> use the html? (why do you need a helper?)
>
> I may be missing something.
The arguments are used (though not all of them, if close=True).
I'll defer discussing the entire rationale until (Real Soon Now) I'll
describe a mechanism for handling better generation of valid html/
xhtml. This stuff relates, at least peripherally.
>
> As for the parameters, if indeed this is of use, why not something
> like
> BODY() ... as is now
> BODY.open(args to your heart's content)
> BODY.close()
>
> This is (at least) more readable and explicit in the code, and -
> heck - the helpers are all classes...
>
> You can extend them now.
That's a good idea, I think. I'm a relative Python novice, so it
wasn't obvious to me how to do that efficiently, but I think I've got
a handle on it: making open & close class methods of DIV looks to me
like it would do the trick.
>
> - Yarko
>
> On Sat, Jul 4, 2009 at 5:58 PM, Jonathan Lundell
> <jlund...@pobox.com> wrote:
>
> I propose to add a "close" argument to the html helpers (gluon/
> html.py).
>
> 1. If there's no close argument, then the behavior is identical the
> current code.
>
> 2. It's an error to specify close= for a self-closing tag (like <br /
> >), or to give it a value other than True or False.
>
> 3. close=False suppresses the closing tag. The opening tag, attributes
> and components (if any) are output normally.
>
> 4. close=True suppresses the opening tag and attributes. The
> components (if any) and closing tag are output normally.
>
> The general idea is to make it easier to use helpers when output is
> being generated sequentially (as in welcome/views/layout.html, for
> example).
>
> While I assert that this change is generally useful, it will also
> support a proposal I intend to make aimed at making it easier to
> generate valid xhtml (or html) code (without breaking legacy
> applications).
>
> Usage, in the simplest case, would be something like this:
>
> {{=BODY(close=False)}}
> ...
> body content goes here
> ...
> {{=BODY(close=True}}
>
> This is meant to be an enabling feature only, with no enforcement
> other than syntax. In particular, there would be no attempt to
> prohibit a close without an open, or the like.
>
> I don't expect that component args will typically be used in this mode
> of operation, but I see no reason to prohibit them.
>
> In the future, my plan is that HTML() would be smarter about
> generating its DOCTYPE, and I want to encourage that use, which is
> currently impractical (I think), since you either have to be prepared
> with all the components, or else create and then edit (extensively)
> the HTML object.
>
> Discussion is welcome. I'd prefer a syntax along the lines of
> BODY(open) and BODY(close), but I don't see a straightforward way of
> doing it.
>
> If there's no objection, I'll create a patch.
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
