On May 16, 2007, at 3:00 PM, Ian Bicking wrote:

>
> Philip Jenvey wrote:
>>
>> On May 16, 2007, at 7:51 AM, Graham Stratton wrote:
>>
>>>
>>> Hi all,
>>>
>>> I see there's discussion about the issues with the @validate  
>>> decorator
>>> in the tracker.  I've come across a few problems myself in the last
>>> few weeks, so hopefully I can contribute here:
>>>
>>> - In order to use multiple fields, you need to set  
>>> variable_decode to
>>> True.  This is probably fair enough, and it probably ought to be the
>>> default. It does have other side effects for field names containing
>>> '-' or '.'   Making variable_decode True by default is certainly  
>>> not a
>>> backwards-compatible change.
>>>
>>> - In order to use htmlfill with multiples, params also needs to be
>>> mapped from a MultiDict. At present htmlfill called from the  
>>> decorator
>>> only selects the first value for fields with multiple values.  I  
>>> think
>>> this can be fixed by passing decoded instead of params to htmlfill.
>>
>> Decoded as in variable_decode=True again, right?
>>
>> Defaulting variable_decode to True was brought up a long time ago  
>> but it
>> never happened. I don't think everyone (at least I didn't) realized
>> there were so many cases in which formencode doesn't work with
>> MultiDicts unless variable_decode is enabled.
>>
>> The fact that variable_decode=True fixes the MultiDict problems is  
>> more
>> of a coincidence. The variable_decode function is supposed to
>> flatten/de-nest a normal dictionary with '-' and '.' separators, the
>> fact that it correctly flattens a MultiDict is almost a side effect.
>>
>> The flattening it does is essentially the same result as having  
>> called
>> MultiDict.mixed(). validate passing MultiDict.mixed() to formencode
>> would be an even better solution than defaulting  
>> variable_decode=True.
>> The qualm I have with doing any of these is that Pylons/Paste  
>> users that
>> aren't using the validate decorator need to know to use
>> MultiDict.mixed() or variable_decode=True.
>>
>> It's reasonable to require variable_decode=True if you're using  
>> the '-'
>> and '.' nesting syntax. But if you're not, I'd rather MultiDicts Just
>> Worked(tm).
>>
>> I spoke to Ian (who I've CCed) about MultiDicts and formencode a  
>> while
>> ago. I got the impression from him that he wanted MultiDicts to Just
>> Work(tm) with formencode. Ian, what's your opinion on all this?
>
> Yeah, I think that's reasonable.  Really FormEncode is intended to  
> work
> with, um, params.mixed()?  FormEncode could just check for that
> attribute in schemas and call it if it's there.

Should this do it?

(There's also docs additions in the attached version of the patch)

--- formencode/api.py   (revision 2695)
+++ formencode/api.py   (working copy)
@@ -352,6 +352,9 @@
          try:
              if self.strip and isinstance(value, (str, unicode)):
                  value = value.strip()
+            elif hasattr(value, 'mixed'):
+                # Support Paste's MultiDict
+                value = value.mixed()
              if self.is_empty(value):
                  if self.not_empty:
                      raise Invalid(self.message('empty', state),  
value, state)



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Attachment: multidict-support_r2695.diff
Description: Binary data

--
Philip Jenvey


Reply via email to