On 01/08/2003 02:31:33 PM Ian Bicking wrote: >> Wierd--I emailed you 12/29 to tell you that the notification didn't seem to >> be working, and that there were patches waiting. You must be filtering out >> my email! :-) > >Not impossible... I've been using a trainable spam filter, and getting >an unfortunate number of false positives... :-(
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. >> Reimplementing FFK again? I understand why, and use the Python >= 2.2 >> features a lot myself. But all the unstability in the code makes it really >> hard to pitch in and help, or even to use it since it keeps changing... If >> everyone was to do a private fork of FFK to get the stability needed for >> production code, it will never get fully testing since one needs lots of >> people using the same code base in order to exercise it and get all the >> bugs out of it. > >Yes, I recognize those problems. I feel conflicted, because I feel like >FFK is too complicated, but also remains relatively immature. Fixing >one breaks the other. 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 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 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. 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. 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. >> Can just anyone commit to the repository? I would like to commit my changes >> since they're pretty basic bug fixes... > >No, not anyone can, but I added you as a developer so you can now. Just >be sure you check out FFK as yourself (not anonymously), then just copy >over files from your old checkout, and do a cvs commit for each change. OK, thank you. I'll start making changes soon... ...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
