Hmm, we have a very similar mechanism in Aquarium, so I'm going to
make a few comments:
On 5/25/05, Ian Bicking <ianb@...> wrote:
> michelts wrote:
> >>It might be better to use
> >>Webware actions instead of another action system, but I don't know if
> >>there's any conflict there.
> > There isn't any conflict with webware actions and the fecomponent
> > actions, fecomponent actions look like this:
> > def someaction(self, fields):
> > pass
> > I don't know if I can merge it with the webware actions and still be a
> > plug-in component.
> If you can list all the actions up front, you should be able to using
> the actions() method of the component itself (which is added to the
> servlet's actions()).
Do you really need to make the list explicit? Just look for
everything in self matching your naming convention.
> >>Is there a default action? For instance, when the user hits Enter
> >>without hitting a button, no submit button will be triggered. Is the
> >>first action listed in actionList the default?
> > Sorry, I doesn't documented it yet, I will do it tomorrow, the actions
> > should use like this:
> I don't think this is what I meant. If you have an action.ok and an
> action.cancel, I believe when you hit Enter in the form (instead of
> clicking a button) that neither of these fields will show up in the
> request fields -- in that case, one of the actions should be considered
> clicked by default.
Yes, we had to deal with the deadly enter key as well. We do this by
having a hidden form field with the default action to be executed. If
the user submits the form, that action gets executed. If he clicks a
different button, you can change which action gets executed (either
hidden variable). I won't send the code because it's not very
interesting. Hopefully you get the idea.
> >>It looks like processForm() calls on*Click. So the flow typically goes=
> >>def writeHTML(self):
> >> self.processForm() --> calls on*Click if form is submitted and val=
> >> do stuff to write the form
> >>then in sleepEvent parseDocument loads the page that was written and
> >>rewrites the form with htmlfill.
> > You doesn't need to use self.processForm (unless a special case), the
> > processForm is called automatically in the sleepEvent by the
> > parseDocument.
> > the special case is if you want to output some data from the
> > on*Clicked, this way you may call processForm when you want your
> > method called (like in FunFormKit).
> To me it would make more sense if processForm was called on awake or
> respond -- sleep seems much too late in the cycle. Hrm... I don't think
> there's a way to call an event just *after* the servlet's awake is
> processed (in Wareweb I added this), but that's where I think it
> belongs. Maybe cpage should be extended to add another event.
> >>But anyway, it looks pretty easy to use, and I like parseDocument is
> >>very output-neutral.
> > Yes, I use it with zptkit, but you can use another component
> > compatible template system or you can write direct from scratch, I use
> > a variant of fecomponent with cheetah, but it is a servlet while there
> > isn't a way to use components with cheetah.
> Yeah, that's too bad. I'd really like if there was a Cheetah component
> -- I don't think it would be hard to write, and would look very similar
> to ZPTKit.zptcomponent.
> >> I can't remember if I ever set you up with svn access for
> >>FormEncode? This could also go in svn.w4py.org.
> > Where do you prefer?
> > Sorry about anything I done wrong, the fecomponent make use of
> > validator package, I didn't have time to update it, I will update it
> > tomorrow...
> Maybe svn.w4py.org is better; colorstudy.com has been having problems.
> If you want to send me a username and password (offlist ;), or a line
> for htpasswd, I can add you.
I have decided to switch to Gmail, but messages to my Yahoo account will
still get through.