I have a page that has a very large form. That combined with the
database is optimized for flexibility rather than speed with many
joins and the server is not much of a machine and can be very slow
means I would like to consider if I can load the form in pieces via
AJAX. My question is does that violate any of the rules for forms and
tables ? The table is inside the form and each form field is a table
cell. If the form and table doesn’t completely load but increases in
size as each AJAX call builds it up, that seems like it would help the
problem of the slow load, but I am not sure if I would break any HTML
rules involving tables or forms doing it that way ? I seem to
encounter these types of problems from time to time, but then I forget
which thing it was after a while that the rule was about and I
possibly get confused thinking the restriction is something different
from what it really was. Maybe there is a good cheat sheet on what’s
not allowed in HTML and the common mistakes along those lines ?
On Oct 29, 2011, at 5:49 AM, Jedrin wrote:
rules involving tables or forms doing it that way ? I seem to
encounter these types of problems from time to time, but then I forget
which thing it was after a while that the rule was about and I
possibly get confused thinking the restriction is something different
from what it really was. Maybe there is a good cheat sheet on what’s
not allowed in HTML and the common mistakes along those lines ?
The basic rule for forms in HTML is that a form is a block-level
element; so any element which can accept a block-level child will
happily be its daddy, and any block-level element can be its direct
child. This means that a form can wrap around a table, or can be
contained entirely within a TD, and a form may contain a table or a div
or a p or a header or a fieldset or a list. (There’s probably more, and
the W3C DTD for the level of HTML you want to target would be the
authoritative source for this, but think about what tags you could get
away with putting as a direct child of the body tag, and that’s probably
the right tag to use.)
I would decouple the table cells from the individual form elements, and
load only the form elements through Ajax, replacing whatever placeholder
you put in the target TD.
So first pass, you make up all your TDs, and fill them with a spinner
gif or whatnot. Then your Ajax callbacks target each TD and replace the
spinner with the resulting form element(s). If TD is too granular, say
you know that each row of the table will have 10 tds, then maybe your
placeholder should be a tr with a single td set to colspan 10 and the
spinner in that. Then update the TR in one whack. You’ll want to put an
ID on whatever element you decide to update.
Walter
On Sat, Oct 29, 2011 at 05:49, Jedrin [email protected] wrote:
I would like to consider if I can load the form in pieces via AJAX.
The big question is, can you group the elements so that they are from
a simpler batch of database queries? It sounds like many of the form
elements, if not all of them, would be coming from the same rather
complex database query. If so, then I would recommend you take these
elements all together in one AJAX call, so that the database query is
only done once.
Very simple example:
Suppose your form has a customer’s name, contact information, and
order history, including the details of each order (how many of what
at what price each, total, tax, shipping, grand total), and the master
total of all orders. The name and order IDs could come from two
very simple queries done in the controller. Then you could have the
form, upon loading in the browser, fire off AJAX queries, one for each
order to get the details. (Better yet, do it not on load, but on user
request, if it’s something they don’t necessarily always need.) Upon
receiving each of these you could fill in the sections, and add to the
master total. Thus the order detail retrieval would be parallelized.
This probably wouldn’t really be worth it, but if your situation is
much hairier, something analogous may be applicable.
Alternately, think about breaking up your form.
-Dave
–
LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern
languages.
Where: Northern Virginia, Washington DC (near Orange Line), and remote
work.
See: davearonson.com (main) * codosaur.us (code) * dare2xl.com
(excellence).
Specialization is for insects. (Heinlein) - Have Pun, Will Babble!
(Aronson)
Thanks for the ideas …
some of my records are very flexible with joins,such that I can’t be
sure how may fields their are in the form or what field types there
are.
I figured I could guess that I wouldn’t have more than 100 fields and
I could generally have an idea how many fields there was so that may
not be a big deal, however when I initially do the
remote_form_for(@rec) do my_form
my_form is a form builder object that I seem to doubt is something I
can have available on an ajax call into a partial to generate a field
after the initial page load. Since when the page first loads, I don’t
know for which fields I would need a text_area versus a text_field,
those details are ideally figured out when I would load the field via
ajax. I could try to figure that out ahead of time, but if I have
older records where the format layout has changed, those would error
out.
Possibly the set up work to get this scheme to work is a bit more
than I anticipated, though it may still be worth doing …