Do you have a sample application I can install to see this in action?
DW On Fri, Jan 22, 2010 at 9:34 AM, Bob Silverberg <[email protected]>wrote: > Hey folks, > > I've committed the new proof of concept code for scaffolding to the > newScaffolding branch. Some of us have been discussing the design on > Google Wave, but I thought I'd share a summary of what's been done > here, in case anyone else is interested. As always, if you want to > follow and/or contribute to the discussion please let me know and I'll > add you to the Wave. If you haven't been following some of this will > make very little sense to you. If you don't care about what we're > looking at in terms of a new approach to customizable scaffolding, > stop reading now. ;-) > > Here's a summary of the changes (copied from the Google Wave): > > ormAdapters: > - getOrmName() method now exists in ormAdapters. The name is set via > the CS config for the adapters. > - ormName is not available to objectMetadata inside the scaffolding beans. > - UDFs for getSourceValue() and getSelectedList() have been added, > calls to which are currently being written to the GTs as input to > custom tag attributes. > > Scaffolding beans: > - I've created two new scaffolding beans to replace Edit.cfc > - Each of them make use of the following custom tags: > - <cf_scaffold_property> is used to generate form controls for > individual properties > - <cf_scaffold_manytoone> is used to generate form controls for > many-to-one relationships (a select box) > - <cf_scaffold_manytomany> is used to generate form controls for > one-to-many and many-to-many relationships (a set of check boxes). > Note that I think that this really only makes sense for a > many-to-many, not a one-to-many, but the current behaviour does it for > both. > - Edit_New.cfc implements the new custom tag scheme duplicating the > same output as the current Edit.cfc > - Edit_cfU.cfc implements the new custom tag scheme approximating the > same output as the current Edit.cfc, but utilizing the cfUniform > custom tag library. > > Custom tags: > - There are two versions of each of the new custom tags. > - For example, there is a scaffold_property.cfm and a > scaffold_property_mg.cfm. > - scaffold_property_mg.cfm generates the code that resembles the > current scaffolding ouput. > - scaffold_property.cfm generates the code that uses cfUniform. > - These exist with different names just for the purposes of testing. > The idea I had was that the scaffolding bean will always contain a > call to cf_scaffold_property, and a developer will customize the > behavior by providing a new version of the cf_scaffold_property custom > tag. So in many cases a user will be able to change the ultimate > scaffolding output simply by providing a new custom tag, without > having to edit the bean at all. > - Note that the only reason that there are two new edit beans: > Edit_New.cfc and Edit_cfU.cfc is to address the issue that cfU > requires all of its tags to be nested between an opening and closing > tag. I couldn't find a way to embed the call to cfU's opening and > closing tags inside another custom tag, so I had to write them to the > GT. If anyone has an idea on how to get that working I'd love to hear > it. > - In order for the GT to use the appropriate custom tag we'd probably > have to use import and namespaces, as Dennis discusses above. That > would mean that the bean would have to generate a custom tag call > using the correct namespace, so I guess that would have to be a > configuration option somewhere. > > Overall I think it's working quite well, and I'm happy with the > results. Please note that the proof of concept is just designed to > test out this idea of implementing scaffolding - the actual output may > not be working 100% properly, but the generation and rendering of the > displays is working. > > What's next? > - A review of the code by members of the team to determine whether MG > is interested in adopting this approach, or something similar would be > appreciated. > - Some of the code in the AbstractORMAdapter could be refactored out > into each individual adapter. > - Implement the ormHelper idea so that the GTs are calling methods in > an ormHelper, rather than event.getModelGlue().getOrmAdapter() as is > being done now. > - Implement the custom tag integration idea involving writing out > import statements based on configuration settings. Deal with the > namespace issue at the same time. > - Move the cftemplate code out of the scaffolding beans. > - Test, test, test. New beans will need to be tested against all of the > orms. > > Cheers, > Bob > > -- > Bob Silverberg > www.silverwareconsulting.com > > Hands-on ColdFusion ORM Training @ cf.Objective() 2010 > www.ColdFusionOrmTraining.com > > -- > Model-Glue Sites: > Home Page: http://www.model-glue.com > Documentation: http://docs.model-glue.com > Bug Tracker: http://bugs.model-glue.com > Blog: http://www.model-glue.com/blog > > You received this message because you are subscribed to the Google > Groups "model-glue" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<model-glue%[email protected]> > For more options, visit this group at > http://groups.google.com/group/model-glue?hl=en -- “Come to the edge, he said. They said: We are afraid. Come to the edge, he said. They came. He pushed them and they flew.” Guillaume Apollinaire quotes -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en
