I do not see why anybody would use helpers this way. the purpose of
helpers is not producting HTML code but provide a serverside
representation of the DOM. Breaking a <tag></tag> into two separate
object just breaks the mechanism.
Massimo
On Jul 5, 12:38 am, Jonathan Lundell <jlund...@pobox.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
