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.
On Wednesday, January 27, 2010 5:17:14 PM UTC-8, Jonathan Lundell wrote
Any update on this? I am using auth.login and auth.register forms on a
single page and it is resulting in duplicate ids for email and
password rows.
Original thread -
http://groups.google.com/group/web2py/browse_thread/thread/e43c1203d8749630?tvc=2
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.
>
> it should be
>
> form = id = formname class=formname:
> input:
> class
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
On Wed, Jan 27, 2010
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 lo
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, Jerem
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
I just want to clarify, that based on what I have seen, you always get
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")
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
On Wed, Jan 27, 2010 at 4:27 PM, Wes James wrote:
> Why not:
>
>
Why not:
form1=SQLFORM(..., _id="what_you_want")
-wes
On Wed, Jan 27, 2010 at 7:31 AM, mdipierro 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
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
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 b
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?
On Jan 27, 1:36 pm, Jeremy Dillworth w
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.getElementByI
while im working on getting a patch together.
did you decide on how we want to handle markdown/__init__.py ?
-Thadeus
On Wed, Jan 27, 2010 at 10:00 AM, mdipierro wrote:
> No objection. send me a patch.
>
> On Jan 27, 9:45 am, Thadeus Burgess wrote:
> > On this same topic when you define an
No objection. send me a patch.
On Jan 27, 9:45 am, Thadeus Burgess 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
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
On Wed, Jan 27, 2010 at 8:31 AM, mdipierro 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 firs
18 matches
Mail list logo
