Hi Michele,
It seems to work fine for me :) Haven't tried the is_required
property though...
However, shouldn't display_field_for be available at the
FormFieldsContainer templates? That is simply adding "d
["display_field_for"] = self.display_field_for " at the end of
FormFieldsContainer.update_data.
This is so a template for a form/fieldset can look like:
<fieldset>
${display_field_for("name", value_for("name"), **options_for("name"))}
${display_field_for("age", value_for("age"), **options_for("age"))}
</fieldset>
Maybe this could even go to CompoundWidget, so it could even simplify
the new AutoCompleteField and similar...
Another idea to simplify the API even further:
Maybe display_field_for could even try to partially apply (curry) the
field's parameters to it's display... this could make:
${display_field_for("name")}
possible, without requiring widget developers to write the boiler-
plate needed to pass the field's value & options. What do you think?
I've uploaded a patch that implement's this though it's minimally
tested (but appears to work). Maybe you can use it as a source of
inspiration... I've just modified display_field_for, added an util
function (pre_bind_params) which could go to util.py (though I think
there's something already there which does the same, could use
that..), and update_data. All at FormFieldsContainer. Take a look at
the Forms' and Fieldset's template so see the change.
Great work BTW! I can't wait to do a big template cleanup for my
projects widget templates taking advantage of this :)
Many thanks!
Alberto
On 14/03/2006, at 11:29, Michele Cella wrote:
>
> I posted an update version here, I think it should work:
>
> http://trac.turbogears.org/turbogears/attachment/ticket/613/
> newversion.patch
>
> any opinion?
>
> Alberto, you said you needed display_field_for inside the compound
> widget template, can you give it a try if you have a moment?
>
> Thanks.
>
> Ciao
> Michele
>
>
> Michele Cella wrote:
>> Just one note, now I'm going offline, anyway I just noticed that I
>> still need to fix some small things related to fully qualified forms.
>>
>> Will look into that today anyway...
>>
>> Ciao
>> Michele
>>
>> Michele Cella wrote:
>>> Hi guys,
>>>
>>> I've implemented support for display_field_for and render_field_for
>>> (and deprecated field_for) and done a really small cleanup (as
>>> announced) on the way we treat a form in our path (for the
>>> full_qualified_form attribute) to support these things in a sane way
>>> and being able to reuse value_for, options_for and error_for in the
>>> same way you can use display_field_for/render_field_for.
>>>
>>> Finally, thanks to Alberto great work on the Schema generation, I've
>>> implemented a long standing feature, a FormField while being
>>> displayed
>>> can now check if it's required (by simulating a validation) and
>>> in that
>>> case add "requiredfield" to its css classes.
>>>
>>> The patch is attached here (should I open a new ticket?):
>>>
>>> http://trac.turbogears.org/turbogears/attachment/ticket/613/
>>> cleanup-display-field-for-and-required-fields.patch
>>>
>>> I think is ready to be committed, but I would like to hear your
>>> feedback and then prepare some tests before committing it.
>>>
>>> Ciao
>>> Michele
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---
