What is unclear to me is why to do all that you so eloquently outline here, we must remove the ability for people to create completely custom solutions for comment creation. All of this was already possible as you have pointed out. You have gained nothing by removing the ability for people to roll there own solution, save for strong arming people into using the core feature.
Since I have found documentation on the change (thanks whoever wrote it) I can make things work, but I am not happy with the attitude "It's our way or the highway" that this change shows. Of course it could just be me being cranky, since I now have to update the code for 10 sites built on top of Habari to use the new system before I can update them to 0.7. On Aug 13, 2010, at 5:03 PM, Owen Winkler wrote: > On 8/13/2010 7:34 PM, Christopher Davis wrote: >> >> I am not against this being the case down the road when the FormUI system is >> more user friendly. Currently this just isn't the case. I would like to >> propose that this change is reverted, and a ticket created to re-implement >> it when FormUI has matured enough to make adding or removing items from the >> comment form trivial. >> > > It is possible to perform all of the actions you suggested using the FormUI > comment form, it simply takes a bit more code than what it would if you were > using HTML and a custom handler. > > Removing unnecessary fields from the comment form is not only easy, but can > be done from a plugin such that you need not change the form HTML for any > theme you activate. It can also be done from a theme, since themes extend > pluggable, making it possible to adjust the form from specific themes if they > provide special functionality. Themes may also still provide distinct > templates for the discrete fields of any form to allow theme to fit more > seamlessly into their design. > > By providing the FormUI comment form, the form becomes extensible to any > plugins that wish to augment the form while retaining compatibility with any > theme, not just the one theme that contains the additional necessary form > fields to make the plugin's function work. > > If there is a control that doesn't exist (such as an upload control) that is > an impediment to using FormUI, then the control could be developed and > contributed back to core. The comment FormUI code will never mature to the > point that it is useful for these edge cases if the edge cases aren't forced > to work within the confines of the classes provided. It's imperative that we > encourage developers to build for FormUI so that useful, reusable code can be > reintroduced to the core. > > There are several plugins in the extras repository that make use of the > FormUI classes to build forms, whether for comments or otherwise. That there > is such a wide variety of samples and a consistent API for dealing with forms > is an advantage, not a detriment. > > Using solely FormUI for the comment form enables plugins to uniformly > introduce arbitrary authentication mechanisms or other additional fields to > any theme, and still allow the core system to securely handle the fields > about which it is aware. This is the primary reason that the comment form > was changed to use FormUI rather than a random assortment of named form > fields. > > Reverting this change would be degenerative to Habari's forward development. > Instead it should be adopted and built upon. > > 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 -- 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
