Hello, I want to chip in :) I'm also working on mako port of deform templates. Here is my clone of Joe's repo https://github.com/kozog/deform_mako
I would appreciate some comments :) -- Krzysiek On 24 Cze, 23:14, Joe Dallago <[email protected]> wrote: > Just wanted to mentioned that I started the project as mentioned above > athttps://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.
