Bob, 1) Because form specifications are data, it's pretty easy to build one up at runtime. One tool for "mixins" -- which I just noticed isn't documented in the readme -- is *formative.core/merge-fields*. It makes it easy to tweaks fields, or insert new fields before or after existing fields.
2) Your approach sounds reasonable. Note that you can create your own :type with render-field and still use an existing :datatype; you don't necessarily have to implement parse-input. If the prepending/appending Bootstrap stuff is generalizable, it might be worth adding it to the default renderer. I don't actually use Bootstrap much myself so I'm open to improvements. 3) Right now only by using the :in validator. I've added an issue for that - https://github.com/jkk/formative/issues/6 Let me know how it goes. Feel free to add issues if you find any. Justin On Wednesday, January 16, 2013 1:32:21 PM UTC-5, hutch wrote: > > > On 2013-01-16, at 11:31 AM, Justin Kramer <jkkr...@gmail.com <javascript:>> > wrote: > > So I went ahead and implemented the first solution I mentioned: the > default renderer now groups fields into fieldsets, split by :heading and > :submit fields. Each fieldset has a class that you can target with css/js. > You can see the result in the demo - http://formative-demo.herokuapp.com/. > > > Heh, that was quick :-) Thanks! > > I don't suppose you've thought much about this situation: I've got a > couple of standard (what I'll call) mixin-forms that have fields and > validations that I 'mixin' to a form (once or not at all). They aren't > forms on their own, just a bunch of fields and validation rules. For > example, I have a standard way of describing an entity (name, title, > abbreviated description, full description, and a few other things). It's > possible to think of tabs this way as well. Dropdowns in a nav bar is > similar too, maybe. It's pretty clear how to get started on implementing > something like this, but I'm wondering if you've considered anything in > this regard. > > I've also got groups of several controls that operate together. The > bootstrap prepended and appended inputs are simple examples. These are to > some degree like the 'mixin' things I mentioned, but there can be more than > one of them and they need to be distinguished, and the validation might be > different for each or need to be extended for each instance. It looks to be > easy enough to do this by adding new field types (extending the > render-field and parse-input multimethods). Is that how you'd approach the > problem? > > While I think of it, do you provide a way to validate that a value > corresponds to one of the :options? > > Cheers, > Bob > > > Justin > > On Wednesday, January 16, 2013 8:35:54 AM UTC-5, hutch wrote: >> >> >> This is *really* interesting! I'll have a look at this more closely over >> the next couple of days, but, really, the timing could not be better… you >> might have just tipped a project I'm working on over to Clojure :-) >> >> It looks as though you've not put any kind of 'structure' on the fields… >> they are 'flat'. For example, I don't see fieldsets. One of my projects has >> its forms in two parts, the input fields which scroll (and have fieldsets) >> and a second part that consists of things like the submit and cancel >> buttons. The second part is pulled into a sidebar and fixed on the page >> (doesn't scroll with the rest of the fields). These forms can be a bit long >> (but they are a lot more usable than you'd think), so there's also an index >> in the sidebar that on click moves the scrollable part to make the >> corresponding fields come into view. In my current project these indexed >> things aren't fieldsets but they could be. Alternatively, some other kind >> of grouping structure could be used. Or possibly just a new field type that >> created an index entry… I'll have a muck about and see what I can come up >> with. >> >> Cheers, >> Bob >> >> >> Justin >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> >> >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > > > -- 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
