On Tue, 2002-10-08 at 19:38, Ian Bicking wrote: > It looks pretty innocuous, but I also have a hard time seeing the > function of this method. Well -- I think I get an idea of how you are > using it, but I'm having a harder time seeing what it's general function > is.
I suppose it's the same thing as a default action in response to a POST. Maybe "defaultPostAction" would be a better name. > Right now the _action_ field works on both POST and GET. But this only > gets called on POST. That's not really symmetrical. That's true. To be symmetrical, we'd have to add defaultGetAction() as well. Upon getting to the bottom of the _respond() -- that is, no action was called -- it would call either defaultGetAction() or defaultPostAction(). The default implementations of each would be to call writeHTML(), which would give the same effect as the current implementation. I'm not really proposing this, I'm just explaining what "symmetrical" would look like. > It seems more like > you need a hook in awake or some other method. Here's the situation: I have a page with a form on it. If the user changes the dropdown box, I have some javascript which automatically submits the form, because it needs to be refreshed. Lots of websites do this - for example you select a country and then the form refreshes itself and the next field presents a list of regions specific to the country you chose. When a browser submits a form using javascript, there is no _action_ field defined, so none will be called. What I need is the ability to recognize when this happens, so that I can grab all of the form values and repaint the form (as opposed to validating the fields like I would have done in the action if the user had clicked a submit button). It's also true that I could achieve the same effect by putting a check in awake(), or even in writeContent(), but I'd have to check to see if an action was invoked, which means I have to essentially duplicate the code in Page._respond(), which I'd prefer not to do. Also, having _respond() call handlePostWithoutAction() makes it easy for FormKit's mix-in class to override the behaviour, making it transparent to the user. If the check occured in awake(), the user would have to be aware of the situation and make a call from his/her awake() method. So you could look at it as a hook to help FormKit integrate more seamlessly with Webware. If what I've written above still isn't clear, I'll be happy to post an example servlet. -- Jason D. Hildebrand [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Webware-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-devel
