Add a bunch of new input types #52

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@osener

osener commented May 28, 2012

Add a bunch of new form fields to match the spec. Most of them are
implemented in Webkit, Opera, IOS & Android browsers.

Add a bunch of new input types
Add a bunch of new form fields to match the spec. Most of them are
implemented in Webkit, Opera, IOS & Android browsers.
@siscia

This comment has been minimized.

Show comment Hide comment
@siscia

siscia Aug 19, 2012

I was looking for that... Now it is already time to implement more html5 stuff... Also the "required" (and autofocus ? )attribute could be very useful...

siscia commented Aug 19, 2012

I was looking for that... Now it is already time to implement more html5 stuff... Also the "required" (and autofocus ? )attribute could be very useful...

@weavejester

This comment has been minimized.

Show comment Hide comment
@weavejester

weavejester Aug 19, 2012

Owner

I'm not completely convinced we need all these fields. It seems like too many functions...

But assuming we do, we shouldn't create them by copy-pasting the same definition over and over, but instead use a doseq loop.

Owner

weavejester commented Aug 19, 2012

I'm not completely convinced we need all these fields. It seems like too many functions...

But assuming we do, we shouldn't create them by copy-pasting the same definition over and over, but instead use a doseq loop.

@siscia

This comment has been minimized.

Show comment Hide comment
@siscia

siscia Aug 19, 2012

We need these field because are implemented in the html5 standard... I guess we are trying to do something more complete as possible...

I completely agree that a better way than copy-and-paste is the way to go...

siscia commented Aug 19, 2012

We need these field because are implemented in the html5 standard... I guess we are trying to do something more complete as possible...

I completely agree that a better way than copy-and-paste is the way to go...

@weavejester

This comment has been minimized.

Show comment Hide comment
@weavejester

weavejester Aug 19, 2012

Owner

What I mean is that is it necessary to have a function like:

(url-field :foo)

When you can already write:

(text-field {:type :url} :foo)

?

Owner

weavejester commented Aug 19, 2012

What I mean is that is it necessary to have a function like:

(url-field :foo)

When you can already write:

(text-field {:type :url} :foo)

?

@osener

This comment has been minimized.

Show comment Hide comment
@osener

osener Aug 20, 2012

You are definitely right, at the time I just followed the general structure of the file and previously available elements like email-field (which is one of these html5 input types) to add a few fields I needed and it got out of hand :) Feel free to close it.

osener commented Aug 20, 2012

You are definitely right, at the time I just followed the general structure of the file and previously available elements like email-field (which is one of these html5 input types) to add a few fields I needed and it got out of hand :) Feel free to close it.

@siscia

This comment has been minimized.

Show comment Hide comment
@siscia

siscia Aug 20, 2012

At this point we could just make pubblic input-field and use it... Instead of abuse of text-field...

I still like the idea of add "required" (for the html5), but it would be a bigger work, don't it ?

siscia commented Aug 20, 2012

At this point we could just make pubblic input-field and use it... Instead of abuse of text-field...

I still like the idea of add "required" (for the html5), but it would be a bigger work, don't it ?

@osener

This comment has been minimized.

Show comment Hide comment
@osener

osener Aug 20, 2012

@siscia You can use something like this:

(email-field {:required true} "email")

osener commented Aug 20, 2012

@siscia You can use something like this:

(email-field {:required true} "email")
@weavejester

This comment has been minimized.

Show comment Hide comment
@weavejester

weavejester Aug 20, 2012

Owner

I don't think it's abusing text-field to use types like "url" or "email", as these are essentially more specialised types of text field. I'm beginning to think that email-field was a mistake that needs to be deprecated.

However, things like dates are another matter, and might need their own fields so that, for instance, you could specify a Java or JodaTime Date object as the value. Could we get away with one datetime-field, or would we need a function for each type? I'm not certain right now...

@osener is right about not needing additional arguments for the "required" attribute, as these can be added to the attribute map.

Owner

weavejester commented Aug 20, 2012

I don't think it's abusing text-field to use types like "url" or "email", as these are essentially more specialised types of text field. I'm beginning to think that email-field was a mistake that needs to be deprecated.

However, things like dates are another matter, and might need their own fields so that, for instance, you could specify a Java or JodaTime Date object as the value. Could we get away with one datetime-field, or would we need a function for each type? I'm not certain right now...

@osener is right about not needing additional arguments for the "required" attribute, as these can be added to the attribute map.

@siscia

This comment has been minimized.

Show comment Hide comment
@siscia

siscia Aug 21, 2012

Sorry for the required stuff, I trying it kinda late, and I put "require" instead of "required" and it didn't work...

@weavejester yes, honestly you are right about email-field, now I can see what you say. For the dates deal I will make a something like that:
(date {:name "datetime-field" :type "datetime"} datetime)

The only problem is that the date field are still not implemented by any browser...

siscia commented Aug 21, 2012

Sorry for the required stuff, I trying it kinda late, and I put "require" instead of "required" and it didn't work...

@weavejester yes, honestly you are right about email-field, now I can see what you say. For the dates deal I will make a something like that:
(date {:name "datetime-field" :type "datetime"} datetime)

The only problem is that the date field are still not implemented by any browser...

@osener

This comment has been minimized.

Show comment Hide comment
@osener

osener Aug 21, 2012

@siscia It is implemented by at least Opera and iirc a few mobile browsers.

osener commented Aug 21, 2012

@siscia It is implemented by at least Opera and iirc a few mobile browsers.

@siscia

This comment has been minimized.

Show comment Hide comment
@siscia

siscia Aug 21, 2012

@osener hummm http://www.w3schools.com/html5/html5_form_input_types.asp it say that even chrome implemeted it, but at least on my pc (fedora and vista) it didn't work...

Anyhow, @weavejester you should decided what is the best way to implemeted this new html5 field and finally close this pull request...

siscia commented Aug 21, 2012

@osener hummm http://www.w3schools.com/html5/html5_form_input_types.asp it say that even chrome implemeted it, but at least on my pc (fedora and vista) it didn't work...

Anyhow, @weavejester you should decided what is the best way to implemeted this new html5 field and finally close this pull request...

@simon-nicholls

This comment has been minimized.

Show comment Hide comment
@simon-nicholls

simon-nicholls Oct 3, 2012

Contributor

Personally, I like the explicit map use for declaring input types.

I wrap Hiccup field functions so that regular Hiccup field rendering is deferred, and parsing based on the type (and perhaps namespaced keywords) is added. Specify an input is for type url, and you will get a URL pop out of the form submission (or an error). Generate the form, and get it rendered to a string.

For me, it's nice that Hiccup's fields are regular, and closely match HTML tags. It's pretty important that additional abstractions can be built out of "basic stuff".

Contributor

simon-nicholls commented Oct 3, 2012

Personally, I like the explicit map use for declaring input types.

I wrap Hiccup field functions so that regular Hiccup field rendering is deferred, and parsing based on the type (and perhaps namespaced keywords) is added. Specify an input is for type url, and you will get a URL pop out of the form submission (or an error). Generate the form, and get it rendered to a string.

For me, it's nice that Hiccup's fields are regular, and closely match HTML tags. It's pretty important that additional abstractions can be built out of "basic stuff".

@osener osener closed this Jun 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment