SQLFORM generating duplicate ids in HTML

[Jeremy Dillworth]

I'm building an app where I am likely to want multiple SQLFORMs on the
same view.

Reading the manual I can see how this works using the formname
argument on the SQLFORM.accepts method.

I'm a little concerned about the HTML side of things, though. I've
noticed that the HTML generated by default contains lots ids that will
be duplicates if you have multiple forms (e.g. <tr
id="submit_record__row">).

I'll probably want to write custom forms in my own HTML in the long-
run anyway, but it looks like a lot of these ids could be CSS classes
and maybe save me some trouble in cases where the SQLFORM default HTML
is otherwise 'good enough' (in fact I've been having some fun and have
a short function using xml.dom.minidom.parseString to move the ids to
the class attribute and it seems to work ok).

Is there any reason why the ids are needed (other than CSS perhaps)?

If not, any chance of a future version of web2py using these as
classnames?

Thanks in advance and thanks for a cool web framework,

Jeremy

[mdipierro]

The ids are only used for CSS. you can do

form1=SQLFORM(...,_class='form1')
form1.accepts(request.post_vars,formname=None)
form2=SQLFORM(...,_class='form2')
form2.accepts(request.post_vars,formname=None)
return dict(form1=form1,form2=form2)

and you can use the class to refer to the id of the first or the
second in CSS. There should be no ambiguity.

Massimo

[Thadeus Burgess]

On this same topic when you define an SQLFORM.factory() it appends 'no_table' as the name.

Would it be difficult to add a way to pass a tablename to factory, so that my CSS will stay logical when I use SQLFORM or SQLFORM.factory?

-Thadeus

--
You received this message because you are subscribed to the Google Groups "web2py-users" group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to web2py+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/web2py?hl=en.

[mdipierro]

No objection. send me a patch.

On Jan 27, 9:45 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> On this same topic when you define an SQLFORM.factory() it appends
> 'no_table' as the name.
>
> Would it be difficult to add a way to pass a tablename to factory, so that
> my CSS will stay logical when I use SQLFORM or SQLFORM.factory?
>
> -Thadeus
>

> > web2py+un...@googlegroups.com<web2py%2Bunsu...@googlegroups.com>

[Thadeus Burgess]

while im working on getting a patch together.

did you decide on how we want to handle markdown/__init__.py ?

-Thadeus

To unsubscribe from this group, send email to web2py+un...@googlegroups.com.

[Jeremy Dillworth]

Thanks. But I wasn't too concerned about ambiguity in the CSS. I was
more concerned about there being duplicate IDs in the DOM. The w3c
HTML validator flags this kind of thing as a problem. As far as I know
it doesn't create a problem in any current browser (other than making
document.getElementById useless), but since these IDs are only used
for CSS, wouldn't it be safer to move these labels into the class
attributes and modify the default stylesheets as needed?

Thanks

Jeremy

[mdipierro]

I agree it is a bug that ids may not be unique. Yet fixing this will
break backward compatibility.
Perhaps we can add the same strings to the class attribute without
breaking backward compatibility but we should not remove them from id.
What do people think?

[Thadeus Burgess]

Bugs must be squashed!

You said so yourself a bug is not to be backwards compatible.

This isn't really a bug but a design oversight, since it was
figured two forms with the same field would never reside on the same
page.

I too have use for multiple same named fields, but since it doesn't
break browsers and the app is internal I have not bothered with w3c
validation.

Then again, I have lots of CSS that is based around the ID field, so
for me it requires making lots of little changes, so I am not
supporting this change lightly, but being a bug and in the spirit of
making web2py force w3c validity as much as possible I support it.

-Thadeus

[Jonathan Lundell]

On Jan 27, 2010, at 11:45 AM, mdipierro wrote:

> I agree it is a bug that ids may not be unique. Yet fixing this will
> break backward compatibility.
> Perhaps we can add the same strings to the class attribute without
> breaking backward compatibility but we should not remove them from id.
> What do people think?

It's better than not doing it. But duplicate IDs is bad. If you serve an xhtml page as xhtml (rather than as html), and it has duplicate IDs, the browser will not display it. Period.

I question whether backward compatibility needs to extend to propagating bugs.

[Wes James]

Why not:

form1=SQLFORM(..., _id="what_you_want")

-wes

On Wed, Jan 27, 2010 at 7:31 AM, mdipierro <mdip...@cs.depaul.edu> wrote:
> The ids are only used for CSS. you can do
>
> form1=SQLFORM(...,_class='form1')
> form1.accepts(request.post_vars,formname=None)
> form2=SQLFORM(...,_class='form2')
> form2.accepts(request.post_vars,formname=None)
> return dict(form1=form1,form2=form2)
>
> and you can use the class to refer to the id of the first or the
> second in CSS. There should be no ambiguity.
>
> Massimo
>
>

<snip>

[Thadeus Burgess]

if it was defaulted to None we could go

if _id == None then id = tablename else id = _id

Id accept that, just set a unique id for each of my forms and nothing
will conflict and it will still keep good with old apps.

-Thadeus

[Jeremy Dillworth]

I just want to clarify, that based on what I have seen, you always get
<tr id="submit_record__row"> even if you don't have any duplicate
fields. So it's not something you can avoid. Once you have multiple
forms you have duplicate IDs.

There are also multiple IDs in the form's HTML. So rather than SQLFORM
(..._id="something") I was thinking more along the lines of SQLFORM
(... _id_prefix="form22_") and then use the prefix on the front of
IDs.

There are probably ways to make this relatively painless.

I personally think web2py should do the right thing by default, for
whatever my opinion is worth (I know everyone else here has much more
invested). So I would suggest if there were a new option to SQLFORM
then something like: SQLFORM(... _use_old_id_scheme=True)... would be
best. Then those that are in Thadeus' situation could simply add the
new option and upgrade their CSS at their leisure.

But then, these kind of switches to preserve old behavior when needed
can accumulate over time. There should probably be a deprecation note
(at least) about it.

Jeremy

[Jonathan Lundell]

On Jan 27, 2010, at 2:30 PM, Thadeus Burgess wrote:

> if it was defaulted to None we could go
>
> if _id == None then id = tablename else id = _id
>
> Id accept that, just set a unique id for each of my forms and nothing
> will conflict and it will still keep good with old apps.

And _id = False for no id at all.

It's not that it isn't useful to put all of them into the same class; it's that class is the right way to do it, rather than id.

[Alex Fanjul]

I agree with prefix IDs, at least as first aproximation, and agree with
"switches" reflexion: it's more like procedural language than object
oriented language.
But for the health of desgners I wouldn't forget about css clasess and
their heritage magic potential

alex

El 27/01/2010 23:42, Jeremy Dillworth escribi�:

--
Alejandro Fanjul Fdez.
alex....@gmail.com
www.mhproject.org

[Thadeus Burgess]

Doesn't javascript input serialization expect to look the field up by id?

it should be

form = id = formname class=formname:
input:
class = formname
id = formname_field

#formname input { ... }
#formname #formname_users_email { ... }
#formname .formname { ... }

This would give a lot more flexibility from both a CSS design and a UI
design using jquery selection.

-Thadeus

[Thadeus Burgess]

Doesn't javascript input serialization expect to look the field up by id?

form = id = formname class=formname:

input:
class = formname
id = formname_field

#formname input { ... }
#formname #formname_users_email { ... }
#formname .formname { ... }

-Thadeus

[Jonathan Lundell]

On Jan 27, 2010, at 5:07 PM, Thadeus Burgess wrote:

> Doesn't javascript input serialization expect to look the field up by id?

There's nothing *wrong* with having an id; it just needs to be unique on the page.

[Mark Li]

Was the duplicate ID's bug ever fixed or addressed with an optional prefix field? It currently looks like I would have to manually alter all the ID's of my auth.login() form, because auth.register() form is on the same page.