Re: Make htmlfill only apply to certain named forms

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?


On Mon, Feb 1, 2010 at 10:42 AM, Adam Batkin <[email protected]> wrote:
>>> 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.
>
>>> 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.
>
>> 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
> FormEncode-discuss-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/formencode-discuss
>

------------------------------------------------------------------------------
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