[Zope3-dev] Re: [Z3d] 721/ 8 Comment "Handling of empty prefixes in
zope.formlib and zope.app.form"
Christian Theune
ct at gocept.com
Tue Dec 12 17:32:27 EST 2006
Moving discussion from collector to list as discussions fit over here.
We can link to the discussion and provide the result in the collector later.
(For people joining the discussion, have a look at the collector entry
to catch up if you like.)
Collector: Zope 3 ... wrote:
> Issue #721 Update (Comment) "Handling of empty prefixes in zope.formlib and zope.app.form"
> Status Pending, community/bug+solution medium
> To followup, visit:
> http://www.zope.org/Collectors/Zope3-dev/721
> Please look again. I removed the *first* definition of the 'submitted' method. The second definition is the one that is currently used. It works
because the __get__ method prepends the form prefix to the __name__ of
the result. (And the deleted version does *not* work for the same reason)
>
>> Some smaller issues that would be nice to change, but I won't insist:
>>
>> form.txt:
>> "For certain use cases it is important to be able to generate forms
>> *without* a +prefix. Using an empty string for the prefix omits it
>> entirely."
>>
>> It would be really cool if you give at least one example of thos
>> 'certain' use cases there, it will help other people understand
>> the motivation better.
>
> I will see what I can do.
>
>> form.py:
>> "Join a number prefixes into a single prefix, or join a number of"
>>
>> Small typo: "Join a number *of* prefixes ..."
>
> This tells me that you have been looking at the prefixhandling-3.patch . What do you think of the alternative patch I posted?
> ________________________________________
> = Comment - Entry #7 by ctheune on Dec 11, 2006 12:52 pm
>
> Nice patch, thanks!
>
> +1 from me too. Here are some small adjustments you could make.
>
> There is one small issue that I don't understand (and from my point might spoil the patch):
>
> form.py
> @@ -570,13 +576,6 @@
> condition = self.condition
> return (condition is None) or condition(self.form, self)
>
> - def submitted(self):
> - if not self.available():
> - return False
> - form = self.form
> - name = "%s.%s" % (form.prefix, self.__name__)
> - return name in form.request.form
>
> Why are you removing this method? It is used throughout the file.
> I see that the method was defined twice in the class, but this
> is the one that is being used now, and the other one looks like
> it wouldn't work correctly, or does it?
>
> Some smaller issues that would be nice to change, but I won't insist:
>
> form.txt:
> "For certain use cases it is important to be able to generate forms *without* a +prefix. Using an empty string for the prefix omits it
> entirely."
>
> It would be really cool if you give at least one example of thos
> 'certain' use cases there, it will help other people understand
> the motivation better.
>
> form.py:
> "Join a number prefixes into a single prefix, or join a number of"
>
> Small typo: "Join a number *of* prefixes ..."
> ________________________________________
> = Comment - Entry #6 by jacobholm on Oct 10, 2006 4:00 pm
>
>
> Uploaded: "prefixhandling-alt.patch"
> - http://www.zope.org/Collectors/Zope3-dev/721/prefixhandling-alt.patch/view
> Alternative patch using better abstractions (has tests).
>
> This patch differs from the previous only in the changes to zope.formlib.form. There are two notable differences:
>
> 1) I extended the 'Widgets' constructor as described in my latest mail to zope3-dev (http://mail.zope.org/pipermail/zope3-dev/2006-October/020730.html). This made the ugly 'prefixlen' function from the other patch irrelevant, and allowed a check to ensure that all the widgets have the correct form prefix. Previously, mismatched prefixes would be silently accepted leading to strange bugs.
>
> 2) A new 'expandPrefix' function has been added. The idea is to expand a given prefix into a 'full' prefix that can be directly prepended to another name or prefix. So I now use 'expandPrefix(prefix)+other' wherever the original code used 'prefix+'.'+other'. This removes the need for the badly named 'prefixjoin' function from the other patch.
>
> The new patch is cleaner IMHO, but both solve the original problem . Which one should I attempt to check in (if any)?
> ________________________________________
> = Comment - Entry #5 by poster on Oct 10, 2006 11:15 am
>
> +1
>
> The "submitted" cleanup is different, of course, but also needed.
>
> Thanks.
> ________________________________________
> = Comment - Entry #4 by jacobholm on Oct 10, 2006 11:00 am
>
>
> Uploaded: "prefixhandling-3.patch"
> - http://www.zope.org/Collectors/Zope3-dev/721/prefixhandling-3.patch/view
> New patch including tests.
> ________________________________________
> = Comment - Entry #3 by BjornT on Oct 9, 2006 5:22 am
>
> I replied to the list thread with a small review of the patch, since I'm +1 on providing more control on the names being used as well. (It'd be good if someone responsible for zope.formlib would review it as well, though)
>
> Maybe there are better ways of giving more controls of the names being used by the widget, but given that tests/documentation is added I think this patch is a good start, and should be applied for two reasons:
>
> * Currently, if you provide an empty prefix, invalid XHTML is
> produced, and that is fixed by this patch.
>
> * The patch is non-intrusive; it doesn't change any external
> API, so it shouldn't break any external code.
> ________________________________________
> = Comment - Entry #2 by fdrake on Oct 8, 2006 2:46 pm
>
> I've not reviewed the patch, but I understand the desire for more control over the names used in the form.
>
> Part of the problem is that the prefix/field-name semantics aren't clearly documented. Another part is that they aren't easily controlled directly. I too have run across cases where I wanted complete control over the names used in the HTML, though the details of the circumstance were different.
>
> +1 on providing more control
>
> +1 on better documentation for prefix/name relationships
>
> Whether improved control should come from manipulating the prefix, I'm not sure. I'd really like complete control over the names used in the HTML, which suggests that direct control of the names should be readily available.
>
> ________________________________________
> = Request - Entry #1 by jacobholm on Oct 8, 2006 9:30 am
>
>
> Uploaded: "prefixhandling.patch"
> - http://www.zope.org/Collectors/Zope3-dev/721/prefixhandling.patch/view
> Mostly copied from my post to zope3-dev...
>
> Using an empty prefix with zope.formlib and the standard widgets from zope.app.form cause the generated HTML widgets to have "name" and "id" attributes starting with a period.
>
> I have two problems with this: 1) It is not valid XHTML, as ids must start with a letter or underscore. 2) I need to generate a form that is posted to a different server whose software I do not control, and it is currently not possible to get the name attributes correct without writing my own complete widget set from scratch.
>
> I have attached a small patch against the current trunk (r70572) that fixes this. All current tests pass, but no tests for the fixed behavior has been added (yet). The patch is minimal in the sense that no API is changed, only the behavior related to empty prefix strings. Specifically it does not change the constructor of the (internal?) class zope.formlib.form.Widgets to take the actual prefix instead of just its length. Doing this would simplify the code and allow some sanity checks, but could cause breakage if the class is used anywhere else.
>
> If there is interest, I will update this patch to incorporate any suggestions. I might even be able to check it in, if my commit privileges have not been revoked due to lack of use. However, I will not attempt this unless I am told to do so.
> ==============================================================
>
--
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20061212/f79acc3f/signature.bin
More information about the Zope3-dev
mailing list