I am not afraid to make a lot of changes at this point. I think we
will want to have more fine grained protocols so that users will only
need to implement the parts that they have to and can rely on the
defaults for everything else.
I would like to end up with an interface that is close to what we have
now, but that is implemented along the lines that David suggests.
Right now, each kind of form field is represented by a map. Two
elements of this map contain hard-coded HTML: :html and :label. The
value of :html can be a function, as it is for muti fields, which
allows them to be dynamically generated for each request (that is what
I think we can still represent form fields as maps but without the
HTML. Internally, all form information would be represented as Clojure
data. The very last step before returning a response would be to
render the form as HTML. This will be done in a way that will allow
users to either stick with the defaults or provide their own
I think that doing this will also clean up a lot of the other code as
The main reason I was opposed to templates was that I didn't want to
have have to come up with "the way" to use them. By keeping it open,
each developer would be able to make that decision.
I think this will be huge improvement as it will allow developers to
create rapid working prototypes and then customize them later.
On Dec 9, 1:53 pm, Nicolas Buduroi <nbudu...@gmail.com
> Unless I'm mistaken, to accomplish David's objectives to provide a way for
> users to handle the form rendering, we could provide a higher-level
> interface than what he proposed. Currently the entry point for html
> rendering is the template and form-layout-grid. Those functions are called
> from show-form which just process some of the form options, so I think the
> simplest way would be to add a protocol as a layer between them. We could
> add the following protocol:
> (defprotocol form-renderer
> template [method action attrs]
> fields [layout name fields request form-data properties])
> And modify show-form to use that. It would put the burden of rendering logic
> on the user tough. It would also need changes to some functions like
> actualize-html (not sure what it does) and we could get rid of template
> multimethod at the same time. I'm just beginning to understand how forms
> rendering work, so I may be totally wrong.
> P.S.: After looking at the rendering code, I see a lot of multimethod using
> single dispatch. maybe they would be another part of the code to convert to