On Mar 28, 11:18 am, Saul Hazledine <shaz...@gmail.com
> On Mar 27, 12:04 am, Joost <jo...@zeekat.nl
> > 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
and a value (though value may be nil). It's certainly possible to
own field types, but if they don't take values or names, it's probably
useful (and I would imagine in those cases it's easier to write your
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
specific fields using a similar style to wrap-labels or wrap-params in
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
constraints directly from the controller instead of hidden away in a
Aside: I've noticed that mapping directly from a model to
validation & form data quickly leads to inelegant hacks (and possible
> > 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
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
long, provided the Lisp symposium and work don't take up all my