On Thu, Dec 11, 2008 at 10:58 AM, ringmaster <[email protected]> wrote:
> I would like to build the comment form in my theme using FormUI, but
> I'm running into a snag.
>
> When using FormUI to build the comment form, I have two options:
>
> 1) I can set the action URL of the FormUI form to the existing
> "submit_feedback" rewrite rule URL.
> Problem: The native form processing of the FormUI object never takes
> place, and so things like automatic validation of fields (for URL,
> email, and required values) doesn't happen.  This is especially a
> problem for custom-added fields, which is an advantage of using FormUI
> at all.

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.

> 2) I can leave the action URL blank and let the FormUI object process
> the form and add the comment.
> Problem: Because the custom submission URL isn't used, plugins like
> SpamChecker that rely on adding additional data to the request via the
> URL don't work properly.

This  is an interesting idea. GET request would retrieve the post
object/child objects; POST request would write to the post
object/child objects.

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 ;).

> Perhaps I need more time with it, but I haven't been able to determine
> a way for this process to degrade gracefully so that the current
> comment forms continue to work while FeedbackHandler also supports
> FormUI-based submissions and tackles the above problems.  I was
> thinking more eyes on the issue might be fruitful.
>
> If no means can be determined to account for both posting types, then
> ideally what I'd like to do is convert all themes to use FormUI for
> comment submission, and update all plugins that previously modified
> the comment submission process to use FormUI instead.

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.

> The advantages of using FormUI for comment submissions, to be clear
> about it:
>
> * Allows plugins to programmatically add fields to the comment form
> (think hidden fields or custom captcha)
> * Allows the form to more effectively process submission errors
> (required fields and field types)
> * Allows the form to be generated from core (by calling one function:
> $theme->comment_form();)
> * Continues to allow customization of the form to fit into the site
> layout

I'm all for using FormUI for comments form, if we can work out the
problems that currently trump it.

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.

-- 
Matt Read
http://mattread.com

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to