jkk / formative Goto Github PK

what string format to use? anything compatible with clojure.instant/read-instant-date?

Formative should have a built in credit card field, that spaces numbers by four and checks if the correct number of digits is entered.

The required DOM attribute is filtered out when rendering a select box field, for instance:

It's quite a useful attribute, should probably add it to the field whitelist above.

(getf :foo.bar {:foo {:bar 1}}) => 1
(getf "foo[bar]" {:foo {:bar 1}}) => 1
(getf "foo[bar]" {"foo" {"bar" 1}}) => 1
(getf "foo[bar]" {"foo[bar]" 1}) => 1

For :flatten fields?
(getf "foo[bar]" {"foo-bar" 1})
(getf "foo" {"foo-bar" 1 "foo-qux" 2}) => {"bar" 1 "qux" 2"}) ???

Reader conditionals are in town + cljx is deprecated so we are better of migrating to cljc

Right now it uses the SimpleDateFormat default (local time zone).

Using clj-time would make this easier, but pulls in the JodaTime dependency.

There is the following undocumented behaviour that is works well with bootstrap, which would be nice to have it right in the readme.

(f/render-field {:name :my-text :data-x 10 :data-y 20})
;; (nil [:input {:type "text", :name "my-text", :value "", :data-x 10, :data-y 20}])

Thank you for all the great work on formative.

I have a request: could you add a field "type" that allows us to add in an inline anonymous function for handling that field? For simple HTML formatting I'd rather define the function inline that invent a custom method with:

(defmethod render-field :hyperlink-value ;;;; code here)

My scenario:

Assume I have something like weblog software, so I have "posts" and "users". Each post is owned by 1 user. On the admin form that allows an admin to edit the "posts", I want the "user-id" field to be a hyperlink that could take an admin from the "post" record to the owning "user" record.

I could:

(defmethod render-field :hyperlink-value ;;;; code here)

Or I could make the presentational HTML fields work to this purpose (I assume).

But I'd rather just define an anonymous function inline, for relatively rare stuff like this.

Thanks for making formative! I've found it very useful so far.

I noticed the bootstrap3-horizontal form is broken. What would it take to fix it?

;; Broken
#_(defmethod render-form :bootstrap3-horizontal [form-attrs fields opts]
   (render-bootstrap-form form-attrs fields "form-shell form-horizontal" opts))

I'm using the latest version of Bootstrap, and the stacked layout doesn't look appropriate for desktop window sizes.

It looks as though you are assuming a labeled input field when a new field type is defined and implemented by adding a new render-field method. This means you can't introduce a new field type similar to a heading, or some regular HTML.

It looks as though you're using sets containing field types to make decisions about lots of things, not just wrapping format, e.g. you're using a set to define what field types separate field-sets.

It might be nice to name (and document) these sets, and even nicer if you could make them dynamic so we could change their contents with a binding. (I'd be able to control what kind of wrapper the new field type has, and if it separates field-sets, and more).

It might be necessary to add additional multimethods to completely control this stuff.

And it's getting complicated, but at least there's reasonable defaults.

Does that make any sense?

When specifying elements like checkboxes and selects where options are passed for the values to be displayed, there should be the possibility to use sets just as one can use vectors.

Example:

{ :fields [ {:name :grouped-by 
              :type :radios 
              :options #{"year" "month" "day"}}]
}

Thanks for the handy library!

I'm running into a problem trying to use checkbox fields with wrap-keyword-params.

See two params maps, extracted from a test application, one with wrap-keyword-params and one without. "disclaimer" is the name of a field that looks like {:name :disclaimer :type :checkbox}

(def pms {"submit" "Submit", "disclaimer" ["false" "true"]})

(def kpms {:submit "Submit", :disclaimer ["false" "true"]})

(#'fp/normalize-params pms)
;;=> {"disclaimer" "true", "submit" "Submit"}

(#'fp/normalize-params kpms)
;;=> {"submit" "Submit", "disclaimer" ["false" "true"]}

The keyword version causes a problem later when we call something like

(parse-input {:datatype :boolean} ["false" "true"])
;;=> java.lang.IllegalArgumentException
;;=> No matching method found: valueOf
;;=> parse.clj:43
;;=> ...

Must account for this in validations, too - does Verily need to be updated?

Would be nice if we can provide a spec as a form validator in addition to validation fns.

Two approaches come to mind:

• Handle it in the renderer by splitting on :heading
• Create a :fieldset field type that contains other fields

Currently the rendering is dispatched as a multimethod,
however if more built-in renderers get added to this project it will add significant cost in terms of code size because they cannot be dead code eliminated.
https://groups.google.com/forum/#!topic/clojurescript/3rL8vKzyJQA

So future built in rendereres will have to be based on protocols to allow unused renderers to be removed.

Decide whether this should be the default. Have a way to opt out if so. Maybe a field key?

Any thoughts about what could trigger this error? I get it when I try to parse the form input:

item-type-as-keyword (keyword (get-in request [:params :item-type]))

the-form (secretary/get-from-interactions [:schema item-type-as-keyword])

item (:params request)

item (if (:item-name item)
item
(assoc item :item-name (make-item-name item)))

item (fp/parse-params the-form item)

That last line triggers the error.

"the-form" is the Formative form definition. "item" is the :params from request when the form is submitted.

Hi,

I saw ngFormBuilder from form.io and I think it is great for prototyping and fast form development.
It would be great if Formative could have something like this.
I saw there is a form renderer in the examples but no form builder.

I've posted the question here as well https://clojureverse.org/t/are-there-any-gui-form-builders-in-clojure-script-world-like-from-ios-ngformbuilder/6212 .

The whole form.io ecosystem comes a lot of features that you can use to deliver a working app/ prototype very fast.

e.g., :staff.location-id => "staff[location-id]"

What about validations?

Topics

• Creating custom field types
• Building/modifying fields at runtime

When I try to render a checkbox I get an extra hidden input field.
Is this necessary?

(form-core/render-form {:fields [{:name :some-nome :label "Some Label"  :type :checkbox}]
                        :values {}
                        :submit-label "Submit"})

[:div
 {:class "form-shell form-horizontal bootstrap-form"}
 nil
 [:form
  {:method "POST"}
  (()
   ([:fieldset
     {:class "fieldset-some-nome"}
     ([:div
       {:id "row-field-some-nome", :class "field-group  control-group checkbox-row"}
       ([:div {:class "empty-shell"} nil]
        [:div
         {:class "input-shell controls"}
         nil
         [:label.checkbox
          {:for "field-some-nome"}
          " "
          ((nil [:input {:value "false", :name "some-nome", :type "hidden"}])
           (nil [:input {:checked false, :value "true", :id "field-some-nome", :name "some-nome", :type "checkbox"}]))
          " "
          [:span.cb-label "Some Label"]]
         nil
         nil
         nil])])]
    [:fieldset
     {:class "fieldset-submit"}
     ([:div
       {:id "row-field-submit", :class "form-actions submit-group  control-group submit-row"}
       ([:div {:class "empty-shell"} nil]
        [:div
         {:class "input-shell"}
         nil
         (nil [:input {:value "Submit", :class " btn btn-primary", :id "field-submit", :name "submit", :type "submit"}])
         nil
         nil
         nil])])]))]]

E.g., :enctype :multipart

• show current value, checkbox to delete, file input for new upload
• parses to map with current value, checkbox value, new upload
• multiple uploads?

single select: "9 am", "10 am", etc.

also, :start and :end

Manually syncing them does not seem feasible, so need to figure this one out...

The problem for me is using formative-generated hiccup vectors in sablono, but lack of support for the tag in Reactjs.DOM is the underlying issue. Also, the w3c discourages its use.

When specifying a :datatype on fields, validation raises error-messages, but those aren't customizable.

Could you make the messages customizable, please?

date + time may require a composite field type

How can I make horizontal Bootstrap 3 layouts like in the Bootstrap documentation?

Currently formative.util is broken for cljs as of 0.8.9

Relevant links:
http://dev.clojure.org/jira/browse/CLJS-324
https://github.com/jkk/formative/blob/master/src/formative/util.cljc#L133
https://groups.google.com/forum/#!topic/clojure-dev/URrnaU6KWQk

How to make it 'work'
http://stackoverflow.com/questions/34667532/clojure-clojurescript-e-g-the-format-function

Figure out a way to support multi-column layouts in the default renderer, without having to use custom css.

Example from squidz on IRC: http://imgur.com/4Rlw4Q8

I noticed the formative.util/escape-html function implemented to sanitise incoming HTML. Is there a way to tell Formative to escape incoming strings for certain form definitions?

Should labels/layout be handled specially?

:separator - what to put in between rendered fields

:combiner - how to combine rendered fields - (fn [fields-by-name] ...)

Currently the problem rendering logic is hard coded to bootstrap flavor,
and making this pluggable would be nice.

Seems like current logic always will look up the dom based on the :name field, so the error and problem classes do not get added if an :id is specified.

https://github.com/jkk/formative/blob/master/src/formative/dom.cljs#L85