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. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
