Grid

[jeremyevans]

Google Group Post: https://groups.google.com/g/ruby-forme/c/_rDVitPcgmk
Google Group Date: Sun, 11 May 2014 16:25:39 -0700
Google Group Sender: group...@grandfenwick.net

BTW, I’m really quite amazed at how patient you are. THIS post is hopefully rant-free. Just questions and suggestions.

Okay, I’ve pushed the :tr inputs wrapper and :td wrapper back to GitHub.

And here’s this form, where the top part is a two-column list, easily created with :inputs_wrapper => :table and :wrapper => :trtd

Below that, but part of the same form, is the invoice item list, which I’d like to lay out in a grid. Now I’m kinda stuck.

What I think ought to work is

mainform = Forme.form(ord, {:action=>'/save'}, {:labeler=>:explicit, :wrapper=> :trtd, :inputs_wrapper=>:table}) do |f|
f.inputs do
f.input(:status)
f.input(:invoicedate, :label=>"Invoice Date")
f.input(:shippeddate, :label=>"Shipped Date")
f.input(:emaileddate, :label=>"Emailed Date")
f.input(:shippingcost, {:label=>"Extra Shipping"})
f.input(:container)
f.input(:source)
end
f.inputs do
f.subform(:items, :inputs_wrapper=> :tr, :wrapper=>:td) do
f.inputs do
f.input(:discount)
f.input(:salestax)
f.input(:name)
f.input(:quantity)
f.input(:price)
f.input(:shipping)
end
end
end
f.button(:value=>'Save Changes’)
end

Except that .subform doesn’t take any options except :legend and :inputs. I can get the individual subform items into cells by specifying :wrapper=>:td for each of them, but I still can’t get the parent in place.

Even slicker would be if I could do

f.inputs(:inputs_wrapper=>:gridtable) do
f.subform(:items, :inputs=>[:name, :quantity, :price, :shipping])
end

.inputs itself would wrap its children in the

tag, the subform would put each associated item in the , each input gets a . I forget off the top of my head.

It isn’t hard for me to imagine wanting to do something like

form(Artist.last, form_attr, { :inputs_wrapper=> :div, :wrapper=>:div, :wrapper_attr=>{:class => “artist}}) do |f|
f.inputs([:name], :legend=>:Artist, :subform_wrapper=>:ol, :wrapper=>:li) do
f.subform(:albums, :inputs=>[:name, :release_date, :copies_sold, :debut_album, :out_of_print]) do
f.subform(:tracks, :inputs=>[:number, :name, :length], :wrapper=>:gridtable)
f.subform(:tags, :inputs=>[:name], :subform_wrapper=>:ol, :wrapper=>:li)
end
end
f.button(:value=>'Update Artist')
end

I’m not sure I’ve put the various wrappers in the correct spots, but I think you get the idea.

Now, my current form builds a table that, at the top, is pretty much exactly what :inputs_wrapper=>:table, :wrapper=>:trtd, :labeler=>:explicit creates. Except for one little glitch. My labels are bold and flush right. This is handled by the CSS, which does things to td:first_child for tables that are “list” class.

Which is to say:

, and the labels would appear across the top in a	row. Or maybe it’s
…

et cetera et cetera.

I can add attributes to the

tag with :wrappers_attr, but there doesn’t appear to be an equivalent :input_wrappers_attr parameter. How do I set the “class” attribute on my table? (Yes, in this particular case, I could also redefine the CSS and set “class=‘list’” on each row, but I don’t know that that would always work, and it’s also messier….)

[jeremyevans]

Google Group Date: Sun, 11 May 2014 17:11:47 -0700
Google Group Sender: jeremy...@gmail.com

On Sunday, May 11, 2014 4:25:39 PM UTC-7, Dave Howell wrote:

BTW, I’m really quite amazed at how patient you are. THIS post is
hopefully rant-free. Just questions and suggestions.

Okay, I’ve pushed the :tr inputs wrapper and :td wrapper back to GitHub.

I see at
snarke@9c36230
that you did that, but in that commit you've also included the backout of
the previous changes you made to the labeler. What you probably want to do
is start with a new clone, make just the change to add the tr and td
wrappers, and commit that.

Note that most times you add a commit that changes behavior, you are going
to want to update the specs as well (in the spec directory). After
updating the specs, you can run the specs with rake. You'll have to
install sinatra and rails to run all of the specs, I think, but you can do:

rspec spec/forme_spec.rb

if you just want to run the core forme specs without the
sinatra/rails/sequel integration specs.

For simple things where you know the API you want to use an advance, it can
be helpful to write the specs first, then write the code that will make the
specs pass.

And here’s this form, where the top part is a two-column list, easily
created with :inputs_wrapper => :table and :wrapper => :trtd

Below that, but part of the same form, is the invoice item list, which I’d
like to lay out in a grid. Now I’m kinda stuck.

What I think ought to work is

mainform = Forme.form(ord, {:action=>'/save'}, {:labeler=>:explicit,
:wrapper=> :trtd, :inputs_wrapper=>:table}) do |f|
f.inputs do
f.input(:status)
f.input(:invoicedate, :label=>"Invoice Date")
f.input(:shippeddate, :label=>"Shipped Date")
f.input(:emaileddate, :label=>"Emailed Date")
f.input(:shippingcost, {:label=>"Extra Shipping"})
f.input(:container)
f.input(:source)
end
f.inputs do
f.subform(:items, :inputs_wrapper=> :tr, :wrapper=>:td)
do
f.inputs do
f.input(:discount)
f.input(:salestax)
f.input(:name)
f.input(:quantity)
f.input(:price)
f.input(:shipping)
end
end
end
f.button(:value=>'Save Changes’)
end

Except that .subform doesn’t take any options except :legend and :inputs.
I can get the individual subform items into cells by specifying
:wrapper=>:td for each of them, but I still can’t get the parent in
place.

This is because if you don't provide the :inputs option to subform, it
doesn't call Form#_inputs and won't use the inputs_wrapper. If you put
the :inputs_wrapper=> :tr in the call to inputs inside subform, that may
work. We may want to change subform such that it always calls Form#_inputs
even if no :inputs option is given.

Even slicker would be if I could do

    f.inputs(:inputs_wrapper=>:gridtable) do 
            f.subform(:items, :inputs=>[:name, :quantity, :price, 

:shipping])

    end 

.inputs itself would wrap its children in the

tag, the subform
would put each associated item in the , each input gets a . I forget off the top of my head.

This or some similar syntax is possible if we add:

1. ability to temporarily modify the form's options for a block, restoring
   it to the previous options when the block exits. That's not too difficult,
   but probably requires some refactoring.
2. Make the table inputs_wrapper respect the :inputs or similar option and
   create a

, and the labels would appear across the top in a	row. Or maybe it’s
…
for each of the labels. Make the table inputs_wrapper respect the :legend option and use a caption tag for it (unrelated but we might as well do it at the same time). It isn’t hard for me to imagine wanting to do something like form(Artist.last, form_attr, { :inputs_wrapper=> :div, :wrapper=>:div, :wrapper_attr=>{:class => “artist}}) do |f| f.inputs([:name], :legend=>:Artist, :subform_wrapper=>:ol, :wrapper=>:li) do f.subform(:albums, :inputs=>[:name, :release_date, :copies_sold, :debut_album, :out_of_print]) do f.subform(:tracks, :inputs=>[:number, :name, :length], :wrapper=>:gridtable) f.subform(:tags, :inputs=>[:name], :subform_wrapper=>:ol, :wrapper=>:li) end end f.button(:value=>'Update Artist') end I’m not sure I’ve put the various wrappers in the correct spots, but I think you get the idea. I think with the above changes, something like this will be possible. options such as wrapper that are passed to subform will temporarily modify the form's options so that they affect the input tags inside the subform. I'm not sure we want to add a subform_wrapper option, it probably should just use the inputs_wrapper option. Now, my current form builds a table that, at the top, is pretty much exactly what :inputs_wrapper=>:table, :wrapper=>:trtd, :labeler=>:explicit creates. Except for one little glitch. My labels are bold and flush right. This is handled by the CSS, which does things to td:first_child for tables that are “list” class. Which is to say: et cetera et cetera. I can add attributes to the tag with :wrappers_attr, but there doesn’t appear to be an equivalent :input_wrappers_attr parameter. How do I set the “class” attribute on my table? (Yes, in this particular case, I could also redefine the CSS and set “class=‘list’” on each row, but I don’t know that that would always work, and it’s also messier….) Modifying the :table inputs_wrapper to support attributes on the table is actually a fairly simple thing to do. Just change the call method do something like: form.tag(:table, opts[:attr] &block) and you should be able to get the output you want via: f.inputs(:inputs_wrapper=>:table, :attr=>{:class=>'list'}) I'm going to be busy at work this week, so I'm not sure when I'll be able to implement these features. Hopefully I'll have a chance later in the week. Thanks for the feedback. Jeremy

[jeremyevans]

Google Group Date: Sun, 11 May 2014 19:01:15 -0700
Google Group Sender: group...@grandfenwick.net

On May 11, 2014, at 17:11 , Jeremy Evans jeremy...@gmail.com wrote:

I see at snarke@9c36230 that you did that, but in that commit you've also included the backout of the previous changes you made to the labeler. What you probably want to do is start with a new clone, make just the change to add the tr and td wrappers, and commit that.

I do? Er, why?

Note that most times you add a commit that changes behavior, you are going to want to update the specs as well (in the spec directory).

{looks in specs directory}

{blinks}

Boy, that’s rather like reading PERL code. It almost makes sense.

Y’know, I don’t really expect anybody to ever use my fork, including me. I think of it more as a fairly tidy way to propose changes for you to review. You might, on occasion, actually say to yourself “oh, that seems fine.” You’re more likely to say “well, I see what Dave’s getting at here, but that’s fairly inflexible/will fail under these other conditions/isn’t idiomatic with the rest of the code” and then rewrite it properly. Sometimes you’ll say “oh, he’s trying to do X, but the existing code already does that in this way he didn’t figure out,” and sometimes you’ll say “Well, that’s just a dumb idea.”

At some point I will throw the whole thing away, and fork a fresh new copy from yours.

That’s my plan, at least.

[jeremyevans]

Google Group Date: Sun, 11 May 2014 22:11:39 -0700
Google Group Sender: group...@grandfenwick.net

On May 11, 2014, at 17:11 , Jeremy Evans jeremy...@gmail.com wrote:

This is because if you don't provide the :inputs option to subform, it doesn't call Form#_inputs and won't use the inputs_wrapper. If you put the :inputs_wrapper=> :tr in the call to inputs inside subform, that may work. We may want to change subform such that it always calls Form#_inputs even if no :inputs option is given.

I think that being able to contain a subform inside a tag should be independent of whether or not I use the :inputs parameter. . . .

This or some similar syntax is possible if we add:

1. ability to temporarily modify the form's options for a block, restoring it to the previous options when the block exits. That's not too difficult, but probably requires some refactoring.
2. Make the table inputs_wrapper respect the :inputs or similar option and create a for each of the labels.
3. Make the table inputs_wrapper respect the :legend option and use a caption tag for it (unrelated but we might as well do it at the same time).

I’m thinking at this point that Forme actually is doing two very different things. First (esp. with the Sequel bridge), it is building input statements that can present multiple instances of associated models of a model and be able to keep separate, and identify, which data belong to which record when the form is submitted.

At the same time, Forme is providing markup utilities, making it easier to affect the appearance of the form.

When I say Form.form(sequelobject, form_attr, form_opts), the first argument is for the first function, the second argument is for the second, and the third tends to affect both of them. More specifically, ::form is going to eventually be a

tag, and the 2nd argument to it will become the tag’s attributes, yes?

::input also is going to create a tag, possibly with children. But to add an attribute to this one, I have to do :attr=>{:my attribute => “something”}

I would propose to you that, rather than have .inputs always call Form#_inputs, a better solution is to not have an :inputs_wrapper at all.

Let’s start with the form-functional tags: et cetera. Most if not all of these may have not only functional attributes, but also appearance ones. Frequently, we want to contain them within other tags (e.g. , ), and will want to set attributes on same; the wrapper. Finally, in order to avoid having to specify wrappers for every single form tag, it’s nice to be able to provide a default wrapper for a tag’s children. Now, if I understand what’s going on in Forme at the moment, when I specify a :wrapper for an .input, I’m specifying an external, or shell wrapper. But when I specify the :wrapper on a .form, I’m specifying an internal, or inherited wrapper. .inputs is both a way of iterating over a list of objects to generate tags for, but also an intermediate stage that can provide grouping for tags. It’s wrapper is specified by .form; ergo :inputs_wrapper is also an inherited wrapper. .subform strongly implies grouping as well, although I’m not sure if it’s unavoidable. Would one automatically group a subform that had only one record? Probably.

Anyway, I would like to offer for your consideration the following re-design. Forme.form, .input, .inputs, .tag, .subform, and possibly a few more should all accept :wrapper as an optional parameter, and all of them would use the wrapper as a shell: it controls what surrounds the tag they represent. It also defaults to being the wrapper inherited by this elements children. Then there’s another parameter (replacing :inputs_wrapper, I guess), that could be set to an alternative inherited wrapper. Thus, if you want this element to be in a list, but for the childrent to be assembled into a table, you don’t have to tell every single child :wrapper=> table; you can set it once in the parent and let them all inherit it.

Some wrapping structures don’t permit input elements at every level. You put a

with an input and another

, no big deal, but if you start a list, you then have to move into a list item before you can do input, and a table requires two steps.

Forme.form(obj, :wrapper=>:div) would put a

around the form.
Forme.form(obj, :wrapper=>:olist) would put the form inside an

tag. :wrapper=>:table would put it inside a tag.

Forme.form(obj, :wrapper=>:div){|f| f.input(:album)} would make the input a child of another

. With Forme.form(obj, :wrapper=>:olist){|f| f.input(:album)}, the :list wrapper knows that the input has to be inside an

tag, but it’s already inside an

, so just an
1. will do.

   Given Forme.form(obj, :wrapper=>:olist){|f| f.group{ f.input(:album)}}. The

2. that would normally appear here can only contain one input tag. The .group method implies multiple children, so the wrapper outputs “
”, and its children will be wrapped in
4. tags within the nested list.

   Forme.form(obj, :wrapper=>:olist){|f| f.group{ f.subform(:tracks)}}; .subform is also a grouping tag, so the wrapper would wrap the subform as “

5. ”, with each child of the subform getting an “
   1. ” of its own.

      If you want the tag outside the first list, then you’d say Forme.form(obj, :child_wrapper=>:olist){|f| f.group{ f.input(:album)}}

      Forme.form(obj, :wrapper=>:table) would work the same, except that grouping tags might become

or might become , but the wrapper will put tables in tables if needed to get inside a

for its content. With this approach, if I’ve set the form wrapper to :div, but I want a field set, I would set :wrapper=>:fieldset or maybe :wrapper=>:default on the .group or .inputs or .subform call itself . This also turns Forme:form(obj, :inputs_wrapper=>:table, :wrapper=>:trtd) into Forme:form(obj, :wrapper=>:table). If I have .input calls as the immediate children, the result is like :trtd; each input gets its own row. If I put the inputs in a group, then I would get a gridtable. What do you think?

[jeremyevans]

Google Group Date: Mon, 12 May 2014 08:40:11 -0700
Google Group Sender: jeremy...@gmail.com

On Sunday, May 11, 2014 10:11:39 PM UTC-7, Dave Howell wrote:

On May 11, 2014, at 17:11 , Jeremy Evans wrote:

This is because if you don't provide the :inputs option to subform, it
doesn't call Form#_inputs and won't use the inputs_wrapper. If you put the
:inputs_wrapper=> :tr in the call to inputs inside subform, that may work.
We may want to change subform such that it always calls Form#_inputs even
if no :inputs option is given.

I think that being able to contain a subform inside a tag should be
independent of whether or not I use the :inputs parameter. . . .

I think that means that subform should always call Form#_inputs (using the
inputs_wrapper). I agree with that, and will add that to my todo list.

This or some similar syntax is possible if we add:

1. ability to temporarily modify the form's options for a block,
   restoring it to the previous options when the block exits. That's not too
   difficult, but probably requires some refactoring.
2. Make the table inputs_wrapper respect the :inputs or similar option
   and create a for each of the labels.
3. Make the table inputs_wrapper respect the :legend option and use a
   caption tag for it (unrelated but we might as well do it at the same time).

I’m thinking at this point that Forme actually is doing two very different
things. First (esp. with the Sequel bridge), it is building input
statements that can present multiple instances of associated models of a
model and be able to keep separate, and identify, which data belong to
which record when the form is submitted.

At the same time, Forme is providing markup utilities, making it easier to
affect the appearance of the form.

When I say Form.form(sequelobject, form_attr, form_opts), the first
argument is for the first function, the second argument is for the second,
and the third tends to affect both of them. More specifically, ::form is
going to eventually be a

tag, and the 2nd argument to it will become
the tag’s attributes, yes?

I tend to think of it as a Forme is doing a single thing (building an html
form), which takes multiple steps. The first step is figuring out what
inputs to use on the form. The second step is taking those inputs and
outputting the appropriate html. As you mentioned, attributes mostly
affect the second step, while options can affect both.

::input also is going to create a tag, possibly with children. But to add
an attribute to this one, I have to do :attr=>{:my attribute =>
“something”}

Correct. In some cases to make simple things easy you can use an option
(e.g. :name, :class, :id) and that gets copied to the attributes.

I would propose to you that, rather than have .inputs always call
Form#_inputs, a better solution is to not have an :inputs_wrapper at all.

Let’s start with the form-functional tags: et cetera. Most if not all of these may have not only functional attributes, but also appearance ones. Frequently, we want to contain them within other tags (e.g. , ), and will want to set attributes on same; the wrapper. Finally, in order to avoid having to specify wrappers for every single form tag, it’s nice to be able to provide a default wrapper for a tag’s children. Now, if I understand what’s going on in Forme at the moment, when I specify a :wrapper for an .input, I’m specifying an external, or shell wrapper. But when I specify the :wrapper on a .form, I’m specifying an internal, or inherited wrapper. Setting :wrapper or similar options on the Form instance just sets the defaults for the Input instances created by the form. You can override that on a per-instance basis by passing the same option when creating the Input. .inputs is both a way of iterating over a list of objects to generate tags for, but also an intermediate stage that can provide grouping
for tags. It’s wrapper is specified by .form; ergo
:inputs_wrapper is also an inherited wrapper. .subform strongly implies
grouping as well, although I’m not sure if it’s unavoidable. Would one
automatically group a subform that had only one record? Probably.

The :inputs_wrapper is basically the equivalent of :wrapper, except that it
applies to a group of related inputs specified by Form#inputs, instead of
individual inputs. Just like :wrapper, the :inputs_wrapper option on the
Form sets the default, you can override it on a per-call basis by passing
the :inputs_wrapper option to Form#inputs.

Anyway, I would like to offer for your consideration the following
re-design. Forme.form, .input, .inputs, .tag, .subform, and possibly a few
more should all accept :wrapper as an optional parameter, and all of them
would use the wrapper as a shell: it controls what surrounds the tag they
represent. It also defaults to being the wrapper inherited by this elements
children. Then there’s another parameter (replacing :inputs_wrapper, I
guess), that could be set to an alternative inherited wrapper. Thus, if you
want this element to be in a list, but for the childrent to be assembled
into a table, you don’t have to tell every single child :wrapper=> table;
you can set it once in the parent and let them all inherit it.

Basically, you want to continue to use inputs_wrapper and wrapper as
concepts, but change the API to specify the :wrapper, and for groups of
inputs (e.g. Form#inputs), automatically map the :wrapper to the
appropriate inputs_wrapper (or vice-versa). So specifying a
:wrapper=>:table would basically imply the current :inputs_wrapper=>:table,
:wrapper=>:trtd.

I think such a thing is possible with some refactoring. I think it makes
sense to do that simply to reduce the verbosity. For backwards
compatibility, you can still specify both options, but if you only specify
:wrapper and not :inputs_wrapper, it will choose the appropriate
:inputs_wrapper based on the value provided by :wrapper.

Some wrapping structures don’t permit input elements at every level. You

put a

with an input and another

, no big deal, but if you start
a list, you then have to move into a list item before you can do input, and
a table requires two steps.

Forme.form(obj, :wrapper=>:div) would put a

around the form.

This actually doesn't happen. If you want to wrap the form in a tag, you
just take the output of the form and put it inside the appropriate tag
yourself. Forme.form always returns as the root tag.

Forme.form(obj, :wrapper=>:olist) would put the form inside an

tag.
:wrapper=>:table would put it inside a tag.

Likewise, this can't put the form inside those tags. I'm not sure that
html allows form to appear as a child tag of ol or table.

Forme.form(obj, :wrapper=>:div){|f| f.input(:album)} would make the input
a child of another

. With Forme.form(obj, :wrapper=>:olist){|f|
f.input(:album)}, the :list wrapper knows that the input has to be inside
an

tag, but it’s already inside an

, so just an
1. will do.

Forme.form(obj, :wrapper=>:div){|f| f.input(:album)} would do something
like:

...

Forme.form(obj, :wrapper=>:olist){|f| f.input(:album)} would do something
like:

...

To actually get the ol tag, you'd need to use inputs to wrap things:

Forme.form(obj, :wrapper=>:olist){|f| f.inputs{f.input(:album)}}

1. ...

   I don't think we can automatically have Forme.form automatically use
   :inputs to wrap things by default, though maybe we can enable that via an
   option.

   Given Forme.form(obj, :wrapper=>:olist){|f| f.group{ f.input(:album)}}.
   The

   that would normally appear here can only contain one input tag.
   The .group method implies multiple children, so the wrapper outputs
   “

   ”, and its children will be wrapped in

   tags within
   the nested list.

   OK, this basically should work as you describe, assuming f.group is
   basically the same as f.inputs.

   Forme.form(obj, :wrapper=>:olist){|f| f.group{ f.subform(:tracks)}};
   .subform is also a grouping tag, so the wrapper would wrap the subform as
   “

   ”, with each child of the subform getting an “
   1. ” of its own.

   This is problematic as subform uses an inputs_wrapper and not a wrapper, so
   you'd end up with something like:

   1. ...

      instead of:

      1. 1. ...

            It probably could be supported, but we'd have to add an option that wraps
            subform with wrapper after it has been wrapped by inputs wrapper.

            If you want the tag outside the first list, then you’d say
            Forme.form(obj, :child_wrapper=>:olist){|f| f.group{ f.input(:album)}}

            As stated above, is always the root tag returned, so I don't think
            you'd want a :child_wrapper option.

            Forme.form(obj, :wrapper=>:table) would work the same, except that
            grouping tags might become

or might become , but the wrapper
will put tables in tables if needed to get inside a

for its content. Assuming we implemented the wrapper/inputs_wrapper integration I described above, you should be able to do: Forme.form(obj, :wrapper=>:table){f.inputs{f.input(:foo)}} .... With this approach, if I’ve set the form wrapper to :div, but I want a field set, I would set :wrapper=>:fieldset or maybe :wrapper=>:default on the .group or .inputs or .subform call itself . Yes. This is basically the same way things work now, where input/inputs specific options override the form options. This also turns Forme:form(obj, :inputs_wrapper=>:table, :wrapper=>:trtd) into Forme:form(obj, :wrapper=>:table). If I have .input calls as the immediate children, the result is like :trtd; each input gets its own row. If I put the inputs in a group, then I would get a gridtable. I'm not sure it's possible to differentiate between immediate children calls from children inside grouping calls. It may be possible, but I can't think of a simple solution right now to do so. Thanks, Jeremy

[jeremyevans]

Google Group Date: Tue, 13 May 2014 22:39:17 -0700
Google Group Sender: group...@grandfenwick.net

On May 12, 2014, at 8:40 , Jeremy Evans jeremy...@gmail.com wrote:

Some wrapping structures don’t permit input elements at every level. You put a

with an input and another

, no big deal, but if you start a list, you then have to move into a list item before you can do input, and a table requires two steps.

Forme.form(obj, :wrapper=>:div) would put a

around the form.

This actually doesn't happen. If you want to wrap the form in a tag, you just take the output of the form and put it inside the appropriate tag yourself. Forme.form always returns

as the root tag.

I know. But it seems inconsistent to me, so I’m suggesting it should. Or, “:wrapper” should not be a parameter that .form accepts, if it doesn’t actually wrap the form, since it does affect what gets wrapped around the other things that accept it.

In a nutshell, I think :wrapper ought to mean the same thing whenever it gets used. It could either set what is used to wrap the command it’s passed to, or it could set what the children get wrapped in. The problem with having it set up the the children is that it becomes a hassle to then override the wrapper for a particular input, because you’d have to do the override in a parent, but a parent of just this one input.

If, on the other hand, :wrapper defines what gets wrapped around the command, then you can just set it for a particular input and it changes what that input is wrapped in. But, that means if you set :wrapper on .form, the form should be wrapped.

Forme.form(obj, :wrapper=>:olist){|f| f.input(:album)} would do something like:

...

To actually get the ol tag, you'd need to use inputs to wrap things:

Forme.form(obj, :wrapper=>:olist){|f| f.inputs{f.input(:album)}}

1. ...

   I don't think we can automatically have Forme.form automatically use :inputs to wrap things by default, though maybe we can enable that via an option.

Are you saying you think we cannot, or that we should not?

Also, that’s not exactly what I’m proposing. When Forme needs to spit out an tag, whether or not .inputs would need to be called depends on what wrapper is active. If it’s the :div wrapper, the answer is “no.” If it’s the :olist wrapper and we’re not currently inside an

tag, the answer is “yes.” If it’s the :table wrapper and we’re not inside a , then it has to be called twice, once to get the , and again to get the .

This also means if I’ve said Forme.form(obj, :children_wrapper=>:table) do |f|… or if saying just :wrapper=> does not put the form inside a table, then if my next line is f.input(:sometextfield), the wrapper would respond with

“I’m not already in a table? I need to be, and then inside a row, and then I can make a cell, and then I have to close it all so when I’m all done spitting tags we’re back where we started.”

Conversely, if I say

Forme.form(obj, :children_wrapper=>:table) do |f|
f.inputs do
f.input…
f.input…
end
end

each input, during wrapping, has to call .inputs in order to get wrapped in a tag, before it can then put its label in one and its in a following one, and then pop back out with the

.subform has an implicit .inputs, or at least it does if it’s an XXX_to_many relationship.

Forme.form(obj, :children_wrapper=>:table, :label) do |f|
f.subform(items)
f.inputs{f.subform(:otheritems)}
end

The first .subform above would wrap each record in a

. Each field of the record would then have to wrap itself in a before it could then wrap itself in a , leaving each input to just wrap itself in a

(or multiple

s if it’s explicit labeling). The ‘otheritems’ subform is already wrapped in a table, so each record then wraps in a

. Thus, the first form would create the current :trtd-type vertical list table, and the second form would create the gridtable. I have not worked out how I think labeling works under the grid table scenario, but I think there’s a couple ways to handle it. I figured I’d wait until you decided if you liked the approach to wrapping before I spent a lot of time thinking about labels. If you call a subform within a subform, the process is the same. .input always starts by saying “what tag, if any, do I want to be wrapped in right now? Is that tag valid in the current context? If not, what tag does provide that context? OK, I wrap myself in that one too. [repeat until valid]" OK, this basically should work as you describe, assuming f.group is basically the same as f.inputs. I believe f.group{…} is the same as f.inputs(){…}. Forme.form(obj, :wrapper=>:olist){|f| f.group{ f.subform(:tracks)}}; .subform is also a grouping tag, so the wrapper would wrap the subform as “ ”, with each child of the subform getting an “ ” of its own. This is problematic as subform uses an inputs_wrapper and not a wrapper, so you'd end up with something like: ... instead of: … That’s why my version doesn’t have :inputs_wrapper. The regular :wrappers have to get smarter, so they know what context they’re in, and would know better than to do (well, the list and table wrappers do. The div wrapper can stay dumb.) I'm not sure it's possible to differentiate between immediate children calls from children inside grouping calls. It may be possible, but I can't think of a simple solution right now to do so. f.input doesn’t know who its parent is? Or rather, .input doesn’t know who ’s parent will be?

[jeremyevans]

Google Group Date: Wed, 14 May 2014 08:59:45 -0700
Google Group Sender: jeremy...@gmail.com

On Tuesday, May 13, 2014 10:39:17 PM UTC-7, Dave Howell wrote:

On May 12, 2014, at 8:40 , Jeremy Evans wrote:

Some wrapping structures don’t permit input elements at every level.
You put a

with an input and another

, no big deal, but if you
start a list, you then have to move into a list item before you can do
input, and a table requires two steps.

Forme.form(obj, :wrapper=>:div) would put a

around the form.

This actually doesn't happen. If you want to wrap the form in a tag,
you just take the output of the form and put it inside the appropriate tag
yourself. Forme.form always returns

as the root tag.

I know. But it seems inconsistent to me, so I’m suggesting it should. Or,
“:wrapper” should not be a parameter that .form accepts, if it doesn’t
actually wrap the form, since it does affect what gets wrapped around the
other things that accept it.

Well, it doesn't seem inconsistent to me, but maybe that's because I wrote
it. :) The transformer options (of which :wrapper is one) are handled
the following way for the two object types:

Forme::Form - Sets the default values for Inputs created by the Form
Forme::Input - Overrides the default value given by this Input's Form.

Also, :wrapper (and most other transformers) only handle Inputs, and the

created by Forme::Form#form isn't an Input, it's a Tag. So I don't think it's possible for :wrapper to wrap the tag even if we exposed an option for it.

In a nutshell, I think :wrapper ought to mean the same thing whenever it
gets used. It could either set what is used to wrap the command it’s passed
to, or it could set what the children get wrapped in. The problem with
having it set up the the children is that it becomes a hassle to then
override the wrapper for a particular input, because you’d have to do the
override in a parent, but a parent of just this one input.

This only makes sense if the options could mean the same thing for both
classes. In this case, they can't mean the same things. What would it
mean for wrapper, inputs_wrapper, labeler, error_handler, and formatter to
operate on the form itself instead of being an option to the form's inputs?

If, on the other hand, :wrapper defines what gets wrapped around the
command, then you can just set it for a particular input and it changes
what that input is wrapped in. But, that means if you set :wrapper on
.form, the form should be wrapped.

As I mentioned the tag created is a Tag, not an Input, and wrappers
only operate on Inputs. So I don't think it makes sense to expect this.

Forme.form(obj, :wrapper=>:olist){|f| f.input(:album)} would do
something like:

...

To actually get the ol tag, you'd need to use inputs to wrap things:

Forme.form(obj, :wrapper=>:olist){|f| f.inputs{f.input(:album)}}

1. ...

   I don't think we can automatically have Forme.form automatically use
   :inputs to wrap things by default, though maybe we can enable that via an
   option.

Are you saying you think we cannot, or that we should not?

Should not. It possible to do so by making Forme.form automatically call
inputs. But that's a complete break with backwards compatibility and no
longer allows you to wrap two groups of options separately (which is the
point of Form#inputs).

Also, that’s not exactly what I’m proposing. When Forme needs to spit out
an tag, whether or not .inputs would need to be called depends on
what wrapper is active. If it’s the :div wrapper, the answer is “no.” If
it’s the :olist wrapper and we’re not currently inside an

tag, the
answer is “yes.” If it’s the :table wrapper and we’re not inside a ,
then it has to be called twice, once to get the , and again to get
the .

Unfortunately, I think this is too much magic. You are trying to change
how the wrapper works based on whether the input is already enclosed in
another tag. But the way the library works, parent tags know their
children, but children tags aren't knowledgeable of their parents (the tags
containing them). I don't think this is possible without a pretty major
rewrite, and completely breaking backwards compatibility, neither of which
sounds very appealing.

I do understand why you want it, as it would reduce the amount of code you
have to write. But I think the costs of doing so outweigh the benefits.

Most of the rest of your post assumed that you can implement wrappers to be
context dependent. I read it but as it assumes something that won't be
implemented, I won't address the individual suggestions you made as they
are moot.

I'm not sure it's possible to differentiate between immediate children
calls from children inside grouping calls. It may be possible, but I can't
think of a simple solution right now to do so.

f.input doesn’t know who its parent is? Or rather, .input doesn’t know who
’s parent will be?

Both. The best it could do is look at the Form's nesting, but I don't
think that will work in all cases. It would also require that decisions be
made on Input creation instead of later during formatting (because the
Form's nesting can change between the two), which causes lots of issues.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 14 May 2014 12:19:33 -0700
Google Group Sender: group...@grandfenwick.net

On May 14, 2014, at 8:59 , Jeremy Evans jeremy...@gmail.com wrote:

Also, :wrapper (and most other transformers) only handle Inputs, and the

created by Forme::Form#form isn't an Input, it's a Tag. So I don't think it's possible for :wrapper to wrap the tag even if we exposed an option for it.

Aha. You’re thinking about the intermediate object, and I’m looking at the end result. .input might make an Input, but Input makes a Tag, and Tag makes a tag.

is a tag. is a tag.

is a tag.

In a nutshell, I think :wrapper ought to mean the same thing whenever it gets used. It could either set what is used to wrap the command it’s passed to, or it could set what the children get wrapped in. The problem with having it set up the the children is that it becomes a hassle to then override the wrapper for a particular input, because you’d have to do the override in a parent, but a parent of just this one input.

This only makes sense if the options could mean the same thing for both classes. In this case, they can't mean the same things. What would it mean for wrapper, inputs_wrapper, labeler, error_handler, and formatter to operate on the form itself instead of being an option to the form's inputs?

If they can’t mean the same thing, then they shouldn’t be the same parameter.

As I mentioned the tag created is a Tag, not an Input, and wrappers only operate on Inputs. So I don't think it makes sense to expect this.

If wrappers only operate on Inputs, then I submit that only Inputs should have a :wrapper parameter.

Unfortunately, I think this is too much magic. You are trying to change how the wrapper works based on whether the input is already enclosed in another tag. But the way the library works, parent tags know their children, but children tags aren't knowledgeable of their parents (the tags containing them). I don't think this is possible without a pretty major rewrite, and completely breaking backwards compatibility, neither of which sounds very appealing.

I know. I don’t propose it lightly.

I do understand why you want it, as it would reduce the amount of code you have to write. But I think the costs of doing so outweigh the benefits.

Actually, I don’t want it for reducing the amount of code I write. I want it because I think it will make writing the code easier. I’ve been struggling to use Forme because, as you may have noticed, I keep tripping over what it does vs. what I expect. I think we’ve just exposed one of the paradigms that had escaped me until now: that you see Forme methods that make “Inputs” as fundamentally different from ones that create “Tags.” As far as I was concerned, they all create tags, so where you saw blue commands and yellow commands, I just saw green commands, and a parameter that did X with blue commands did not-X with the yellow ones, leaving me baffled.

Most of the rest of your post assumed that you can implement wrappers to be context dependent. I read it but as it assumes something that won't be implemented, I won't address the individual suggestions you made as they are moot.

Well, you’d said a few weeks back that one of the reasons Forme wasn’t esp. well documented was because people weren’t using it a lot. It’s a bit of a chicken-and-egg scenario, but I know I would find it much easier to explain my version than yours. Of course, that’s not really that surprising. :) Given that it’s currently rev. 0.9.2, I thought that there might be an opportunity with a 1.x bump to, in fact, do an incompatible release, should the change be worth it.

I’ll table this for now, but I gotta say, even if the functionality of Forme doesn’t change, it’s still going to need an incompatible release in order to make what it does do more obvious and clear. I’m sure I’ll eventually figure out why you named two of the methods “.input” and “.inputs”, but for me, these two almost-identically named methods do wildly different things, and the similarity in naming is still incomprehensible. :wrapper appears to be short for “:input_wrapper,” and to also have “:inputs_wrapper”, well, I long ago installed a .gsub(‘inputs’,’something other than what “inputs” means to me’) in my head for Forme.

[jeremyevans]

Google Group Date: Wed, 14 May 2014 13:46:37 -0700
Google Group Sender: jeremy...@gmail.com

On Wednesday, May 14, 2014 12:19:33 PM UTC-7, Dave Howell wrote:

On May 14, 2014, at 8:59 , Jeremy Evans wrote:

Also, :wrapper (and most other transformers) only handle Inputs, and the

created by Forme::Form#form isn't an Input, it's a Tag. So I don't think it's possible for :wrapper to wrap the tag even if we exposed an option for it.

Aha. You’re thinking about the intermediate object, and I’m looking at the
end result. .input might make an Input, but Input makes a Tag, and Tag
makes a tag.

is a tag. is a tag.

is a tag.

Well, the end result may be a tag, but most of the transformers require an
Input object, so using them without an Input object isn't possible. For
this to work, Form#form would have to create an intermediate Input object.
That would cause issues, as Input objects are closed, while Tag objects
are open, in the sense that Tag objects can yield to blocks and accept
additional children, while Input objects cannot. I'm not sure how a
wrapper could work if the tag being wrapped could still have additional
objects appended to it.

In a nutshell, I think :wrapper ought to mean the same thing whenever
it gets used. It could either set what is used to wrap the command it’s
passed to, or it could set what the children get wrapped in. The problem
with having it set up the the children is that it becomes a hassle to then
override the wrapper for a particular input, because you’d have to do the
override in a parent, but a parent of just this one input.

This only makes sense if the options could mean the same thing for both
classes. In this case, they can't mean the same things. What would it
mean for wrapper, inputs_wrapper, labeler, error_handler, and formatter to
operate on the form itself instead of being an option to the form's inputs?

If they can’t mean the same thing, then they shouldn’t be the same
parameter.

I disagree that just because two options have the same name, they should
work exactly the same way for two separate classes. A Form is not a Input,
you shouldn't expect that they have identical APIs.

This begs the question, if you don't want the options to have the same
name, what name would you propose for the Form options?

I do understand why you want it, as it would reduce the amount of code
you have to write. But I think the costs of doing so outweigh the
benefits.

Actually, I don’t want it for reducing the amount of code I write. I want
it because I think it will make writing the code easier. I’ve been
struggling to use Forme because, as you may have noticed, I keep tripping
over what it does vs. what I expect. I think we’ve just exposed one of the
paradigms that had escaped me until now: that you see Forme methods that
make “Inputs” as fundamentally different from ones that create “Tags.” As
far as I was concerned, they all create tags, so where you saw blue
commands and yellow commands, I just saw green commands, and a parameter
that did X with blue commands did not-X with the yellow ones, leaving me
baffled.

Well, that's an important difference in understanding. Input and Tag
methods operate differently because the classes are different. A Tag is a
concrete representation (1-1 with html tags), and an Input is an abstract
representation with a number of different possible concrete
representations. What the formatter, error_handler, labeler, and wrapper
transformers do is work together to transform the abstract Input
representation into a concrete Tag representation.

Most of the rest of your post assumed that you can implement wrappers to
be context dependent. I read it but as it assumes something that won't be
implemented, I won't address the individual suggestions you made as they
are moot.

Well, you’d said a few weeks back that one of the reasons Forme wasn’t
esp. well documented was because people weren’t using it a lot. It’s a bit
of a chicken-and-egg scenario, but I know I would find it much easier to
explain my version than yours. Of course, that’s not really that
surprising. :) Given that it’s currently rev. 0.9.2, I thought that there
might be an opportunity with a 1.x bump to, in fact, do an incompatible
release, should the change be worth it.

Certainly breaking backwards compatibility is possible, and there are
already multiple backwards incompatible changes between 0.9.2 and the
master branch. That said, the changes that are made are hopefully minor
enough that that most current users will not need to change their code.
I'm unlikely to consider changes that will break the average user's setup
unless I see a very good reason to do so.

I’ll table this for now, but I gotta say, even if the functionality of
Forme doesn’t change, it’s still going to need an incompatible release in
order to make what it does do more obvious and clear. I’m sure I’ll
eventually figure out why you named two of the methods “.input” and
“.inputs”, but for me, these two almost-identically named methods do wildly
different things, and the similarity in naming is still incomprehensible.
:wrapper appears to be short for “:input_wrapper,” and to also have
“:inputs_wrapper”, well, I long ago installed a .gsub(‘inputs’,’something
other than what “inputs” means to me’) in my head for Forme.

input represents a singular input, inputs represents a group of related
inputs. The method names input and inputs I took from the very popular
Formtastic library (https://github.com/justinfrench/formtastic). I don't
think they are confusing or incomprehensible, though I suppose we could
could add an input_group alias for inputs if that would make things clearer.

The reason for the naming of :wrapper and :inputs_wrapper is that :wrapper
for input was introduced first, and was the only wrapper at that point.
When I added a wrapper for inputs, I needed to make the name different, so
I named it :inputs_wrapper. I suppose for consistency :wrapper could be
:input_wrapper, but since :wrapper is used much more than :inputs_wrapper,
having a shorter name is nice.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Wed, 14 May 2014 16:13:24 -0700
Google Group Sender: group...@grandfenwick.net

On May 14, 2014, at 13:46 , Jeremy Evans jeremy...@gmail.com wrote:

That would cause issues, as Input objects are closed, while Tag objects are open, in the sense that Tag objects can yield to blocks and accept additional children, while Input objects cannot.

Which I believe reflects the fact that is an HTML tag that cannot have children, wheras many other HTML tags can?

I disagree that just because two options have the same name, they should work exactly the same way for two separate classes. A Form is not a Input, you shouldn't expect that they have identical APIs.

No, a Form is not an Input, but then, I don’t usually work with Input, I’m usually calling .input on the Form instance. I’m never handling the Input object; I pass things to to the .input method, and I get a out the other side when the form closes.

This begs the question, if you don't want the options to have the same name, what name would you propose for the Form options?

Can I get back to you on that? I think I need to understand .form better before I can give you a confident reply.

input represents a singular input, inputs represents a group of related inputs. The method names input and inputs I took from the very popular Formtastic library (https://github.com/justinfrench/formtastic). I don't think they are confusing or incomprehensible, though I suppose we could could add an input_group alias for inputs if that would make things clearer.

Given how remarkably clear the Sequel library is, or rather, how good a job it does at failing to be as opaque as it obviously could be, especially given the astonishing flexibility and complexity it encapsulates, I took for granted that you weren’t doing anything with Forme that you thought was confusing or incomprehensible.

I also am quite clear that I am not the core audience for Forme. When I compare what I have created/coded/programmed, I think the evidence is fairly strong that I’m a pretty damn good programmer. However, because it’s not my full-time gig, my knowledge is very lumpy: I know a lot about X, and almost nothing about Y. Also, a lot of my knowledge has cobwebs. There’s also the lack of formal training, especially in modern programming practices or even terminology.

On the third hand, one of the other skills I have is being other people. When I was doing game design/testing/editing at Wizards of the Coast, one of the things I specialized in was pointing out what might be confusing to non-core-gamers. Would kids get this? Would my Mom?

So I’m trying to be as clear as I can about what has been giving me trouble with Forme, and why, and how I think it could me made clearer, particularly for people who are fairly new to programming or Ruby or HTML forms or whatnot. If I do that well, you can in turn say “Ah, yea, I can see how that might also confuse some of my core audience,” or “pfft, 99.9% of the people who’d even look at Forme know exactly what a DSL is, there’s no need to spell it out.”

One of the things I really love about Ruby is its guessability. Whether its [4..76], a Sequel::Model, or a hash, ::each does the same thing, or something so similar as to be quite obvious. That’s awesome.

The reason for the naming of :wrapper and :inputs_wrapper is that :wrapper for input was introduced first, and was the only wrapper at that point. When I added a wrapper for inputs, I needed to make the name different, so I named it :inputs_wrapper. I suppose for consistency :wrapper could be :input_wrapper, but since :wrapper is used much more than :inputs_wrapper, having a shorter name is nice.

The shorter name is nice.

Okay, I’ll keep working on figuring out what Forme really does, and get back to you regarding possible aliases for parameters.

[jeremyevans]

Google Group Date: Wed, 14 May 2014 20:22:54 -0700
Google Group Sender: jeremy...@gmail.com

On Wednesday, May 14, 2014 4:13:24 PM UTC-7, Dave Howell wrote:

On May 14, 2014, at 13:46 , Jeremy Evans wrote:

That would cause issues, as Input objects are closed, while Tag objects
are open, in the sense that Tag objects can yield to blocks and accept
additional children, while Input objects cannot.

Which I believe reflects the fact that is an HTML tag that cannot
have children, wheras many other HTML tags can?

That's true, but no really related. tags can have children, but in Forme input(:select) and tag(:select) operate differently. You can do: input = f.input(:select, :options=>[1, 2, 3]) but: tag = f.tag(:select) tag << f.tag(:option, {}, 1) tag << f.tag(:option, {}, 2) tag << f.tag(:option, {}, 3) The f.input(:select) call is self contained, but the f.tag call is not. You can always add children to an existing Tag instance. input represents a singular input, inputs represents a group of related inputs. The method names input and inputs I took from the very popular Formtastic library (https://github.com/justinfrench/formtastic). I don't think they are confusing or incomprehensible, though I suppose we could could add an input_group alias for inputs if that would make things clearer. Given how remarkably clear the Sequel library is, or rather, how good a job it does at failing to be as opaque as it obviously could be, especially given the astonishing flexibility and complexity it encapsulates, I took for granted that you weren’t doing anything with Forme that you thought was confusing or incomprehensible. I also am quite clear that I am not the core audience for Forme. When I compare what I have created/coded/programmed, I think the evidence is fairly strong that I’m a pretty damn good programmer. However, because it’s not my full-time gig, my knowledge is very lumpy: I know a lot about X, and almost nothing about Y. Also, a lot of my knowledge has cobwebs. There’s also the lack of formal training, especially in modern programming practices or even terminology. On the third hand, one of the other skills I have is being other people. When I was doing game design/testing/editing at Wizards of the Coast, one of the things I specialized in was pointing out what might be confusing to non-core-gamers. Would kids get this? Would my Mom? So I’m trying to be as clear as I can about what has been giving me trouble with Forme, and why, and how I think it could me made clearer, particularly for people who are fairly new to programming or Ruby or HTML forms or whatnot. If I do that well, you can in turn say “Ah, yea, I can see how that might also confuse some of my core audience,” or “pfft, 99.9% of the people who’d even look at Forme know exactly what a DSL is, there’s no need to spell it out.” And I appreciate that very much. In some cases, what Forme does may not be intuitive, and may not be able to made intuitive, in which case the hope is that the documentation is good enough to explain how things work. Obviously we aren't there yet. One of the things I really love about Ruby is its guessability. Whether its [4..76], a Sequel::Model, or a hash, ::each does the same thing, or something so similar as to be quite obvious. That’s awesome. That's certainly the type of API I try to create. But it isn't always possible to do so, or if it is possible, sometimes I fail to do so. Thanks, Jeremy

[jeremyevans]

Google Group Date: Thu, 15 May 2014 09:13:12 -0700
Google Group Sender: jeremy...@gmail.com

On Sunday, May 11, 2014 4:25:39 PM UTC-7, Dave Howell wrote:

It isn’t hard for me to imagine wanting to do something like

form(Artist.last, form_attr, { :inputs_wrapper=> :div, :wrapper=>:div,
:wrapper_attr=>{:class => “artist}}) do |f|
f.inputs([:name], :legend=>:Artist, :subform_wrapper=>:ol,
:wrapper=>:li) do
f.subform(:albums, :inputs=>[:name, :release_date,
:copies_sold, :debut_album, :out_of_print]) do
f.subform(:tracks, :inputs=>[:number, :name,
:length], :wrapper=>:gridtable)
f.subform(:tags, :inputs=>[:name],
:subform_wrapper=>:ol, :wrapper=>:li)
end
end
f.button(:value=>'Update Artist')
end

I’m not sure I’ve put the various wrappers in the correct spots, but I
think you get the idea.

I've added a :grid option to subform that does basically what you want.
Nested subforms need to be wrapped with td tags manually, but otherwise it
basically takes care of things for you. I've updated the demo site to show
how things work both with a single grid and nested grids.

Let me know what you think.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Sun, 18 May 2014 01:50:24 -0700
Google Group Sender: group...@grandfenwick.net

On May 15, 2014, at 9:13 , Jeremy Evans jeremy...@gmail.com wrote:

I've added a :grid option to subform that does basically what you want.

Yes, that does indeed look like what I want.

Let me know what you think.

{tinker tinker}

So I take it this is all still development-grade code? I think I’m either going to have to try to get an actual web server running on my laptop, or push my local github-ish copy of forme onto my web server. Hmm.

[jeremyevans]

Google Group Date: Sun, 18 May 2014 03:08:03 -0700
Google Group Sender: group...@grandfenwick.net

I pushed it onto the web server. I’m loading it with an explicit path.

This mostly worked:

f.subform(:items, {:inputs=>[:quantity, :name, :price, :shipping, :discount, :salestax], :grid=>true, :label=>""}) do
f << f.tag(:td)<<"delete"
end

The subform is ignoring my “Don’t label this please” label of “”.

I did successfully tack the ‘delete’ text at the end of the row. It’ll become a link next. Oh. Hmm. Well, partially successfully. There’s an extra empty cell between my ‘delete’ and the last cell of the subform.

Integers are getting ginormous text input boxes, and :name needs to be a heck of a lot wider. To be sure, my previous solution wasn’t the most elegant one. Your form comes back as a Forme:Tag. Mine came back as a REXML:Element. If I convert my Forme form into REXML, I can do the same patch:

mainform = Forme:form(……..){…….}
mainform.to_s.as_xml.elements.each("//[@name]"){|xm| if xm.attributes['name'].match(/name]$/) then xm.attributes["size"] = 100 end}

My hunch is that a better way to do this with Forme is to drop the inputs out of the parameters and into the block, where I can add attributes without making it turn into one ungodly long line. Yes?

Is there a way to set a default for database integer fields so that the end result is something like <input name=“field name” value=“4325” size=“8”> ?

[jeremyevans]

Google Group Date: Sun, 18 May 2014 08:11:32 -0700
Google Group Sender: jeremy...@gmail.com

On Sunday, May 18, 2014 1:50:24 AM UTC-7, Dave Howell wrote:

So I take it this is all still development-grade code? I think I’m either
going to have to try to get an actual web server running on my laptop, or
push my local github-ish copy of forme onto my web server. Hmm.

I'm not sure what you mean by "development-grade" code. There hasn't been
an official release with it yet, but unless bugs are discovered or features
are added, what's currently there will be in the next release.

In the meantime, you can either push your local repo to your webserver, or
build your own release (gem build forme.gemspec) and push that to your
webserver.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Sun, 18 May 2014 08:34:01 -0700
Google Group Sender: jeremy...@gmail.com

On Sunday, May 18, 2014 3:08:03 AM UTC-7, Dave Howell wrote:

I pushed it onto the web server. I’m loading it with an explicit path.

This mostly worked:

f.subform(:items, {:inputs=>[:quantity, :name, :price, :shipping,
:discount, :salestax], :grid=>true, :label=>""}) do
f << f.tag(:td)<<"delete"
end

The subform is ignoring my “Don’t label this please” label of “”.

The :label option is not respected for subform, you need to use :labels.
I've pushed a couple new commits that will make :labels=>nil or
:labels=>[] not add a header row.

I did successfully tack the ‘delete’ text at the end of the row. It’ll
become a link next. Oh. Hmm. Well, partially successfully. There’s an extra
empty cell between my ‘delete’ and the last cell of the subform.

If you are trying to add delete:

f << f.tag(:td, {}, ['delete'])

Integers are getting ginormous text input boxes, and :name needs to be a
heck of a lot wider. To be sure, my previous solution wasn’t the most
elegant one. Your form comes back as a Forme:Tag. Mine came back as a
REXML:Element. If I convert my Forme form into REXML, I can do the same
patch:

For sizing, you can either use css for styling or input_defaults with
:number=>{:size=>8}, and set the :size option for the name field explicitly:

f.subform(:items, :inputs=>[:quantity, [:name, {:size=>100}], :price,
:shipping, :discount, :salestax], :grid=>true, :labeler=>nil) do

mainform = Forme:form(……..){…….}
mainform.to_s.as_xml.elements.each("//[@name]"){|xm| if
xm.attributes['name'].match(/name]$/) then xm.attributes["size"] = 100
end}

My hunch is that a better way to do this with Forme is to drop the inputs
out of the parameters and into the block, where I can add attributes
without making it turn into one ungodly long line. Yes?

That may look better.

Is there a way to set a default for database integer fields so that the
end result is something like <input name=“field name” value=“4325”
size=“8”> ?

As shown above, :input_defaults=>{:number=>{:size=>8}} should get what you
want, assuming that it's the size attribute that you want to modify.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Mon, 19 May 2014 13:32:24 -0700
Google Group Sender: group...@grandfenwick.net

On May 18, 2014, at 8:11 , Jeremy Evans jeremy...@gmail.com wrote:

I'm not sure what you mean by "development-grade" code. There hasn't been an official release with it yet,

That’s what I mean. I can’t get the new features merely by upgrading the gem. :)

[jeremyevans]

Google Group Date: Mon, 19 May 2014 14:41:04 -0700
Google Group Sender: group...@grandfenwick.net

On May 18, 2014, at 8:34 , Jeremy Evans jeremy...@gmail.com wrote:

For sizing, you can either use css for styling or input_defaults with :number=>{:size=>8}, and set the :size option for the name field explicitly:

Where do I put :input_defaults? I’ve tried the first and second hashes of .form, the opt hash of .inputs, the opt hash of .subform, and as a parameter for .inputs, .subform, and .input. None of them had an effect.

[jeremyevans]

Google Group Date: Mon, 19 May 2014 17:27:01 -0700
Google Group Sender: jeremy...@gmail.com

On Monday, May 19, 2014 2:41:04 PM UTC-7, Dave Howell wrote:

On May 18, 2014, at 8:34 , Jeremy Evans wrote:

For sizing, you can either use css for styling or input_defaults with
:number=>{:size=>8}, and set the :size option for the name field
explicitly:

Where do I put :input_defaults? I’ve tried the first and second hashes of
.form, the opt hash of .inputs, the opt hash of .subform, and as a
parameter for .inputs, .subform, and .input. None of them had an effect.

It's a Form option, so the second hash to .form (the first hash is the
attributes for the

tag):

Forme.form({}, :input_defaults=>{:number=>{:size=>8}}){|f| puts
f.input(:number).to_s}

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Mon, 19 May 2014 20:11:21 -0700
Google Group Sender: group...@grandfenwick.net

On May 19, 2014, at 17:27 , Jeremy Evans jeremy...@gmail.com wrote:

It's a Form option, so the second hash to .form (the first hash is the attributes for the

tag):

Forme.form({}, :input_defaults=>{:number=>{:size=>8}}){|f| puts f.input(:number).to_s}
<input size="8" type="number”/>

Aha. It’s not working because that input’s type is “text” not “number.”

In Postgres, it’s a Numeric data type, not an integer. But I would have expected that to still be a number . . . .

[jeremyevans]

Google Group Date: Mon, 19 May 2014 21:59:21 -0700
Google Group Sender: jeremy...@gmail.com

On Monday, May 19, 2014 8:11:21 PM UTC-7, Dave Howell wrote:

On May 19, 2014, at 17:27 , Jeremy Evans wrote:

It's a Form option, so the second hash to .form (the first hash is the
attributes for the

tag):

Forme.form({}, :input_defaults=>{:number=>{:size=>8}}){|f| puts
f.input(:number).to_s}
<input size="8" type="number”/>

Aha. It’s not working because that input’s type is “text” not “number.”

In Postgres, it’s a Numeric data type, not an integer. But I would have
expected that to still be a number . . . .

I'm not sure how well the number input type is supported for non-integer
data in different browsers. Chrome seems to work with it, but I'll have to
check some other browsers and see how well they handle it. One issue in
Chrome is that if you don't provide a step attribute, it will default to
rounding up/down to the next integer, which is probably not too friendly.

Note that you can use :type=>:number to force the :number type for a
numeric field.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Mon, 19 May 2014 22:21:50 -0700
Google Group Sender: group...@grandfenwick.net

On May 19, 2014, at 21:59 , Jeremy Evans jeremy...@gmail.com wrote:

Aha. It’s not working because that input’s type is “text” not “number.”

In Postgres, it’s a Numeric data type, not an integer. But I would have expected that to still be a number . . . .

I'm not sure how well the number input type is supported for non-integer data in different browsers. Chrome seems to work with it, but I'll have to check some other browsers and see how well they handle it. One issue in Chrome is that if you don't provide a step attribute, it will default to rounding up/down to the next integer, which is probably not too friendly.

Note that you can use :type=>:number to force the :number type for a numeric field.

Hmm. But if I’m putting a special parameter in the input, I might as well just make that parameter :size=>8. A stepper for a dollar amount really doesn’t make sense anyway.