Just wanted to mentioned that I started the project as mentioned above at https://github.com/jayd3e/deform_mako. If you find yourself converting one of the chameleon templates in deform in the near future please add it to that repo.
On Fri, Jun 24, 2011 at 1:54 PM, Matt Feifarek <[email protected]> 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. > 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. 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. > >> >> 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... > > -- > 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. > -- 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.
