Get documents about "Brand Mapping Presentation - Excel
W
Description
Brand Mapping Presentation document sample
Document Sample
Sheet1
Feature Same Different FB Pros FB Cons
XML All use XML config FB has multiple XML, Easier to manage, can Hard to see whole app
files M2/MG has one XML reuse at once
MVC Can use MVC FB allows but does not Easier to learn Easier to write
enforce, M2/MG pretty spaghetti code
much forces it
MVC Structure Model/View FB typically has Structure is more Multi-circuit approach
directories controller circuit explicit can cause duplication
directory, M2/MG has
implicit controller in
framework
CFCs Can use CFCs FB allows but does not Easier migration path None
enforce, M2/MG pretty from old school code
much forces it
Plugins All have plugin FB has more plugin Finer grained control More complex
points points, M2 over processing
distinguishes events
and views, MG has
simple request/queue
model
Access control All have private / FB has per circuit and Finer grained control None
public concepts per fuseaction as well over processing
as roles-based model,
M2/MG has per event
access only
Auth / Security None FB has roles support Some builtin If roles-based security
builtin, M2 provides a infrastructure doesn't meet your
sample filter, MG is needs, you have to
free form start from scratch
Install / Config One-stop core files, One-stop core files is More control over More parameters to
basic properties in brand new in FB41, framework behavior learn
XML file FB provides finer
control over
framework behavior,
MG has a simple
framework control
model
Modularity of None FB has circuits to Better modularity None
Application partition large
applications
Modularity of Site None M2 allows multiple sub- None No single sign-on
applications to share across multiple apps
application scope
Commonality Can explicitly invoke FB has per-circuit pre- Some builtin support More complex, more
fuseactions / /post-fuseaction for commonality options
announce events / hooks, providing
add results to framework level
handle common support for
functionality commonality
Page 1
Sheet1
Views All encourage views FB/MG lets you Simpler, less XML to If you move a view,
to contain “only include a view directly, write you have to change
HTML” (no logic) M2 requires that you every reference to it
declare all views in
XML
Handler Model All declare 'handlers' FB is a static, explicit Simpler, more intuitive You cannot 'do' a
for 'events' in XML invocation model, M2 for web developers; dynamic fuseaction,
is a dynamic, implicit Performance is good e.g., from a database,
invocation model, MG because static so certain dynamic
is somewhere in execution model can applications are hard
between be compiled to inline to write entirely within
code the framework
Data bus Can use request FB allows variables Simpler – one scope No encapsulation
scope as data bus scope as data bus; M2 (variables) can be
(but it's not always allows event object as used throughout
best practice) – MG data bus, MG enforces
uses event object event object as data
bus
Global data None FB has Simpler – one file Application data
fusebox.init.cfm, M2 contains all global data initialization needs to
uses either <property> setup be explicitly coded
tags or plugin (or
both), MG has settings
Model CFC Most CFC methods FB uses standard init() Simpler – CFCs can Construction needs to
Structure could be the same construction controlled be independent of be explicitly managed
by explicit code in framework and follow
fusebox.init.cfm or standard best practice
circuit, M2 reserves
init() and uses a
managed configure()
method to initialize
CFCs – with no
arguments – and
CFCs must extend the
framework, MG has
base controller init()
method
Page 2
Sheet1
Conditional logic None FB has some Simpler XML controller can get
conditional logic in the polluted by logic
XML grammar, M2
requires conditional
logic placed in CFCs,
MG requires controller
CFCs
Model Actions All have the concept FB allows a model An action can 'do' Risk of spaghetti code
of separating action to set multiple more in terms of since an action can set
business model outputs, M2 uses strict setting up a data arbitrary outputs
logic from call/return semantics environment for
presentation logic so each action can subsequent actions,
have only one result, queries or displays
MG allows a model to
set multiple outputs via
event object
Model Queries None FB specifically Better organization of None
separates out code
persistence operations
(by a naming
convention on files),
M2/MG draws no
distinction between
actions and queries
Page 3
Sheet1
M2 Pros M2 Cons MG Pros MG Cons
Easier to see whole Hard to manage when (M2) (M2)
app it gets large
Easier to stick to best Harder to learn (M2) (M2)
practice
Simpler organization: None (M2) (M2)
model is CFCs, view is
CFML
Easier to stick to best Harder to learn (M2) (M2)
practice
Supports pre/post- Not very granular Easy to learn since No real plugin concept
view plugins 'plugins' are just so it isn't as powerful
controllers
None Not very granular (M2) (M2)
None You have to build it all (M2) (M2)
yourself
Simple infrastructure Not as much control (M2) (M2)
in place for quite a over framework
while behavior, requires
both <cfinclude> and
CFC-creation setup
(mapping and custom
tag paths)
None No support for (M2) (M2)
partitioning
applications
Single sign-on across Sub-applications (FB) (FB)
multiple apps cannot share
properties etc
None All commonality must (M2) (M2)
be explicitly
programmed
Page 4
Sheet1
You can move views A lot more XML to (FB) (FB), although you
around and only write (and it's very specify the view
change a single tedious) location via a mapping
declaration in the XML which means you can
file move all your views to
a new location and
only change one XML
setting
Implicit invocation The event queue (M2); Messages are The event model is
provides looser model is very hard for processed as they are essentially static (like
coupling, more many web developers broadcast (rather than FB) but interpreted
flexibility and more to grasp; Dynamic being queued); (like M2) although the
dynamic power within interpretation of the Broadcast / listener performance overhead
the framework event queue has a model is even more is lower than M2
performance overhead loosely coupled than
M2
Event object is a nice Framework doesn't Very consistent – all None
encapsulation fully support event data is passed via the
object as a data bus event object which
becomes the view
state
Automatic <property> is (M2) (M2), although you
management of restricted to simple use controllers instead
application data string data so plugins of plugins and the
are often required event object instead of
updating the settings
Standardized Complex, requires (M2) CFCs must extend
infrastructure to integration with the and initialize the base
manage CFC lifecycle framework and non- controller
standard CFC
structure
Page 5
Sheet1
Clear delineation of Requires more code is (M2) (M2)
declarative written
configuration and
procedural logic
Simple interactions Often requires either (FB) (FB)
with the business more roundtrips to the
model business model or use
of complex data
structures to simulate
multiple results
Consistent framework Need to use design (M2) (M2)
interface (listeners) patterns to manage
separation of
persistence
Page 6
Sheet1
GGCC Example?
fusebox.xml.cfm and
circuit.xml.cfm, mach-
ii.xml, ModelGlue.xml
GGCC3-7 are MVC
Show each apps
directories
GGCC3-7 use CFCs
GGCC4/5 have M2
plugin, no FB plugins
All but GGCC1 use
public/private
somewhere
None
The examples assume
you have /fusebox4,
/MachII, /ModelGlue
either as mappings or
in your web root
FB examples use
multiple circuits
N/A
GGCC1 uses
<prefuseaction> and
also reuses common
fuseactions (see
taskmanager circuit)
Page 7
Sheet1
GGCC4/5 cheat a little
since they use <view-
page> directly rather
than separate view
events (which would
better match the FB
examples)
No real example of
this
GGCC4 needs to do a
lot more work to
maintain the event
data bus but FB apps
are inconsistent about
attributes, variables
and request scope
All the FB examples
(GGCC1/2/3/6) use
fusebox.init.cfm for
globals, M2
(GGCC4/5) uses a
combination of
<property> tags and
plugins, MG (GGCC7)
uses a combination of
<setting> tags and
controllers
Compare GGCC3,
GGCC4 and GGCC7
to see how the
different frameworks
handle this
Page 8
Sheet1
User identity is a good
example in every
variant
Compare GGCC2 with
GGCC3 to see how
the single return value
affects things; GGCC7
goes back to multiple
results
Both GGCC3 and
GGCC4 blend
persistence into main
model, as does
GGCC7
Page 9
