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
-~----------~----~----~----~------~----~------~--~---
