Forum OpenACS Development: Re: Ad_form DOM error

Collapse
3: Re: Ad_form DOM error (response to 1)
Posted by Gustaf Neumann on 01/15/08 09:44 AM
Eduardo,

DOM is HTML agnostic and does not require IDs for anything. I don't understand, why you are talking about a "DOM error". Sure, if someone processes HTML from javascript, it is quite convenient to use IDs, but it is still quite easy to access HTML forms, since the FORMs have names. Historically, FORMs were identified by the name attribute rather than IDs, but HTML 4.01 still uses name for backward compatibility. Form JavaScript FORMs can be accessed via document.forms[form_name].

The new OpenACS versions (5.3.*) have many quality improvements for the generated HTML, mostly from the Zen project. The labels and input fields are linked via IDs (most likely addressing your PS).

The code snippet that you included does not intend to provide an HTML ID, but is used for the form handling internally in OpenACS. It is certainly possible to change from FORM names to IDs and use current name as HTML ID (not all names are valid IDs, most likely no big issue), but this is more of a feature request than a bug fix.

Collapse
4: Re: Ad_form DOM error (response to 3)
Posted by Eduardo Santos on 01/23/08 01:57 PM
Hi Gustaf,

Thank you very much for all your explanation and sorry for the late answer. I'm still trying to understand all this W3C stuff and my last DOM studies where more related to the use of JavaScript, as everybody is using it and we have to put it too when the customer ask for.

Is seems to me that DOM is more like a model from wich you can access some document pieces, it doesn't matter the platform you use. The problem in ad_form is when you try to use somebody else JavaSript libraries, wich is what we do in Ajax Helper. The prototype framework has a lot of functions wich use the document.GetElementById method to access some content from the page, such as the Form.Serialize(). As our API doesn't generate the form id it's impossible to get the form with this method and the function doesn't work. There are some other functions that break on that too.

Yes, there's a very simple workaround using the -html switch in the form generation, but I don't think it's the best way. We allways try to be inside the W3C recomendation all the time, and in that specific case it seems to me that we are not. Almost all the forms in the Internet have the id set, wich also seems to me a W3C recomendation, so I think we should do it too.

I don't know if I'm putting this in the right place or in the right way, but I guess this is something we should think about. Something like an improvement to be made.

Collapse
5: Re: Ad_form DOM error (response to 4)
Posted by Gustaf Neumann on 01/24/08 01:34 PM
Dear Eduardo,

i have committed a patch to the oacs-head and oacs-5-4 branches that add adds IDs to HTML forms built with the form builder. The IDS have the identical value as the "name" of the FORM. In other words, FORMs have now an ID and a name, both with the same value. Therefore, the exiting javascript parts of openacs expecting a "name" should continue to work, and new code, requiring IDs for FORMs should work as well.

In general, the HTML syntax specification for IDs and names is the same, the only potential conflict happens when the HTML document has already an ID for a different element, which is identical to the FORM ID. For the existing apps i have checked, this does not appear to be a problem. In general, we should define in openacs naming convention for all IDs and names to avoid clashes. This is however a larger issue since it involves CSS as well, when we start to rename IDs, on which some applications might rely. So, keep this in mind, when you use the FORM IDs (or other IDs).

Collapse
6: Re: Ad_form DOM error (response to 5)
Posted by Eduardo Santos on 01/24/08 02:25 PM
Hi Gustaf,

You were quite fast on that. I didn't mean to give you some extra work, but as I told you it seemed the right thing to me. You are right when you talk about more than one ID in the same page, but I don't think it should happen. It's something like a "good practice" not doing that, especially when you are using JavaScript in the page, even though we know somebody will do it.

If you need any help in this kind of work, let me know what I can do to help. I don't have commit rights but maybe I can submit a patch for these boring fixes.

Thank you for the good work.