[FE-discuss] Make htmlfill only apply to certain named forms

[Adam Batkin]

Hi,

I have a use case where it would be good if htmlfill could operate only
on a particular named form (<form name="foo">) and leave any other forms
alone.

For example, if there were two forms on a page, one for logging in (with
a username field) and one for creating a new user (also with a username
field), the filling-in would only touch the one specified.

Attached is a proposed patch that adds this ability. My initial testing
has found that it works pretty well.

It adds an optional argument to htmlfill.render(): form_name

If a form_name is not passed, htmlfill should act exactly the same as
before. If a form_name IS passed however, htmlfill will only ever touch
the named form (plus any unnamed forms, though I'm not sure if this is a
good idea).

Thoughts? Comments? Suggestions?

Thanks,

-Adam Batkin

[A Monkey]

Hi Adam,

I have a use case where it would be good if htmlfill could operate only on a
particular named form (<form name="foo">) and leave any other forms alone.
For example, if there were two forms on a page, one for logging in (with a
username field) and one for creating a new user (also with a username
field), the filling-in would only touch the one specified.

This use case is not uncommon, and the usual advice for handling it is
"use unique field names" (as I'm sure you've heard :). That's not so
great, I don't think. I'd be happy to have something like this around.

Attached is a proposed patch that adds this ability. My initial testing has
found that it works pretty well.

Can you add some tests for the change into your patch? htmlfill.render
is a pretty busy place and could use the testing attention.

It adds an optional argument to htmlfill.render(): form_name
If a form_name is not passed, htmlfill should act exactly the same as
before. If a form_name IS passed however, htmlfill will only ever touch the
named form (plus any unnamed forms, though I'm not sure if this is ahttps://mail.google.com/mail/?shva=1#label/formencode/1268619c75a51425 good
idea).

I think your instincts are on target with regard to unnamed forms.
Probably it's best to ignore them if a named form has been specified
explicitly.

Adding another optional parameter is the standard mechanism for adding
configurable behaviour to htmlfill.render, but that parameter list is
getting awfully long. Does anyone have any ideas about breaking
rendering up a little bit?

Thanks,
Matthew

[Adam Batkin]

Post by A Monkey

Attached is a proposed patch that adds this ability. My initial testing has
found that it works pretty well.

Can you add some tests for the change into your patch? htmlfill.render
is a pretty busy place and could use the testing attention.

Agreed.

Post by A Monkey

It adds an optional argument to htmlfill.render(): form_name
If a form_name is not passed, htmlfill should act exactly the same as
before. If a form_name IS passed however, htmlfill will only ever touch the
named form (plus any unnamed forms, though I'm not sure if this is a
idea).

I think your instincts are on target with regard to unnamed forms.
Probably it's best to ignore them if a named form has been specified
explicitly.

Anyone else agree with this statement? I do too, but I wanted to leave
the default behaviours as much as possible.

Or it could be another option. But no.

Post by A Monkey
Adding another optional parameter is the standard mechanism for adding
configurable behaviour to htmlfill.render, but that parameter list is
getting awfully long. Does anyone have any ideas about breaking
rendering up a little bit?

I suppose there is an advantage of named parameters though: If you like
the defaults, you don't need to pass any. They sure beat positional
parameters.

Actually, I was thinking of adding one additional [mutually exclusive]
parameter: form_id. That way it could identify the form by either the
name attribute or the id attribute. But it would otherwise work
identically to the form_name attribute.

So, is this something that is interesting to the wider community? In
particular, is this something that has the potential to be merged in?

Thanks,

-Adam Batkin

[Ian Wilson]

This idea seems okay but like its going down the wrong path. If
someone has two forms on a page with conflicting keys will they just
run htmlfill twice, once for each form? What about three forms? Then
we get the problem of removing or leaving the defaults in the html
already, etc. If htmlfill handles multiple forms at once will
defaults then need to be partitioned by form id/name?

Seems like all this could be solved if htmlfill.render received only
one form via a templating function within whatever templating language
you are using. This would be more explicit and might perform
better(Although I don't know much about performance). If you had two
forms you could just pass them to two seperate calls of
htmlfill.render. I probably am missing something very obvious but
what blocks/deters people from doing this?

Post by Adam Batkin

Post by A Monkey

Attached is a proposed patch that adds this ability. My initial testing has
found that it works pretty well.

Can you add some tests for the change into your patch? htmlfill.render
is a pretty busy place and could use the testing attention.

Agreed.

Post by A Monkey

It adds an optional argument to htmlfill.render(): form_name
If a form_name is not passed, htmlfill should act exactly the same as
before. If a form_name IS passed however, htmlfill will only ever touch the
named form (plus any unnamed forms, though I'm not sure if this is a
idea).

I think your instincts are on target with regard to unnamed forms.
Probably it's best to ignore them if a named form has been specified
explicitly.

Anyone else agree with this statement? I do too, but I wanted to leave
the default behaviours as much as possible.
Or it could be another option. But no.

Post by A Monkey
Adding another optional parameter is the standard mechanism for adding
configurable behaviour to htmlfill.render, but that parameter list is
getting awfully long. Does anyone have any ideas about breaking
rendering up a little bit?

I suppose there is an advantage of named parameters though: If you like
the defaults, you don't need to pass any. They sure beat positional
parameters.
Actually, I was thinking of adding one additional [mutually exclusive]
parameter: form_id. That way it could identify the form by either the
name attribute or the id attribute. But it would otherwise work
identically to the form_name attribute.
So, is this something that is interesting to the wider community? In
particular, is this something that has the potential to be merged in?
Thanks,
-Adam Batkin
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
FormEncode-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/formencode-discuss

[Adam Batkin]

Post by Ian Wilson
This idea seems okay but like its going down the wrong path. If
someone has two forms on a page with conflicting keys will they just
run htmlfill twice, once for each form? What about three forms? Then
we get the problem of removing or leaving the defaults in the html
already, etc. If htmlfill handles multiple forms at once will
defaults then need to be partitioned by form id/name?

Yes, under my proposed solution, you could run htmlfill multiple times,
and if each form has a name (and a form_name is passed to render()) then
each pass would modify the defaults of a different form, leaving the
others intact. So you would partition your defaults (and calls to
render() by form name.

Actually, my patch will need some cleaning up to do exactly that, as
currently it deals with the named form properly, but for any other forms
on the page, it strips <form:error> and <form:iferror> tags (unless the
<form:iferror name="not something">). I suppose an extra option may be
warranted to have it leave those alone.

Post by Ian Wilson
Seems like all this could be solved if htmlfill.render received only
one form via a templating function within whatever templating language
you are using. This would be more explicit and might perform
better(Although I don't know much about performance). If you had two
forms you could just pass them to two seperate calls of
htmlfill.render. I probably am missing something very obvious but
what blocks/deters people from doing this?

That sounds like it would definitely work, and without any modifications
to htmlfill. My proposed change also wouldn't affect the ability to do
that. But dealing with multiple forms that way requires that you
structure your templates in a very specific way. And also some web
frameworks don't make that process completely natural.

The other possibility would be to optionally pass a dict to defaults,
errors and add_attributes, where each key would be a form name, and the
value would be the defaults, errors and add_attributes for forms of that
name. Then a single pass with render() could take care of all forms.

Thanks,

-Adam Batkin