Excellent Jared! I wanted to use the CF9 ORM but the project I'm fooling with is CF8 so I went from my cfObjective() memory of Mark's preso. Good info though.
Thanks, I'll take another stab at this project later in the week when I jump back on this gig. That is to say...look for more questions l8r. :-D --- John C. Bland II http://www.johncblandii.com http://www.johnandseason.com http://www.twitter.com/johncblandii --- Suggested sites: http://www.lifthimhigh.com - "Christian Products for Those Bold Enough to Wear Them" http://www.sportsmatchmaker.com - "What are you doing today?" On Wed, Oct 7, 2009 at 10:42 AM, Jared Rypka-Hauer <[email protected]>wrote: > > > On Oct 6, 2009, at 5:28 PM 10/6/09, John C. Bland II wrote: > > > > > So I've decided to bite the bullet and try out MG. This is my very > > first attempt at it and a few things have come up. > > > > 1) Using MG, ColdSpring, and Transfer > > There are two or three places where a datasource is set. This is > > pretty counter-intuitive (change N places to tweak the datasource > > name). Did I do something incorrect or is this simply going to happen? > > If you're using Transfer or Reactor, the only place that the DSN > really matters is in their config files. > > > 2) Transfer vs Reactor > > I know...this is a subjective question but I noticed the docs made > > mention to Reactor for scaffolding. More-so curious as it applies to > > MG here and not so interested in a "mine is bigger" convo. > > Transfer is objectively more performant, and has a ton of features > that Reactor doesn't, like it's own pseudo-language "TQL" (Transfer > Query Language), which is like a shorthand SQL. It also has a busier > mailing list... subjectively speaking, it looks like Transfer is a > more active community. However since CF9 announced ORM, Mark Mandel > (Transfer's author) has basically pronounced Transfer, if not dead > then comatose. TransferObjects become your business objects, but you > can extend them to implement your own business behaviors within the > object model. Transfer also has a robust caching mechanism (which is > actually about to be rewritten). > > Reactor is still an active project, managed by Mark Drew, previously > of the CFEclipse project. Originally written by Doug Hughes of > Alagad.com, it's dedicated to the Active Record approach, somewhat > less performant than Transfer, and has no caching mechanism > whatsoever. It does provide an extensible object model, but the > objects tend to be "heavier" than those of Transfer. The primary > attraction of Reactor is the AR pattern it supports and it's somewhat > simpler API. > > > 3) Templates > > Page 1-3 are public but 4-8 are private so they have different nav > > items. What is the best practice here? Do templates get the same > > business "data" passed into the event as the page? > > Every view template gets a handle on the Event object, so all data in > the event is available to all view templates. If you have a broadcast > that fetches nav content based on their login status and puts it in > the event, you can then use that in any <include /> touched by the > request. > > > 4) Pages > > The pages folder could get hairy fast if you have a lot of cfm's. Is > > it common to make pages/{subfolder name}/{page}.cfm to separate cfm's? > > Yes. I love the easy questions. > > > 5) File locations > > Is it common to put all of the MG stuff out of the root (where > > possible of course) and only have css/scripts in the root? If so, to > > what extent? Could the root be completely empty minus public files or > > is that bad practice? > > Yes. It's not bad practice at all... in fact it's very wise and fairly > common. You can use application-specific mappings and the viewmappings > config setting in the MG config file to tell the application where to > find the view files. All that should be in the webroot is > Application.cfc, index.cfm and your static files (images, css, PDFs, > yadda yadda). > > > As you can see from the questioning I'm trying to find the best > > practices. It is a definite switch in my mind to make the MG jump but > > I'm trying to stick with it. I figured this group could help alleviate > > my pains. :-) > > Indeed. We rawk. You rawk. Let's hug the internet. ;) > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
