On Fri, Sep 08, 2006 at 04:51:15PM -0400, Kevin Dangoor wrote:
>
> On Sep 6, 2006, at 9:34 AM, Timur Izhbulatov wrote:
> >
> > On Wed, Sep 06, 2006 at 07:24:46AM -0400, Kevin Dangoor wrote:
> >>
> >> On Sep 6, 2006, at 2:33 AM, Timur Izhbulatov wrote:
> >>
> >>> Sorry, but I still don't get your idea. I agree, I can pass the
> >>> schema from the
> >>> controller to the template engine through expose using its mapping
> >>> argument. But
> >>> how the validate decorator will receive it than?
> >>
> >> Ahh. I think I might have missed something with your original
> >> thought. I thought the schema was known beforehand...
> >>
> >> if that's not the case, the only way at present to dynamically
> >> provide a schema to validate is by passing a callable (eg a function)
> >> to the decorator, and it will call that at the time that it wants to
> >> do validation. (I know you can do this with the form, I'm not 100%
> >> sure you can do this with a schema...)
> >
> > That's what I was afraid of. I have to create my own decorator. The
> > existing
> > decorators I've seen (like validate) look rather complex (or even
> > scary :)
> >
> > The problem is that I can build schema only when I already have a
> > business
> > object which I display form for. In my original application I get
> > an object plus
> > some metadata for validation from the model and pass everything to
> > the template
> > engine which generates the form, the validation logic resides in
> > the controller.
> >
> > My initial goal was to have the form and the schema generated in
> > one place and
> > get rid of my own validation logic in favour of TG's validate. But
> > taking into
> > account that I have to write my own decorator and some callable for
> > schema
> > generation, looks like there is no point in using
> > htmlfill_schemabuilder
> > anymore.
>
> I don't think you have to write your own decorator. You just need to
> pass a callable to @validate.
Yes, I noticed that @validate checks if form is callable. At that moment I
thought the form argument can be only useful if you are working with widgets. I
didn't use widgets and was focused on validators.
The other thing which confused me was that @validate didn't try to catch any
exception while calling form. I needed to do some kind of "prevalidation" inside
the callable and to return possible validation errors back to the decorator.
While typing this I realized that in case of an error I could merely return the
form validating only the field which caused the error:
class my_callable_form(object):
def __call__(self):
args = cherrypy.request.params
id_ = args.get('id', '')
try:
id_ = self.id_validator.to_python(id_)
except Invalid, error:
return self.get_form_for_id()
data = model.get_metadata(id_)
return self.get_complete_form(data)
Looks good enough.
> BTW, the decorator stuff is only a bit scary because it works hard to
> preserve the original method signature. We have an overhaul in mind
> for TG 1.1 that will behave the same but be extraordinarily simple
> inside.
All this signature magic seem to cause some weird effects (unexpected field
'self'..., multiple values for keyword argument 'foo') in python 2.3. I'll try
to find out more next week.
--
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:[EMAIL PROTECTED]
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears
-~----------~----~----~----~------~----~------~--~---
