Kudos on ORM in Railo. I really like what I'm seeing in the Railo space. Keep it up.
Thanks for the highlights on Transfer vs Reactor. Yeah, I'm digging the events and have setup a few types which I'm pretty sure I'll be able to cleanly derive the url's from within the types. I'm definitely going to setup the app to have a minimal web root. I love that in all other cases and MG seemingly makes it even cleaner. --- 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 Thu, Oct 8, 2009 at 7:18 PM, Sean Corfield <[email protected]>wrote: > > On Tue, Oct 6, 2009 at 3:28 PM, John C. Bland II <[email protected]> > wrote: > > 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? > > I'd expect to only put it in the Transfer config and then expose it > via factory-bean definitions in ColdSpring should it be needed > elsewhere in the application (do you need the datasource name anywhere > really?). > > > 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. > > MG is ORM agnostic so you can pick whichever you want and it will "just > work". > > Personally I prefer Transfer but I'm using Reactor on my current > project and it's perfectly adequate (it's gotten much more performant > since I last tried - and abandoned - it back in 2006. Mark Drew has > added some nice stuff to it recently. That said, I still prefer > Transfer's architecture and idiom. It'll be interesting to see if > folks can build an adapter for the new ORM features in CF9 (which will > also be added to Railo in the next release). > > > 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? > > I'd suggest looking at event types and derive the nav/layout from that > (with PublicEvent and PrivateEvent types). > > > 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 generally partition the views folder into sections and > subsections with the actual "pages" inside those. You can also have > completely separate trees and then use multiple viewMapping paths in > the configuration file. > > > 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? > > My web root has only: > - Application.cfc > - index.cfm > - assets/ folder (containing CSS, JS, SWF) > > I may also have a remote/ folder for remotely exposed CFC APIs. > -- > Sean A Corfield -- (904) 302-SEAN > Railo Technologies US -- http://getrailo.com/ > An Architect's View -- http://corfield.org/ > > "If you're not annoying somebody, you're not really alive." > -- Margaret Atwood > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
