Here's some real-world examples I've found recently:
[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.
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! ;)
I noticed you got a similar - but not identical - approach suggestion in the wiki. A little bit different though.
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.
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.
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.
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. =/
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.
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.
@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 %>
<%= f.input :username, :as => :string_with_introduction %>
In both of those cases you'd subclass StringInput for a narrower purpose.