That is true but I didn't think MG can pull in pieces the way FB4.1 can as I'm describing. I thought I really only had 1 mapping option for both the BeanMappings and ViewMappings versus the multiple FB4.1 allows. Since FB4.1 is more like an 'uber controller' I tell it to put the actual controller & view circuits (model is all CFC so there is nothing to point to) files that live in multiple  directories outside the app root.

E.g.
CoreFiles\Contorller
CoreFiles\Controller\Contacts
CoreFiles\Controller\Contacts
CoreFiles\View
CoreFiles\View\Contacts
CoreFiles\View\Company

Since FB4.1 allows me to break the app into more refined circuits it means I can pull in 1 small circuit with a handful of files (controller or view) rather than a single viewMapping with all view files.  FB4.1 lets me condense the views and controllers into smaller code sections which lets me modify smaller chucks of files.   If MG can be broken into pieces as I'm describing please let me know how to do this in MG. I'm using MG for a much smaller app and wouldn't mind switching my other project over but I must have the flexibility for changes as described to help reduce maintenance and upgrade paths for the app. Copying all view files just to tweak one or 2 files just will not work for this app.

Also, the other bonus w/ FB4.1 allowed me to create a new mapping, I call it a helper, that the controller can use as a go between for the model and view.  Helpers do not display anything but interact b/w the view and controller. It's not a view since it doesn't display anything and hence I don't like throwing it in with other view files.  Currently I'm using this concept to stuff all display text, instructions, etc into the helper struct or add custom validation rules in addition to the models standard validation. The added mapping gave me a way to encapsulate something that changes often, yet minimize the file coping issue.  I'm still 'green' in the MG world but I couldn't find a way to do this the last time I looked.


Sean Corfield wrote:
On 1/30/06, Jason Daiger <[EMAIL PROTECTED]> wrote:
  
Speaking from experience going from FB3 to FB4 is a much easier
transition than from FB3 to MG.
    

I think that depends on your background. I found the jump from FB3 to
FB4 much bigger than many others apparently found it.

  
One pro I found w/ FB4.1 vs MG at this
time is the ability to place all circuits, including controller, model
(CFC's) & view, in a shared area.
    

Since the CFCs for MG can be placed anywhere, as can the views, this
is already true for MG as far as I can tell. The only thing that needs
to be in the webroot, for example, is the index.cfm entry point - all
other files can be in a shared area outside of webroot (this is true
for FB41, M2 and MG).
--
Sean A Corfield -- http://corfield.org/
Got frameworks?

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org


.

  

-- 
Jason Daiger
URL: www.jdaiger.com
EML: [EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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).

An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org

Reply via email to