FormUI Refactor

27 views
Skip to first unread message

Owen Winkler

unread,
Feb 8, 2013, 8:56:49 AM2/8/13
to habar...@googlegroups.com
I'm refactoring FormUI, starting last night. So far, it's in branch
388, for issue #388:

https://github.com/habari/system/commits/388

I'm not going to guarantee any existing use of FormUI will work after
I'm done, though I am mindful that changes in this area could be costly
to plugins. There are a few goals I'm trying to work into the system:

* Be less Session/cookie-dependent.
* Be easier to build forms (in code via IDE, in pluggable XML, in
DOM-parsed HTML)
* Support Ajax
* Uniform and sensible control API.
* Generic, ubiquitous, Milk Plus-compatible HTML templates and template
families.

Provide your input now, or forever hold your peace.

Owen

Morgante Pell

unread,
Feb 8, 2013, 8:58:54 AM2/8/13
to habar...@googlegroups.com
Those all seem like worthy goals, but I'm very concerned about significantly changing the API for FormUI.

Specifically, what is it about the current system which *prevents* those.

it'd be easier if you outlined the planned changes. Also, at some point could we stop changing things for the sake of changing them? It gets a little annoying to have to constantly go an rewrite every plugin.
> --
> --
> To post to this group, send email to habar...@googlegroups.com
> To unsubscribe from this group, send email to habari-dev-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/habari-dev
> --- You received this message because you are subscribed to the Google Groups "habari-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to habari-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Owen Winkler

unread,
Feb 8, 2013, 9:09:50 AM2/8/13
to habar...@googlegroups.com
On 2/8/2013 8:58 AM, Morgante Pell wrote:
> Those all seem like worthy goals, but I'm very concerned about
> significantly changing the API for FormUI.

The current system is in the poor state it is currently precisely
because we altered it while keeping backward compatibility. While we're
still in pre-1.0, we have every reason to make it right so that we have
a stable API instead of a rickety one we keep using.

It's not just a change for change's sake. It's a change because what's
there now isn't good enough and prior to 0.10's other massive changes is
the time to properly fix it.

Owen

Morgante Pell

unread,
Feb 8, 2013, 9:16:01 AM2/8/13
to habar...@googlegroups.com
I'm not convinced FormUI is such a bad system. It's one of the
beautiful bits of Habari.

I'm not saying we need to keep the API. I'm just asking what
specifically about the changes necessitates breaking the API.

Why do things like this go ahead with minimal discussion?

~Morgante

Chris J. Davis

unread,
Feb 8, 2013, 9:27:59 AM2/8/13
to habar...@googlegroups.com
Because Habari is a commit-then-review project and alway has been. The changes are being made in a branch, which allows people to jump in and help if they can, review if they want and offer informed pushback if necessary.

I think you make some valid points. We really don't need to break APIs willy nilly, that has bitten me on the butt more than once. Owen sent this to the list so we could have discussion about it, and it is in a branch so that it doesn't affect trunk until it's ready.

One of the major pushes for the update to formUI was me, and my very vocal hate of trying to use it in non-bloggy projects, which is 90% of what I do with Habari today. I have real world, incredibly frustrating experience trying to use the system. It doesn't support AJAX well, which most of the forms I create today need to be able to handle, and it makes intricate, in depth styling impossible.

These are two major, major stumbling blocks to its adoption outside of hardcore developers, and I say hardcore since I am a core dev, a founder and pretty good at the whole PHP thing and I don't take the time to create custom templates to solve the problems in formUI, because I don't have the time or energy to do it. It is less effort to just create the forms I need and the code that backs them from scratch.

And there in lies the rub. FormUI should make it easier and safer to create forms than rolling them yourself, and today it just doesn't do that.

Owen Winkler

unread,
Feb 8, 2013, 9:31:09 AM2/8/13
to habar...@googlegroups.com
On 2/8/2013 9:16 AM, Morgante Pell wrote:
> I'm not convinced FormUI is such a bad system. It's one of the
> beautiful bits of Habari.

I'm not suggesting its removal. I'm suggesting improvement.

> I'm not saying we need to keep the API. I'm just asking what
> specifically about the changes necessitates breaking the API.

There are many internal inconsistencies. Options, parameters,
settings... these things are shared and intermingled. It's not clear
which array is used in what case on what output element.

Saving control values is convoluted. I don't know how many times people
have tried to set the value of a control after they create it into the
form. This doesn't work. And I'm tired of explaining why. I think I'd
rather just make it work and let it people do what they expect with it.
Most of the changes I'm considering are along these lines - allowing
FormUI to make things easier by doing what people expect.

Unifying the template output is important because as we allow properties
to be set in a uniform way, the control templates must handle it.
Currently, even if you know in what place a property needs to be set, it
may not have the intended effect on the control because of the template
used (admin vs option vs tab vs regular). A better system is needed so
that you can rest assured when you set an option on a control, it
affects it regardless of the template used.

For when all else fails, attaching a FormUI class to an existing form
should be possible. For people that "just want to process this one
stupid custom form", FormUI should be able to help them out.

It could all be better, the above are the low points that, to me, are
more easily addressed by rethinking how it's done rather than spraying
on some new paint.

> Why do things like this go ahead with minimal discussion?

This seems like a discussion to me. Things hardly ever happen solely as
a result of discussion around here.

Besides that, I think it's better to talk about changes in the concrete
than abstract. The refactor is in a branch. If consensus is that we
don't need/want it, it can stay there.

FormUI is one of the few parts of Habari that keep me up at night. I've
got some personal deadlines for not letting bits like this linger, so
I'm starting my effort now.

Owen

mikelietz

unread,
Feb 8, 2013, 10:14:43 AM2/8/13
to habar...@googlegroups.com
Back when I would complain about FormUI, I took issue with the templates. I recall rearranging labels and inputs for comment forms, and lamented not being able to do that in the FormUI calls themselves, instead of needing to edit the template files, add them to the theme, add them in theme.php, etc.

The templates had a lot of what I considered to be excess tags, too. Divs around things I didn't think needed them, for example. It made making admin pages a lot less wonderful of a process (although that could just as well be leveled as a complaint about admin CSS too).

mikelietz

Morgante

unread,
Feb 8, 2013, 12:11:20 PM2/8/13
to habar...@googlegroups.com
I've replied on GitHub, and suggest that we shepherd future replies there as well.

Reply all
Reply to author
Forward
0 new messages