hmm, this seem to follow what we've now done for form.custom On Sun, Jul 5, 2009 at 7:44 PM, Jonathan Lundell<[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
