On Mar 13, 11:19 am, David Dashifen Kees <[EMAIL PROTECTED]>
wrote:
[...]
> As for using class for styles, id for information, that would be great
> except that, as far as I'm aware, each id should only be used once per
> page. Since I need to send the id of the database record from the
> client to the sever for clicks on two different images, then I'd need
> two id's per row. Thus, I used the name field, which can be any thing
> we want it to and has no other syntactical meaning.
The name attribute is intended to be used to identify elements and
should not be used to store values that are more appropriate in the
class attribute.
"name = cdata [CI]
"This attribute names the element so that it may be referred to from
style sheets or scripts. Note. This attribute has been included for
backwards compatibility. Applications should use the id attribute to
identify elements."
<URL: http://www.w3.org/TR/html4/struct/objects.html#adef-name-IMG >
The HTML class attribute is intended for general values used in
processing:
"A class name may be shared by several element instances. The class
attribute has several roles in HTML:
"* As a style sheet selector...
"* For general purpose processing by user agents."
<URL: http://www.w3.org/TR/html4/struct/global.html#adef-class >
You can also create your own custom attributes with whatever values
you want. To access them in a cross-browser fashion you need to use
getAttribute().
> What I'm really looking for is a way to avoid all of the inline
> functions in the javascript.
Consider putting a single onclick on the table and using event.target/
srcElement to see where it came from. This works very well if you
have a table of say 100 records with edit and delete buttons for each
record - just one function does it all.
If the above is what you are doing, you can get the elements of
interest using DOM methods without IDs or names - a click on an edit
button tells you which row, you then grab the appropriate cell and
provide an edit widget, etc. Any parameters you want stored with the
element go in its class attribute or some custom attribute you access
with getAttribute.
[...]
> I could just add an
> onclick attribute to the image and call a defined function which would
> execute the behavior that I desire.
Often whatever is simplest is best, but code bloat can be a real
problem with lots of identical inline functions.
> I guess, perhaps, what I'm looking for is a solid reason for unobtrusive
> javascript. So far, no one's been able to show me that it's a valuable
> technique. 'Course, I said the same thing about using CSS positioning
> for layouts and, by now, I've changed that tune. I suspect that, in
> time, I'll be convinced, but I don't think I'm there yet.
Like object oriented programming (or any programming technique), it is
not an end in itself. It's only useful if it provides benefits like a
significant reduction in the amount of code sent to the client or in
server-side programming (e.g. allocating a class attribute that causes
stuff to happen at the client rather than adding in-line code for
events).
--
Rob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
