Announcement: flutter - hiccup-based form field generation

[Joost]

I'm currently working on a library to provide a consistent and
extensible method for generating form fields, based on hiccup.

The code is at github: https://github.com/joodie/flutter

The README should give you a decent indication of what I'm aiming for.
In any case, this library will NOT provide validation routines (though
it should integrate nicely with clj-decline or whatever you might
prefer). I'm keeping my sights on the "do one thing, but do it right"
goal.

I'm still working on the tests, but in any case, the tests are the
right spot to look at right now to see some examples.

Some more convenience functions should be coming soon. For now, I've
been mostly trying to get a consistent internal API.

Check it out if you want. Let me know if the API prevents you from
doing stuff; preferably using pull requests ~ assume that I'm lazy and
you'll have a good chance that I'll accept your suggestions :-)

Cheers,
Joost Diepenmaat
Zeekat Softwareontwikkeling.
http://joost.zeekat.nl

[Saul Hazledine]

On Mar 27, 12:04 am, Joost <jo...@zeekat.nl> wrote:
> I'm currently working on a library to provide a consistent and
> extensible method for generating form fields, based on hiccup.
>

I think this is a cool thing to do. One thought I had was that your
approach looks very general - could it be used for all types of HTML
generation or is it limited to form fields?

> The code is at github:https://github.com/joodie/flutter
>
> The README should give you a decent indication of what I'm aiming for.
> In any case, this library will NOT provide validation routines (though
> it should integrate nicely with clj-decline or whatever you might
> prefer). I'm keeping my sights on the "do one thing, but do it right"
> goal.
>

I think this is a good direction to go in. I'm really interested in
how things will turn out.

One thing to look out for (it may not even be an important problem but
it has bugged me) is how attributes such as "max-length" end up as
validation and html. Looking at things from an MVC perspective max-
length is an attribute of the model that ends up used by the
controller for validation and also in the view html. I feel it would
be good if there was a painless way of using such attributes across
multiple libraries such as clj-decline and flutter. If people start
using HTML5 form validation, this problem multiplies.

> I'm still working on the tests, but in any case, the tests are the
> right spot to look at right now to see some examples.
>
> Some more convenience functions should be coming soon. For now, I've
> been mostly trying to get a consistent internal API.
>

I think the API is the most innovative thing about what you are doing
- the functionality is already there, entangled, in most web
applications. I feel you would get more early feedback on your
approach if you documented the API. Personally, I struggle to get an
overview of a library from the unittests.

Good luck.
Saul

[Joost]

On Mar 28, 11:18 am, Saul Hazledine <shaz...@gmail.com> wrote:
> On Mar 27, 12:04 am, Joost <jo...@zeekat.nl> wrote:
>
> > I'm currently working on a library to provide a consistent and
> > extensible method for generating form fields, based on hiccup.
>
> I think this is a cool thing to do. One thought I had was that your
> approach looks very general - could it be used for all types of HTML
> generation or is it limited to form fields?

It makes a few assumptions; mostly, it assumes that fields always have
a name
and a value (though value may be nil). It's certainly possible to
create your
own field types, but if they don't take values or names, it's probably
less
useful (and I would imagine in those cases it's easier to write your
own
functions to generate hiccup code directly).

>
> > The code is at github:https://github.com/joodie/flutter
>
> > The README should give you a decent indication of what I'm aiming for.
> > In any case, this library will NOT provide validation routines (though
> > it should integrate nicely with clj-decline or whatever you might
> > prefer). I'm keeping my sights on the "do one thing, but do it right"
> > goal.
>
> I think this is a good direction to go in. I'm really interested in
> how things will turn out.

Thanks, me too :)

> One thing to look out for (it may not even be an important problem but
> it has bugged me) is how attributes such as "max-length" end up as
> validation and html. Looking at things from an MVC perspective max-
> length is an attribute of the model that ends up used by the
> controller for validation and also in the view html. I feel it would
> be good if there was a painless way of using such attributes across
> multiple libraries such as clj-decline and flutter. If people start
> using HTML5 form validation, this problem multiplies.

Maybe. Right now it wouldn't be much of an issue to pass constraints
to
specific fields using a similar style to wrap-labels or wrap-params in
flutter.

How best to integrate that with server-side validations might be more
of a puzzle, though the above way would already mean you can specify
the
constraints directly from the controller instead of hidden away in a
view somewhere.

Aside: I've noticed that mapping directly from a model to
validation & form data quickly leads to inelegant hacks (and possible
security issues).

> > I'm still working on the tests, but in any case, the tests are the
> > right spot to look at right now to see some examples.
>
> > Some more convenience functions should be coming soon. For now, I've
> > been mostly trying to get a consistent internal API.
>
> I think the API is the most innovative thing about what you are doing
> - the functionality is already there, entangled, in most web
> applications.  I feel you would get more early feedback on your
> approach if you documented the API. Personally, I struggle to get an
> overview of a library from the unittests.

I understand that. I've been holding off a bit on documenting the API
until I've tested it a bit more and feel fairly sure that it's
flexible
enough and that there aren't going to be a lot of big changes.

Right now, I'm feeling fairly confident, so that probably won't take
too
long, provided the Lisp symposium and work don't take up all my
time. :)

Cheers,
Joost.

[Joost]

I just pushed release 0.0.2, which has many improvements and a bit
more documentation on the API.

If you're interested, please take a look and let me know if you have
any questions or remarks.

Cheers,
Joost Diepenmaat.