James Bennett wrote:
> On 8/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> Thoughts/comments/suggestions on Joseph's plan below, and on Brant's
>> plan in Trac?
>
> I think Brant's rocking the sexiness; the concept of validation
> behaving as a try/except block feels nice to me. And bidding good-bye
> to 'if errors', FormWrapper and friends will be a huge win.
>
> The exact details could use a little fine-tuning, though; a couple
> things in particular jump out at me:
>
> 1. I'm not sure I like the idea of manipulators having a 'process'
> method which does everything; it would feel more natural to just try
> 'manipulator.save()', have that save if all is well, and catch any
> validation errors.
>
> 2. Since we're already striving hard to get rid of 'get_absolute_url'
> I'm not sure how I feel about introducing a 'get_update_url'.
>
> 3. Doing 'manipulator.process(request)' is probably unacceptable,
> since there are tons of common use cases where you'll want to fiddle
> with the soon-to-be-validated data before you let the manipulator get
> involved. I can live with 'new_data' in this case.
Some comments:
1: hardwired to HTML
[[[
def process(self, request):
"Perform the manipulation process."
if (not request.POST):
raise self.form
self.request = request
self.data = copy_dict(request.POST)
]]]
I gather this proposal means validation will be highly optimised for web
forms and available only on POST? I understand that is the mainline use
case, but I have a preference something that wasn't baked into HTML 'cos
I'll have to hack around it eventually or use something else.
Can I suggest one of the following. Set up a Manipulator family and
extract the prep work to a method in process() so other cases can be
supported (even if it's just unit testing the validations). Or, leave
the validation framework as specced but tie it right into form handling
so there's room for non-form validations work on models.
2: fast fail
Throwing exceptions means the first error will exit the chain. A lot of
work I do involves gathering as many errors as possible.
3: exception based flow
This will be my inner Java guy no doubt, but using exceptions to manage
mainline execution seems wrong to me. I guess I see validation failure
as not being exceptional behaviour. But as it goes, I think what's there
is about as elegant as you make it with exceptions. Partially related
to 2 because when you walk away from exceptions as a mechanism you are
left with a chaining/pipelining approach, which will support error
collation naturally.
cheers
Bill
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
