On Dec 12, 1:13 am, "Matt Read" <[email protected]> wrote: > > FeedBackHandler could create the current active theme object, then > call $theme->get_comment_form() to retreive the submitted formUI > object, then process the formUI calling plugin hooks as needed, also > allowing themes to hook in. The theme could also overload the > get_comment_form() for specialized formui fooness.
This is more complicated than it seems at first. If the form fails to validate, it should display the post page again with the errors. There's no guarantee that the form will exist on a page showing a single entry (one that would display for the rewrite rule "display_entry"). I've been building my new theme on the premise that a comment form could appear on every post on the home page, for example. (Yeah, this seems a little crazy, but I have plans for this that would behoove keeping FormUI/comments this flexible.) So it's not enough to simply redirect back to $post->permalink. Anyway, since you have submitted the form to a new URL, it's hard to know where the form submission came from unless you want to trust $_SERVER['HTTP_REFERER'] or add a hidden field to the comment form with that information. Either way, you'd need to either display the original page at the feedback URL (that would look confusing) or store the form errors in the session, bounce back to the referring page, and then have FormUI pull the errors back out of the session for display. Tricky business, that. But maybe it's the way to go. Storing FormUI errors in the session might be useful for other things, too. I'm not sure what yet, though. > Although, I do like having a separate URL/ActionHandler to submit > comments to. It allows Plugins to hook the "before_act_$action" and > "after_act_$action" hooks, if you are doing something crazy like only > allowing OpenID authenticated comments ;). Yes. I think there are advantages to allowing changes to this URL that we get in Habari that other systems don't have. I think this is responsible for a good bit of reduction in automated spam. > To degrade back to normal form submittion would require checking if a > formui was submitted, then possibly extract the formui name/value > pairs and process (This would still allow formUI to do it's validation > and extract any custom added feilds for processing through plugin > api). If no formui was submitted we would just grab and process the > data. > > Essentially we would be creating two unique systems to gather the same > data so it can be processed in a uniform way. I would rather force the > use of FormUI in themes, or not use it at all. I agree. And as I mentioned, I think there are significant advantages to doing so. It would actually be easier to have only one system, since determining how to handle incoming submissions, whether using the existing code or FormUI, is a challenge in itself. > I'm all for using FormUI for comments form, if we can work out the > problems that currently trump it. I wonder if others share this sentiment. I'd be happy to code out the system this way, but I didn't want to make any changes that would affect existing themes without more input first. I may not have said it explicitly before, but if we make a decision on this, my local code is 80% there already. > Also, since the element names are hashed, wouldn't that make it harder > for the spam bots to determine which field is name/email/url? .. But I > guess most just fill every one with the same crap. The names of the fields must be specific if the current handler is to be used. But if that's not a requirement, then the names can be hashed per-post, per-field. Also, the ability to add new fields to enhance protection from spam, like the honeypot plugin does, would be almost too easy. Owen --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
