On Fri, 2011-06-24 at 13:54 -0500, Matt Feifarek wrote: > On Fri, Jun 24, 2011 at 11:42 AM, Chris McDonough <[email protected]> > wrote: > It satisfies some people entirely, and other people very > poorly. The > folks it satisfies poorly tend to be people who need to do > very > layout-intensive "retail" forms with lots of irregular styling > and > arbitrary layout. They don't like it because it often it > requires that > they write Deform templates. This is a large percentage of > people. > > > Hmm. Thanks for the high-level perspective, Chris. > > > I'll weigh in; it was my question that started this. > > > As-is, I can't use Deform out-of-the-box. I'm willing to invest some > work to make it work for me, of course, but its not flexible enough on > output, as you acknowledge, for a large percentage of people. I don't > think that my needs are particularly irregular or layout-intensive, > fwiw.
Nobody does, of course. ;-) > Styling forms sucks; and don't get me wrong, deform is a welcome tool > in the pyramid arsenal. And the default templates including support > for "required" styling and-so-on are completely up to par for markup > completeness, standards, etc. > > > But my needs are not advanced or special... in my opinion. Having > good/logical css-selector access to the html-elements and their > containing elements is necessary for my real-world work, call it > 'retail', sure. I mean, you sort of already have that capability, or at least it's possible to add classes to do this. But what you probably want, and cant easily get, is to be able to style an individual form element using its HTML id, which really sort of just isn't compatible with Deform's goal of allowing for the rendering of multiple copies of the same form element in the same form, sometimes even added dynamically via Javascript. At least without a major overhaul of how Deform works. I'm going to maintain that you don't actually *need* to style elements by id, it's just very convenient for very high-touch forms. > And the containing html as-is precludes simple things like 2-column > forms. (I expect it's possible through some clever use of float styles > and re-ordering the schema to zip left-right, left-right, left-right > rather than left-left-left right-right-right.) > It seems like a logical help for a "large percentage of people" would > be to let the widget markup stay as-is, which is deliberate and > full-featured, but over-ride the markup for the form object itself... > letting the fields slug-in their buckets of markup in a loop or a > mapping. I think this will get us 95% of the way there, except for > *really* picky layouts, where the number of spaces between the <label> > and the <input> might matter or something. > > > I'm so ignorant with ZPT that I don't even know if the given form.pt > can be easily modified, but I expect so. If I can make this work, I > could make a recipe for the cookbook or whatever. Overriding templates is relatively easy. http://docs.pylonsproject.org/projects/deform/dev/templates.html#adjusting-the-chameleon-template-path . Once you have your own path set up, you just basically copy the structure of the existing templates directory over as necessary to override bits of it. Overriding individual templates with an exact copy of the original really doesn't have much to do with knowing Chameleon. Of course, when you want to modify a template you just overrode, you do need to know Chameleon. Or you need to recreate all templates in a templating language you like, and use those. > If the next question is "what would it take to...", the answer > is "I > don't know". I haven't had much occasion to think about it, > and won't > soon (delta sponsored work entering the equation). > > > Maybe those of us who have expressed an interest in this aspect of > deform can come up with an answer to this question... I'd love to be able to provide some sort of "inside-out" mode for Deform where the developer drives the individual elements during rendering, or take up where danjac left off on a Colander-using pyramid_simpleform, which would allow for at least schema-level sharing of Deform schemas. It's just an arbitrary amount of work. - C -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en.
