On 01/08/2003 04:54:48 PM Ian wrote:
>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.
I guess it isn't working too well... I certainly started to get the feeling
that you were ignoring my email... :-)
>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()
Before I abandoned my design, I had something much simpler:
class MyForm(Form):
def createForm(self):
self.addField(TextField("myTextField", ...))
self.addField(IntegerField("myIntField", ...))
self.addButton("buttonName", ...)
The advantage of this is that you could add fields and buttons to MyForm
very easily on-the-fly, and you could also control the generation of fields
even during instantiation via code in the createForm() method.
Also, unlike your Form class, mine did not attempt to extract and deliver
data to each field from the request stream. It just passed the transaction
object to each field, and each field was responsible for extracting what it
needed, as well as casting data to the appropriate data type.
>Anyway, that's some of what I was thinking. Aesthetic interfaces please
>me greatly.
Have you looked at Matt Feifarek's FFK-derived FormKit? I haven't tried to
work with it yet, but it looks to be structured somewhat like what you
describe.
>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()
This is what I was thinking, except that yeah, the submit actions assume a
mixin usage so that self.x is scattered everywhere.
>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)
Hmmm... I agree with the first bit, but the issue of not having default
actions never bothered me since in my Page.py, the default is just to
execute a specific method, which could itself invoke a specific action.
...Edmund.
-------------------------------------------------------
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
