On 1/23/07, RobG <[EMAIL PROTECTED]> wrote:
> The findFirstElement method is unreliable because it is dependent on
> the results of form.getElements(), which, as pointed out in another
> thread, does not return results in the order they are coded in the
> document
32 return $A($(form).getElementsByTagName('*')).inject([],
33 function(elements, child) {
34 if (Form.Element.Serializers[child.tagName.toLowerCase()])
35 elements.push(Element.extend(child));
36 return elements;
37 }
That looks like it returns them in order.
> One solution is to use the form's elements collection, but since that
> is unreliable in IE with dynamic forms,
It is? Interesting. Do you have a reference for this?
> that you will also check
> if the elements are visible by looking at their (possibly inherited)
> CSS visibility and display property values,
I don't know, that looks like overkill. How far should that go? As a
real-live case, a container with a label and the input whould be made
hidden, not the input alone, so you would have to check for this as
well.
> and finally ignoring those that are readonly.
There is a "!element.disabled" condition present.
> And should elements that can't be successful (e.g. those with no name
> attribute) be ignored?
Sometimes you want this, sometimes you don't.
> All that seems an amazing amount of work, and will likely still not
> identify the "right" element in some cases.
I believe, it does not have to work in all imaginable cases. 80/20 rule.
> The element in the page
> that should get focus (if it needs to be set programatically) must be
> known at the time the page is generated or updated.
I guess in most cases you know it and the simple solutions will work.
But you also have real world cases like mine. I have a object
hierarchy with a showForm() method in the root class that calls the
_getForm() method implemented by each class. Then, in showForm(), I
insert the returned structure into the DOM, focus the first form
control etc.
Of cause, I could change this so I know the ID of the first element,
but I like the current separation of duties.
Speaking of real world usage: now that I think about it, when would
tab-index be used?
- As the original poster requests, to focus a button at the top of the
form. ("creative use" of z-index instead of a introducing a "include
submits" option to focusFirstElement() )
- To focus a submit button at the bottom of a form that got filled out
with reasonable defaults. Think a delivery address pre-filled with
data from a previous transaction. The user has to just press return to
submit.
The tab-index would basically be used as a override for cases where
focusFirstElement() does not do the right thing.
I think it is not a bad idea. Adds flexibility.
Bye,
Martin
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
