On Tue, Dec 9, 2008 at 2:36 AM, Noah Gift <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, Dec 9, 2008 at 11:33 PM, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>>
>> Previously cropr wrote:
>> > I don't use FormEncode. It is based on a very common design mistake
>> > made by a lot of programmers, who think one can better generate html
>> > from code. When a graphical artist designs the layout of a web page,
>> > he uses tools who speak html, css and javascript, but no python (or
>> > Perl, Java, C++, ...).
>>
>> While I agree FormEncode is very far from ideal, your argument does not
>> make sense to me. FormEncode does not generate markup at all unless
>> you explicitly tell it to. I do exactly what you describe: hand-written
>> markup written by a designer, with FormEncode on the backend only
>> doing decoding and validation.
>
> I think this is a case where the unified documentation that Django presents
> is much clearer:
> http://docs.djangoproject.com/en/dev/topics/forms/
>
> It took me 3 seconds to find how Django does form validation. And most
> people aren't confused about what it exactly does.
Cropr's point seems to be that programmers should not design forms
because graphic designers do a much better job. That is true only if
a complex visual design for the form page is paramount. In most cases
the complex design occurs on the home page and content pages, and the
form is merely an add-on and can be simple. In some cases the form is
for technical users who will tolerate a lack of bells and whistles.
And some organizations do not have graphic designers for things like
form pages. In any case, the programmer can put CSS IDs in the form
as instructed by the graphic designer, or the graphic designer can be
taught the simple syntax of input-tag helpers.
Or you can use Genshi, which allows you to place dummy tags in the
template source, which will be replaced by the actual input tags which
can be calculated using WebHelpers. It's something like this:
<input type="text" name="name" class="my-class"
py:replace="h.text('name', value=None, class_='my-class')" />
If you're setting tag attributes, it's much more convenient to call a
helper than to interpolate the value into a static tag.
${h.text("name", id="my_name", class_=c.my_class)
<input type="text" name="name", id="my_name", class="${c.my_class}" />
The helper also takes care of issues like attributes in a dictionary.
${h.text("name", **attrs)}
<input type="text" name="name"
${FUNCTION_TO_CONVERT_A_DICT_TO_A_TAG_FRAGMENT(attrs)}>
Making links and the form tag is also more convenient with a helper.
${link_to(c.title, url("bla", anchor="bla-bla"), class_="C")}
<a href="${url('bla', anchor='bla-bla')}" class="C">${c.title}</a>
${h.form(c.action, c,method, multipart=True, class_="search")}
<form action="${c.action}" method="${c.method}"
enctype="multipart/form-data" class="search">
I haven't used Django forms but it seems to generate HTML based on a
Python field specification, akin to ToscaWidgets or Quixote forms. So
that would not meet Cropr's standards either. Especially since the
kinds of forms that require graphic designers have arbitrary and
changing requirements like "Put this field exactly here, to the right
of this other field. And could we add two paragraphs of help text
below this field? And oh, this field needs a little green message
below the title." It takes a lot of time to program this into an HTML
generator and write unit tests for it, about the same amount of time
as it does to lay out the form manually. But laying out the form
manually is made more convenient with WebHelpers.
In any case, in Pylons the programmer is free to let the graphic
designer handle all templates, or design the form with WebHelpers, or
design the form without WebHelpers, or use ToscaWidgets or Django
forms or FormAlchemy. WebHelpers is just there to provide a basic
alternative, and doesn't get much in the way if you don't use it.
--
Mike Orr <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
