Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

the ability to provide :prefix and :suffix strings #46

Closed
justinfrench opened this Issue Sep 8, 2009 · 11 comments

Comments

Projects
None yet
3 participants
Owner

justinfrench commented Sep 8, 2009

Here's some real-world examples I've found recently:

[input] mt

[input] square meters

AU$ [input] excl. GST

These can all be "solved" with some help/hint text below the input or a verbose label, but I think we should try to figure out a better solution.

Contributor

grimen commented Sep 8, 2009

Just a first reflection how it could act...with custom component aspect of it (in HAML)

= f.input do |c|  # i.e. block_given? => true, renders LI still
  = c.field :length   # c could be a sort of "input builder", renders INPUT
  = 'square meters'

...and same pattern applies to a case I just had with Region + City selector aside:

= f.input do |c|
  = c.field :region
  = c.field :city

...or "f.wrap do" or similar, but input outputs LI right now so should maybe still be the wrapper.

Sleep on it until it's time for 1.x issues! ;)

Contributor

grimen commented Sep 8, 2009

I noticed you got a similar - but not identical - approach suggestion in the wiki. A little bit different though.

Contributor

grimen commented Nov 18, 2009

It would make my day (times 30) if this would get into Formtastic 1.0. I know, I know...it's just that this is soo fundamental stuff, and there seems to be a quite clear picture on how we want to solve this. Bugs me and my partners everyday we work with forms. 8/ With most things near perfect in Formtastic, so missing features like this annoying as a mosquito in a dark room.

Contributor

grimen commented Nov 27, 2009

My current suggestion for a DSL/usage solving this (inline inputs, prefixes, and suffixes) + custom form helpers issues:

= f.input do 
  = f.text_field :length 
  = f.my_cool_selector :length_unit, :default => 'giraffe-steps' 
  = link_to("What is this?", '#show_tooltip') 

Feels very neat if you ask me, adds no complexity at all, and no new concepts really. Straight-forward.

Contributor

grimen commented Dec 2, 2009

experimenting

Owner

justinfrench commented Jan 9, 2010

I think this will be better solved with custom inputs (:as => :price), which may be done in the DSL, may be done in partials, may be done some other way (I have something brewing), so I'm closing this issue off.

Contributor

grimen commented Jan 9, 2010

I very much disagree on this one, this one is a time-stealer in forms and as Formtastic is enforcing a LI elements for semantically purposes (with the positive effects) it makes it much harder to make semantically correct non-standard inputs (fields that belong together should belong together and not as seperate list items). I got a patch with specs, but not yet finalized a block issue but i know how to solve it now (just got it while fixing a show_for gem block issue). This and buttons is my only votes for 1.0, even more important than docs. The rest of the issues lately haven't affect the time me and the guys I worked with lately spend on forms (4 different projects). Inlined inputs in Formtastic made us hurl for real. =/

Owner

justinfrench commented Jan 9, 2010

Yes, but this ticket was about :prefix and :suffix string options to help with the lack of custom inputs. I opened it, now I'm closing it because I think that particular job is better solved another way, so I'm going to work on that instead.

Feel free to open another issue for the other topics touched upon in this issue.

joallard commented Mar 6, 2014

Hello there! I'm a reader from the future! Has this been solved in a fun way? Maybe we could get a link for future visitors; googling "formtastic prefix" gives here as 2nd result.

Owner

justinfrench commented Mar 6, 2014

@joallard nothing has been added to the API to facilitate prefixes and suffixes in this way, but we did pour a lot of effort into custom inputs, which make it really easy to do abstract what you're trying to.

For example, this:

<%= f.input :username, :as => :string, ..., :prefix => "<p>some kludge of crap here</p>" %>

Could be abstracted away to something really specific like:

<%= f.input :username, :as => :username %>

Or:

<%= f.input :username, :as => :string_with_introduction %>

In both of those cases you'd subclass StringInput for a narrower purpose.

This issue was closed.

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