On Wed, 2003-01-08 at 14:52, Edmund Lian wrote:
> Aha! That explains things... I actually did email you a couple of times,
> but never got any replies. What are you using that's giving so much
> trouble? I just use a combination of a few RBLs and SpamAssassin, and have
> had great results.
I'm using bogofilter -- it's statistical (Bayesian). It was working
great, but it's gotten overzealous with training. Sadly, a big reason I
wanted to use it was because I hoped it wouldn't have as many false
positives.
> FFK is a bit complicated. Before I started using it, in December, I was
> using my own system (that did use Python 2.2 things like metaclasses, etc.)
> because FFK < 0.4 just wouldn't play nicely with Cheetah Templates, at
> least to the degree that would make me use it. But when you simplified the
> servlet interface in FFK 0.4, I spent a bit of time looking at it (hence
> the emails to you) and eventually puzzled out how to use it. The better
> documentation certainly helped.
>
> At that point, I decided that maintaining yet another form system was
> stupid, so I retired my own stuff and started switching over to FFK.
> Some of my random thoughts so far are...
>
> Overall, I think FFK 0.4 is much easier to use than earlier incarnations,
> but I do agree that the code underlying Form.py and Field.py is certainly
> complex. For example, there's a bug in MultiCheckboxField that causes
> return values from the form to come back in the wrong format when the field
> is static (because the statically rendered version stuffs everything into
> one hidden field, and forgets to unpack the returned string to form a
> list). But, I haven't been able to wade through everything to figure out
> how to fix it yet.
I think that would be with the htHidden and valueFromFields methods, but
I'd have to look at it again. (That I don't know for sure is part of
why I want a simpler codebase)
> I suppose the reasons for wanting to take another tilt at the windmill of
> FFK design are good given the above. The problem is that the public
> interface has been changing, and this affects dependent code when it should
> not.
>
> If you can settle on an interface, and then what happens with regard to
> implementation is irrelevant so that you can rewrite FFK every week without
> breaking code. :-)
The interface was a big part of what I wanted to change. Which might be
silly -- it's not that big a deal, and the improvements are largely
aesthetic. They also make automatic form generation even more difficult
-- with current versions, it seems pretty straight forward how you
construct a form programatically -- it's just a statement. But a class
definition is hard to create programmatically -- you're in metaclass
territory then.
To give an idea of what I was thinking, this is what a form might look
like:
class RegistrationForm(Form):
class FirstName(TextField):
maxLength = 20
validator = Validator.NotEmpty()
class LastName(TextField):
maxLength = 20
validator = Validator.NotEmpty()
# ...
class Submit(SubmitButton)
method = "register"
layout = [(FirstName, LastName),
Submit]
Class Register(SomeModifiedVersionOfPage):
form = RegistrationForm
def awake(self, trans):
submitted, date = self.processForm()
if not submitted: self.writeForm()
# then define register -- writeForm would be automatic.
The insides are more like servlets, where Form (and Field) instances are
created for each transaction. (Potentially the form could be separated
out, so that only a hook from Page is required, not a mix-in)
Then I wanted to work on a FFK-lite of sorts. The interface in these
cases would be defined in the function definition, like:
class Register(SomeModifiedVersionOfPage):
def registerUser(self, firstName, lastName):
# firstName and lastName taken from the submission
registerUser.public = True
def registerForm(self):
self.write('''<form action="Register" method="POST">
<input type="hidden" name="_action_" value="registerUser">
<input type="text" name="firstName">
<input type="text" name="lastName">
<input type="submit">
</form>''')
There'd be some other tweaks as well, like some minor type checking
based on variable names (like having an argument "idList" would make
sure the "id" field was a list).
Actions would work a bit different, more along the lines of actions in
FFK -- i.e., they wouldn't interrupt the normal flow of display, and
would be expected to occur before any rendering. But there's hooks to
make it easier to base rendering on what action occurred, or dispatch to
a method based on the action.
The next step would be allowing simultaneous XMLRPC access to the same
servlet, only without rendering. And to make FFK do XMLRPC validation.
And to make FFK output a layout that's suitable for client-side
rendering. And... oh, I won't go too far.
Anyway, that's some of what I was thinking. Aesthetic interfaces please
me greatly.
> The current public interface for FFK is easy to use, so I wonder if you
> really need to change the interface at all. What I like least about FFK 0.4
> is the need to use a mixin. Inheritance is just a horrid way to bring in
> added functionality due to namespace pollution, unseen interactions, etc.
> So if you do change something, change this! :-)
>
> In fact, it does look like you've prepared FFK 0.4 to work without being
> used as a mixin, but I haven't tested this mode of use yet. E.g.,
> FormServlet.processForm() will accept a transaction object, and FormServlet
> itself does not try to take over the servlet the way FFK <0.4 used to.
FormServlet does set some instance variables which it needs for later.
But, though I haven't thought about it, it just might work to do:
form = FormServlet(formDef)
form.processForm(self.transaction())
rf = form.renderableForm()
etc. The only issue would be submit actions (methodToInvoke), which are
assumed to be methods of self. A little tweak and a subclass could fix
that easily. With a little refactoring, it could probably turn into:
form = formDef.processForm(self)
if form.submitted():
rf = form.renderableForm()
self.write(rf.htFormTable())
That's kind of nice...
> The only other thing that occurs to me about FFK 0.4 right now is that it
> doesn't try to take advantage of button actions as implemented in
> WebKit.Page.py. I haven't thought through the implications of whether this
> is a good or bad thing. In fact, I don't actually use Page.py myself, but
> use a vastly modified version. The one thing that I did keep was the
> actions.
I've never felt comfortable with Webware actions. They just seem wonky
to me -- it doesn't fit together like I'd like. FFK submit actions seem
more flexible to me, so long as you intend to use a MVC-like paradigm
(where the actions are strictly C -- i.e., occur before any rendering).
You can also use either a functional or imperative style.
> Hmm... now that I think of it, rather than explicitly calling
> FormServlet.processForm in the servlet, this could be called in an
> overridden preAction() method. This would get rid of the need to pass in a
> value for methodToInvoke in the SubmitButton constructor. Of course,
> SubmitButton fields would then have to emit "action compatible" button
> names.
No, those actions can only be taken when the form has been submitted
successfully. But the _action_ field will exist whether or not there
were errors in the form. It also should deal with default actions,
which Page does not have the facilities to handle. (Or rather, to define
what the default is)
In fact that's what the hidden _formID_ field is for -- it makes it
complete unambiguous whether the form was submitted or not, without
using submit buttons. Then it can handle default submit buttons and all
that.
--
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
