On Wed, 2003-01-08 at 21:25, Edmund Lian wrote:
> >Part of the advantage of a class definition is that it's a declarative
> >style people are used too -- as it is now you might almost imagine it's
> >imperative, but it's not, and I imagine that disconnect frustrates
> >people.
> 
> It never bothered me... how would mutable forms be achieve with the
> class-within-a-class form/field definition/interface?

I never really have supported or wanted mutable forms -- people just
happened to find them on their own since I left the code in.  There
would be no mutable forms.  I don't believe there is any need for them.

> >Formulator is all crazy because it's in Zope.
> 
> Why doesn't this surprise me? Zope makes everything seem complex...

Well, in their defense I don't know if Formulator is crazy.  But it's an
application, not a Python package, and is rather opaque as a result. 
And that's just because that's how Zope works.

> Oh, before I forget, I have a little feedback about validators...
> 
> The way FFK is now, validators are passed in as a part of a field
> constructor. There isn't an officially sanctioned way to turn off
> validation for a field, at least not without digging into the underscored
> instance variables. I came a cross a situation where it would be useful to
> turn off or change validators on the fly.

I know there's problems with validators -- I've encountered them as
well.  I'm planning to change validators to receive a magic "state"
argument (a dictionary).  Some values will be placed in there -- the
field it's validating and the servlet involved are all I've thought of
so far.  The validator could take that into account.  There wouldn't be
any validators that would come with FFK that would use this, but you
could make your own so that a validator would be integrated into the
context.  The one I've needed several times so far is a validator that
takes into account the user that's logged in, which is impossible with
the current design.

Anyway, this isn't exactly what you're thinking, but it should make what
you're thinking possible.  It would be something like:

class ConditionalValidator(ValidatorConverter):

    def __init__(self, innerValidator, servletAttr, **kw):
        self._innerValidator =innerValidator
        self._servletAttr = servletAttr
        ValidatorConverter.__init__(self, **kw)

    def attemptConvert(self, value, state):
        if getattr(state['servlet'], self._servletAttr, 1):
            return self._innerValidator.attemptConvert(value, state)
        else:
            return value

Then use it like:

validator=ConditionalValidator(IsInt(), 'forceInt')

And have a forceInt attribute in your servlet.  I don't have the state
passed in the current version (just the experimental one), though it
wouldn't be too hard to add.

-- 
Ian Bicking           Colorstudy Web Development
[EMAIL PROTECTED]   http://www.colorstudy.com
PGP: gpg --keyserver pgp.mit.edu --recv-keys 0x9B9E28B7
4869 N Talman Ave, Chicago, IL 60625 / (773) 275-7241



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel

Reply via email to