On Jul 4, 2009, at 11:34 PM, mdipierro wrote: > > 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.
I'd like to try to persuade you that the helpers serve another purpose: abstracting html code generation. The helpers are already used piecemeal in existing applications to generate fragments of html without creating the entire DOM. The adding an open/close option does nothing to impair DOM representation, but it gives us an abstraction layer that will be useful for generating valid xhtml/html code down the road. Let me make the larger proposal, and it'll be clearer where the open/ close detail fits in. > > Massimo > > > On Jul 5, 12:38 am, Jonathan Lundell <[email protected]> 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 >>> <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
