I hadn't considered extending the Form class on my own. How would you do that?
As a side note, I believe a form requires the fieldset and legend attributes to be valid. I could be wrong, however, and it may only require your inputs to be in a block-level element like <p> or <div>, but that wouldn't be following semantics very well. I took a closer look at the source and noticed that the preferred way of using the class is to combine it with a template. This means that technically the Form class only needs to create fieldsets and legends instead of a table, so the <form> details can be plugged into the template. The one issue I have with changing the source to fieldsets is that the "section" of the form needs a heading string to go in the <legend> element. Would it be acceptable to give Form a header attribute that must be set in order to name the section (and if omitted just results in an empty <legend>, which is valid but semantically worthless)? I'm still new to the whole OOP thing, but am interested in helping web.py improve. On Feb 19, 1:52 pm, Justin Davis <[email protected]> wrote: > From my experience, not wrapping the content in a form tag makes it > more flexible to add inputs within a template. If you wanted to put a > couple of different buttons inline, for instance, it's easier to just > code them up in the template. You can use a fieldset and legend if it > makes sense to you, or skip it. > > If rendering is an issue, I recommend subclassing class Form and > defining your own render method. > > I consider one of the greatest assets of web.py is that it's small > enough to read the code and actually understand everything that's > going on. It's pretty cool that the render method for forms is less > than 20 lines long. It's small enough that you can use it as a > starting point for a new render method and not feel like you need to > remove unneeded stuff first. > > Cheers! > Justin > > On Feb 19, 7:49 am, Daniel Campbell <[email protected]> > wrote: > > > > > While reading the documentation for web.py I noticed that the form.py > > module renders forms in a table, which is not semantic and doesn't > > adhere to W3C standards. The proper structure of a form is as follows: > > > <pre> > > <form action="$url" method="GET|POST" name="foo"> > > <fieldset> > > <legend>insert form section header here</legend> > > insert your form inputs and buttons here > > </fieldset> > > </form> > > </pre> > > > If you don't mind my asking, why were tables chosen? They don't follow > > the proper structure of a form... as far as I could tell from the > > source, the form element isn't used at all; I'm surprised the forms > > even function. > > > I'm somewhat new to web.py and I enjoy it so far, but this sort of > > rendering bugged me. If you want, I could see about modifying form.py > > to adhere to W3C standards. In its current form (no pun intended :P), > > it will not validate with w3's validator, and may not render properly > > in all browsers. > > > My apologies if the code example I provided doesn't display properly; > > there isn't a preview function here at Google Groups. -- You received this message because you are subscribed to the Google Groups "web.py" 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/webpy?hl=en.
