Magic Table-fication

[jeremyevans]

Google Group Post: https://groups.google.com/g/ruby-forme/c/eBwJafEdWN4
Google Group Date: Sun, 11 May 2014 01:20:17 -0700
Google Group Sender: [email protected]

Part of the form I currently have puts associated subfields in rows. The :trtd formatter puts each record vertically, so I was going to need a new formatter.

I added “:td” to the :wrapper code that already handles :div :span and the like. “Just the … pair. That’s it. Nothing else.”

But when I tried it, Kazam! It was magically boxed up into a table, with a row, and with the form. WTF? I have absolutely no idea what magical code is causing that to happen!

I went on to create an input wrapper that would do the . And, pleasingly, the fields I put inside an f.inputs block were indeed placed in separate cells within a row. And all the .input fields outside were placed in another row. Sadly, the .subform did not use the inputs wrapper the way the .inputs block did. The subform’s fields were just cells in the same ‘everything left over row.’ If it’s not going to use the :inputs_wrapper that I define, then why does it insist on dressing up in a

when I don’t define one?

So I put the subform inside an .inputs. That did put it on a row of its own, but the hidden information got its own cell, so the subform had a big blank space at the beginning, since the other rows above it did not have hidden-only data stuck in a cell of its own.

I would suggest that all inputs shoudl be collected in their own special bucket, and dumped onto the form right after the

tag, entirely immune to all formatting commands &/or wrappers.

[jeremyevans]

Google Group Date: Sun, 11 May 2014 10:12:15 -0700
Google Group Sender: [email protected]

On Sunday, May 11, 2014 1:20:17 AM UTC-7, Dave Howell wrote:

Part of the form I currently have puts associated subfields in rows. The
:trtd formatter puts each record vertically, so I was going to need a new
formatter.

I added “:td” to the :wrapper code that already handles :div :span and the
like. “Just the … pair. That’s it. Nothing else.”

But when I tried it, Kazam! It was magically boxed up into a table, with a
row, and with the form. WTF? I have absolutely no idea what magical code is
causing that to happen!

I went on to create an input wrapper that would do the . And,
pleasingly, the fields I put inside an f.inputs block were indeed placed in
separate cells within a row. And all the .input fields outside were placed
in another row. Sadly, the .subform did not use the inputs wrapper the
way the .inputs block did. The subform’s fields were just cells in the same
‘everything left over row.’ If it’s not going to use the :inputs_wrapper
that I define, then why does it insist on dressing up in a

when
I don’t define one?

So I put the subform inside an .inputs. That did put it on a row of its
own, but the hidden information got its own cell, so the subform had a big
blank space at the beginning, since the other rows above it did not have
hidden-only data stuck in a cell of its own.

I would suggest that all inputs shoudl be collected in their own
special bucket, and dumped onto the form right after the

tag,
entirely immune to all formatting commands &/or wrappers.

A lot of this seems to suggest that you aren't actually looking at the
markup created by Forme, but markup created by the browser from parsing the
DOM.

Hidden inputs in general can't be collected into their own special bucket,
as that would break use in template. In may be possible to do it via a
custom serializer in non-template mode, though. However, in general it
shouldn't matter where hidden inputs appear in the form.

I think having a :td wrapper and :tr inputs_wrapper makes sense if you want
to lay out your inputs in a grid. I'll add that to my todo list. I'll see
if I run into the same issues that you had and can work through them.

Thanks,
Jeremy

[jeremyevans]

Google Group Date: Sun, 11 May 2014 15:38:48 -0700
Google Group Sender: [email protected]

On Sunday, May 11, 2014 10:12:15 AM UTC-7, Jeremy Evans wrote:

On Sunday, May 11, 2014 1:20:17 AM UTC-7, Dave Howell wrote:

But when I tried it, Kazam! It was magically boxed up into a table, with
a row, and with the form. WTF? I have absolutely no idea what magical code
is causing that to happen!

A lot of this seems to suggest that you aren't actually looking at the
markup created by Forme, but markup created by the browser from parsing the
DOM.

I wonder how long I would have been banging my head against the wall in
bafflement if you hadn't said that. Indeed. If I use Safari's "inspect
element", as I have been, because it gets me to the item in question
without having to wade through buckets of other stuff, Safari then goes and
makes shit up. I wonder if there's a "don't make stuff up" setting I can
toggle somewhere.

Hidden inputs in general can't be collected into their own special bucket,
as that would break use in template. In may be possible to do it via a
custom serializer in non-template mode, though. However, in general it
shouldn't matter where hidden inputs appear in the form.

As long as they don't become a "thing" inside a table cell that would
otherwise collapse, yes, it generally shouldn't matter. I've also seen it
have weird effects on linebreaking at times.

I think having a :td wrapper and :tr inputs_wrapper makes sense if you
want to lay out your inputs in a grid. I'll add that to my todo list.
I'll see if I run into the same issues that you had and can work through
them.

Thanks,
Jeremy