Nice idea - but I'm talking about millions of rows here. Creating millions of 
XML files, or even 1 file for each form TYPE, with millions of records in it 
just isn't on.

Besides, I think manipulating those XML files, in RAM would kill any server. 
XML manipulation is just too damned heavy on resources, and not at all 
appropriate once you're talking about even hundreds of records.

Lastly, once we get onto dynamically adding custom fields to existing models... 
mixing XML and DB? er... that's bad news.

As for the name - Dynamic Form is more true, Dynamic model isn't. In Symfony, 
users expect models to relate directly to forms and modules, and this blatantly 
isn't the case with this plugin - you can't even SEE a specific model, it's 
just inferred from the context of a form, and the collection of fields it 
contains - models are created as a direct result from the defined and included 
fields. 

Call it "model" and you'd be expected to find ways to dynamically add methods, 
behaviors etc to the models too, which I'm not at all interested in doing. 

"form" is the overall driver (and the scope of the plugin) - hence the name :)

----- Original Message -----
From: "Gandalf" <[email protected]>
To: [email protected]
Sent: Monday, February 23, 2009 11:37:04 AM GMT +00:00 GMT Britain, Ireland, 
Portugal
Subject: [symfony-users] Re: sfDynamicFormsPlugin [was:  Symfony/Doctrine/Forms 
with EAV model?]


Hello,

Once, long time ago, I made a framework, php4, that included this
feature, I didn't made it with an EAV model, I modified the tables
directly, using alter sql and such. that allowed me to have full
control over the schema without losing data during modifications.

Please try not to hardcode the EAV model in this plugin, try to
include the xml case I sent, not all forms need to go to a table.

Also, the plugins name shouldnt be dynamic form, model will be more appropriate.

Best,

Pablo


On 2/23/09, Lee Bolding <[email protected]> wrote:
>
> Just apply to join the plugin on the plugin page, and I'll accept you. I
> think that then gives you SVN commit access to the repo.
>
> I guess the typical use case for adding custom fields would be where the
> specification or requirements change after the project has been released -
> more attributes for a model are required, but it's not searchable data, so
> doesn't warrant changing the model and an entirely new code release. I've
> been in that situation before - where 1 new field is needed, and we've
> needed to change the schema, rebuild the model etc - not a big hassle, but
> it needs a whole release cycle just for 1 additional piece of information
> which we just "need recorded". Also, there could be a case where you have a
> base object - say "vehicle" and you'd dynamically change it for other
> psuedo-concrete classes by adding custom fields - create "mpv" by adding
> attributes for 4wd, locking diff, etc. To be honest, I haven't really
> thought about the use cases - it was just a "wouldn't it be cool if..."
> idea, based on the fact that I could have used that functionality in the
> past.
>
> Still, as I said - that's something to consider in the future, once the
> initial functionality for fully dynamic forms/models has been created :)
>
> ----- Original Message -----
> From: "David Herrmann" <[email protected]>
> To: [email protected]
> Sent: Monday, February 23, 2009 10:19:52 AM GMT +00:00 GMT Britain, Ireland,
> Portugal
> Subject: [symfony-users] Re: sfDynamicFormsPlugin [was:
> Symfony/Doctrine/Forms with EAV model?]
>
>
> Lee Bolding schrieb:
>> Hope to have those finished tomorrow night, for check in to SVN.
>> Unfortunately, at the moment, I can only work on this plugin during
>> my spare time (but that's also the reason I can make it a public
>> plugin).
>
> I'd love to take a look at it, too. Perhaps we can join our (spare time)
> efforts for that one.
>
>> Something else that occurred to me is that a logical extension of
>> this would be the ability to dynamically add custom fields into
>> existing models/forms. Not sure exactly how difficult that would be,
>> but I think that's the direction I'll head in once I've got it
>> working for creating fully dynamic forms from scratch.
>
> Sounds interesting, although I miss a typical use case at the moment
> (perhaps you can give me one). I think I'll have to breed a little over
> this...
>
> David
>
>
>
> >
>



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

Reply via email to