Well, that sounds like an interesting implementation. One of the Rails rants is to not put config files as such into XML. I think they have some points but the point is overstated IMO. Here the Rails thing with Active Records goes against the grain of many deep thinkers. Yet it works in a interesting number of situations. Now they are turning around and beating the "don't do this" drum. If it works to the level you need then it's a good thing. I say we look at it and build CFoR based on CF since CF and Ruby are different creatures.
That is why I started this thread to start with. I am not trying to duplicate Rails point for point. What makes RoR so cool is how much it does and that it is all packaged together. One of the principles of rails is release fast and release often. If we follow that principle we can build things one at a time, and keep adding on. That seems to be the way to go... and I would like to start with the Active Record concept. (Keeping the other areas in mind of course... but start getting things out there. After all RoR isn't even to 1.0 yet the last I knew.) John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Mandel Sent: Sunday, September 25, 2005 8:32 PM To: [email protected] Subject: Re: [CFCDev] Ruby on Rails for CF Joe - Sounds like you an me have been having some similar ideas ;o) I've been working on some code as well, called 'Transfer' for a while now - It also runs off a XML config file where you can define packages, objects and a variety of object composition types (one to one, many to one, many to many). Probably the difference with mine is that the code it generates is only a listing of the UDFs that are relevent for the Business Object, and when the BO is requested they are inserted on a generic 'transferObject' at runtime. The information from the XML config file is then utilised to create the required SQL at runtime for your CRUD operations. So a basic retrieve and update ends up looking like: myObject = transfer.get("package.class", 27); myObject.setItem(3); transfer.update(myObject); I'm also going to be open sourcing it when this is done, I'm just in the process of fiddeling out the one to many composition model, but that is almost done, and fixing up the various todos that are scattered through my code that I haven't gone back and fixed up yet.It'll be release shortly after I release the v2 of my website, which strangely enough is running this code! ;o) I would be very interested to see your code at some point Joe - and see how you tackled certain things. Just thought I'd share my little project, as it seemed relevent to the conversation. Mark On 9/24/05, Joe Rinehart <[EMAIL PROTECTED]> wrote: > Sorry Trevor, it's not one big XSD file. Right now, I think there's > 21 different code generators plugged in, creating everything from > beans to SQL scripts. I should have something worth showing before > too long. > > -Joe > > On 9/23/05, Trevor Orr <[EMAIL PROTECTED]> wrote: > > Is there an xsd file for the XML file to generate the framework code? > > If so can we have a peek? > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Joe Rinehart > > Sent: Friday, September 23, 2005 10:17 AM > > To: [email protected] > > Subject: Re: [CFCDev] Ruby on Rails for CF > > > > Yep. Rocket's really just a CFC that reads the project XML file, reads > > its own XML config file (a ChiliBean), then passes the XML and config > > information off to any registered generators (registered in its config > > file). > > > > -Joe > > > > On 9/23/05, Tom Young <[EMAIL PROTECTED]> wrote: > > > Sounds interesting Joe. I look forward to seeing it. Is Rocket > > > itself written in CF? > > > > > > Joe Rinehart wrote: > > > > > > >Wow, this is a good-sized thread. > > > > > > > >I've been working on a bit of code called "Rocket" since I started > > > >Model-Glue, with the aim of generating basic "bootstrap" CRUD code > > > >for consumption by any CF framework (or lack thereof). I'm going to > > > >try to have an early (at least demoable) release ready for the F&F > > > >conference next week. > > > > > > > >Rocket itself focuses on a "project" XML file that describes > > entities. > > > > Entities contain properties, which can be references to other > > > >entities. > > > > > > > >Rocket itself basically reads this XML and then passes it to > > > >registered "generators" (registered via an XML file) that can do just > > > > > >about anything with it. Generators I've created focus on the > > > >entities themselves, ORM and persistence objects, an app-wide service > > > > > >layer, and the necessary Model-Glue files to create a site that > > > >consumes this service layer. It'd be a snap to create FB or > > > >M2-specific code generators and "site templates" (the base code, like > > > > > >the RoR skeleton, that a site starts with). I think this a lot along > > > > > >the lines of what Dave Ross mentioned earlier - a code generator, not > > a framework. > > > > > > > >The CFC generators in Rocket generate both a _rocket_myFile.cfc file > > > >and (if it doesn't already exist) a myFile.cfc file in the target > > > >directory. MyFile.cfc extends _rocket_myFile.cfc: you can therefore > > > > > >override logic, then re-run the code generator to do something like > > > >adding a property, and not lose what you've done. > > > > > > > >For a given entity, it'd generate the following: > > > > > > > >Entities: > > > > > > > >Entity.cfc (extending _rocket_Entity.cfc...) EntityBean.cfc > > > >(extending....) EntityTO.cfc (you get the point...) > > > > > > > >ORM/Persistence: > > > >EntityCollection.cfc (lazy-loading collection / iterator on Entity) > > > >EntityDAO.cfc EntityGateway.cfc > > > > > > > >Business Rules: > > > >EntityValidator.cfc > > > > > > > >Service layer: > > > > > > > >Regardless of entities, Rocket generates a RocketService.cfc (and > > > >_rocket_RocketService.cfc that it extends) that provides a basic set > > > >of CRUD functions for each entity, like PutEntity(), GetEntity(), > > > >ListEntity(), and ListEntityReferencedEntity() (e.g., > > > >ListBlogEntryComments() on a BlogEntry entity). > > > > > > > >Right now, it also generates a Model-Glue specific Controller.cfc and > > > > > >View files. The Model, though, doesn't give a darn as to what > > > >framework/lack thereof is using it. > > > > > > > >On a database level, it also creates (right now, just MS SQL) scripts > > > > > >to create the various tables used to persist the model. One thing I > > > >needed from it was a journaling DB system (where every table is > > > >'threaded', and no rows are actually updated) that lets you roll back > > > > > >versions of an entity, keep an audit log, etc., so the generated > > > >persistence components handle this transparently - the App itself is > > > >none the wiser to it. It just says RocketService.getWidget(widgetId) > > > > > >and gets the latest version of that widget. While this may (ok, > > > >will) increase DB size....hard drives are cheap :). > > > > > > > >If anyone's interested, I do plan to release this under an LGPL > > > >license, but I don't think I'm quite ready for full community > > > >involvement. There's still low-level stuff going on in terms of > > > >getting things up and running, but I'd be happy to set it up as a > > > >community project when it's ready. > > > > > > > >-Joe > > > > > > > > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com ICQ: 3094740 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
