if the all points is to add " * " for required field in label, just use the
setLabels method !

You have so many way to add a star, so there in no "good" solution.

I am not sure for propel, but doctrine generates a middle class, where you
can put some stuff in. (an event listener to add custom methods).

All your points are good, I think some of them are on the roadmap, if not
just open a ticket.

ps : nothing is perfect at the first shot, it will be too easy !


2009/3/26 Nickolas Daskalou <[email protected]>

> I for one welcome our new Form overlords.
>
>
> 2009/3/27 Vojtěch Jína <[email protected]>
>
>
>> Hi all,
>> I like Nicolas's piece of code. But Marc's code is a big hack in my
>> opinion...
>>
>> Im afraid, that this form framework is not so well designed and we
>> cant make some great updates, without changing the basics...
>>
>> Class for <li>, <tr> or <div> is very useful and common, we need it.
>> And its not possible to make it, without any hacks...
>>
>> List of problems in design:
>> 1] sfWidgetFormSchema->render() calls sfWidgetFormSchemaFormatter for
>> generateLabel, generateCommonErrorLabel. Then it puts all returned
>> values together and calls sfWidgetFormSchemaFormatter->renderRow().
>> Whats the reason of this design ? I dont know, but when you renderRow,
>> you dont have acces to the widget. Thats bad. You have access to the
>> whole widgetSchema, but you dont have the name of the widget.. I hope,
>> it would be better, to call sfWidgetFormSchemaFormatter->renderRow()
>> with reference to the rendered widget. And then things like
>> generatingLabels and so on, should be done inside the renderRow()
>> method. Then we would have access to the widget and we can set class
>> for <li> and many other useful things...
>> Then we dont need extending sfWidgetFormSchema, or sfForm... All we
>> need is to set our specific sfWidgetFormSchemaFormatterXXX.
>>
>> 2] when I want to rewrite sfWidgetFormSchema like that.. There is
>> another problem... I cant use it well. No way. I can set sfForm-
>>  >setWidgetSchema(new sfWidgetFormMySchema), but then, when I call
>> sfForm->setWidgets(), it sets new sfWidgetFormSchema... And all propel
>> generated forms use setWidgets() method.
>>
>> 3] Ok, then I have to rewrite whole sfForm. No problem. But when I use
>> propel forms, I cant use my sfMyForm... Its in libs/plugins/
>> sfPropelPlugin/lib/sfPropelForm.class.php. I hope, it should be set
>> somewhere in factories or something like that. At this time, its not
>> possible, to extend sfForm without any hack.
>>
>> Finally, I hope, that the best sollution is to rewrite core files...
>> Like sfWidgetFormSchema->render(). Then everyone can use
>> sfWidgetFormSchemaFormatterMy and no problem at all.... All these
>> things will be done by this class... I hope, it would be much easier
>> to extend forms then.
>>
>> Maybe, Im totaly wrong. Its only idea.
>>
>>
>>
>
> >
>


-- 
Thomas Rabaix
http://rabaix.net

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"symfony developers" 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/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to