1) I may have understated my theory of "dumb layouts" - the layout system you have in place doesn't seem quite adaptable enough for a larger-scale (200-screen) application, such as a biggish store or a large user community. How would you handle Fusebox's notion of "Nested Layouts," for example? What about changing the page title (part of the view) based on some piece of data only available through the model (article title, item name, etc.)?
Our application has more
than 200 hundred type screens (if you take into account all the possible
pagelet combinations of our 40 layout pages) and we did not encountered any
limitations.
It is true that you
cannot have the notion of "Nested Layouts" from
Fusebox.
It is a limitation of
the fact that the page is executed pagelet by pagelet, by following the
pagelet order in the page.
On the other hand, the
Fusebox "Nested Layouts" functionality adds a lot of
overheads...
Most of the time, the
functionality brought by "Nested Layouts" can be easily worked around by passing
the necessary parameters in the URL (ex. : article title) or by using the
request scope to share the result all over the
page.
When I need a piece of
data all over the page, I put the result of the Entity CFC or Utility CFC
in the request scope.
In all the pagelets
requiring the "shared" result, I test if the result already
exists in the request scope (<cfif
isDefined()>).
If it don't (during the
first encountered pagelet), I execute the CFC and put the result in
the request scope for next pagelets that might use it (without re-executing the
CFC).
The other disadvantage
of "Nested Layouts" is that it is not as easy to understand as simple layout
pages (a direct representation of what you see on the
screen).
In my opinion,
simplicity with few limitations is always better than complexity without
limitations.
2) Indeed, the BlogMX works (on my machine, no less, and before I asked about this the first time) without doing anything but creating the datasource. I guess the namespace could be reduced from com.mycompany.mycfc to just mycom.mycfc or something... then there's the appConfig file. Would you then just make one per application?
It is
a good practices to use a package naming convention in order to avoid naming
clash.
The
com.mycompany.mycfc is a well-know practice, but if you are sure that you'll
never get conflict by using mycom.mycfc, then go for it.
Same
thing for the appConfig file, you might have one or several
ones.
What
we do in our case, is that we have one generic cfapp-config.xml, that define
configuration parameters linked to the current server for all the
applications with a unique xml schema, such as :
-
physical path names,
-
domain names,
-
datasource names...
Ex.
: in our cfapp-config.xml, we have one application
definitions for each different server configurations :
- one for myApp.local (local developer machine),
- one
for myApp.dev (dev server),
- one for myApp.com (production
servers).
When
we move your application from server to server, we don't have to
change this config file, we only need to call the correct application in
Application.cfm (one line to change).
Then
we have one config file specific to each application (functional parameters
definition), because each application might require its own xml
schema.
Those
config files usually don't need any modifications when the application is moved
from server to server (only one definition is valid for all of
them).
3) Speaking of the appConfig file, what drives you to use XML for the app config, and the .properties format for the i18n data? Would it not be just as easy, if not easier and faster to simply create structures in cfscript, or even with cf tags?
Barney
Boisvert has already well answered the question.
We use
XML because it is the standard for configuration file definition, especially in
J2EE (look at all the configuration files of CFMX and Jrun).
As for
the .properties files, it is also the standard in J2EE world for
i18n.
The
big advantages is the interoperability with the J2EE world.
Your
application might use existing .properties i18n files or a pure java
application might use your .properties i18n files.
If you
use WDDX or cfscript, you're stucked in the CF "little" world...
;)
When
I've defined MVCF, I've tried to have an approach very similar to the usual J2EE
approach in terms of architecture and in terms of syntax.
The
great thing : any J2EE developers will be able to understand the way your
application is architectured and even the way your application is coded because
the principles and the syntax are very similar.
This
is definitely not the case with Fusebox... where you're again stucked in the CF
"little" world... ;)
Interoperability with J2EE is one the main advantage of
CFMX.
So it
sounds logical to use similar syntax (taglib with prefix), terms and design
patterns (Entity/Session, Stateless/Stateful, Facade component, MVC...),
especially for communication between different dev teams (one might use CF, the
other might use Java...).
Benoit
Hediard
#affinitiz.com
