[symfony-users] Re: sfDynamicFormsPlugin [was: Symfony/Doctrine/Forms with EAV model?]
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" To: symfony-users@googlegroups.com 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 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" > To: symfony-users@googlegroups.com > 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[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 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" > To: symfony-users@googlegroups.com > 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: sfDynamicFormsPlugin [was: Symfony/Doctrine/Forms with EAV model?]
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" To: symfony-users@googlegroups.com 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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[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 symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: sfDynamicFormsPlugin [was: Symfony/Doctrine/Forms with EAV model?]
Kind of got sidetracked at the weekend, but started on schemas for both Propel and Doctrine. 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). 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. - Original Message - From: "Lee Bolding" To: symfony-users@googlegroups.com Sent: Saturday, February 21, 2009 11:01:18 AM GMT +00:00 GMT Britain, Ireland, Portugal Subject: [symfony-users] sfDynamicFormsPlugin [was: Symfony/Doctrine/Forms with EAV model?] > > This whole thing of course screams for being developed as a generic > > "dynamic form plugin", even if you don't want to (or can't) make it > > public - when it's a plugin, you can test it and make sure there > are no > > dependecies and maximum reusage options in the future. I'll make it a plugin... I've just created sfDynamicFormsPlugin. I'll base it on DbFinder, so it works with both Doctrine and Propel If anybody that wants to join it, please do - i'd like to see some demo's of the different concepts that have been suggested :) I think this will be one of those plugins that nobody knew they wanted until it existed... it opens up a few possibilities, you no longer need 1 module per model for CRUD, in some apps, you may not even need ANY models anymore... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: sfDynamicFormsPlugin [was: Symfony/Doctrine/Forms with EAV model?]
Hello Lee, read my reply on the other thread. On 2/21/09, Lee Bolding wrote: > > > On 20 Feb 2009, at 18:14, Jonathan Wage wrote: > >> I would for sure use the form framework and design your own form >> classes to handle the specific scenario needed. Using the forms >> generated from your models won't be of much assistance I don't think. > > In this instance, that's not really an option - the requirement is > that we need to build dynamic forms without needing a developer. Every > new questionnaire would need (at the very least) a new form class, if > not a new model... once we'd added 50 or so, autoloading all those > classes would become a problem (not to mention deciding on a sensible > naming convention, routing, etc...) > >> On Fri, Feb 20, 2009 at 6:53 AM, Gandalf wrote: >> >> I Inherit from sform and pass an object from the class that the form >> will represent, in the configure method, I add widgets and validators >> while iterating in the object I passed. > > Sorry, I'm lost. In my implementation the form won't represent a > concrete object. It will represent an abstract 'field container' > object (although, in theory, this could be any type of data object - > its just a container), which will contain many field objects. Does it > help explaining it like that? So, the abstract class could be say... > "car" or "invoice" or "asset". Anything. > > Your code has hardcoded widgets and options in it - that's not what I > want. > >> On 2/20/09, David Herrmann wrote: >> >> > I think falling back to COMPAT_10 is one of the things I wouldn't >> even >> > consider. If you can create validator.yml files on the fly, you >> can also >> > create forms on the fly. > > As far as I understand, a form relates directly to a concrete object. > If this is the case, it's going to be difficult - if not impossible - > to use the new forms framework. > > I'm considering COMPAT_10 because it may work - the old forms system > is actually a lot more flexible :) > >> > The road to the solution must be something like this: >> > *) setup a list of possible objects and possible options for those >> > objects (yaml comes to mind here) > > By this, I assume you mean different validated field types? eg > textareaField, inputField, selectField, radioField etc? > >> > *) write a Form class based on sfForm that creates all the form >> elements >> > and validators based on the possibilities from the yml file and the >> > options from the database on the fly. > > Hmm possibly. ideally though, you only want to recreate the form > whenever it's changed, not on every request. > >> > I know that this sounds like a lot of work, but I think that most >> of it >> > is actually quite simple - and once you've got it up and running >> there >> > is maximum flexibility and options for further objects at hardly any >> > cost. Start with the absolute minimum you need (e.g. text boxes and >> > selects) and add further object definitions as necessary. > > I think once the solution has been identified it will not take much > work to get a proof of concept working. It could prove tricky to add > some advanced cases and validators though. > >> > The old validator.yml is a good base to build the option range >> upon, but >> > that's where its use should end. The current form framework is >> much too >> > powerful to ignore it. > > I have no doubt that the new forms framework is very powerful, but I > think in this instance it could be difficult to bend it to conform to > do something it was never designed to. The old forms system is a lot > less rigid - so I've got a lot more confidence that using the old > system would work. Infact, I can see Symfony 1.0 plugins that look > worth investigating - spyFormBuilderInterfacePlugin and > sfDynamicsFormBuilder > >> > This whole thing of course screams for being developed as a generic >> > "dynamic form plugin", even if you don't want to (or can't) make it >> > public - when it's a plugin, you can test it and make sure there >> are no >> > dependecies and maximum reusage options in the future. > > I'll make it a plugin... I've just created sfDynamicFormsPlugin. I'll > base it on DbFinder, so it works with both Doctrine and Propel > > If anybody that wants to join it, please do - i'd like to see some > demo's of the different concepts that have been suggested :) > > I think this will be one of those plugins that nobody knew they wanted > until it existed... it opens up a few possibilities, you no longer > need 1 module per model for CRUD, in some apps, you may not even need > ANY models anymore... > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~
