I can appreciate your distaste for "dumb Views;" however, you seem to have swapped them out for dumb layouts. The page.cfm custom tag may be powerful, but it must be generic enough to work for every application that calls it.
Indeed, the page.cfm custom tag is related to the application (it is mainly the header/footer of the application).
In fact, the only glaring weakness I can see in your MVCF (which I really do like, I promise) is that it only seems to concern itself with a single application on each server, or a single application deployed amongst several servers. I'm in the opposite boat, developing lots of small applications for internal use only, that all must reside on the same server. Adapting your MVCF to fit this system is going to be quite difficult, I fear.
Back to the <layout:page> tag: I'm glad to see you use a single layout page now, "article.cfm," but doesn't that kind of obviate the need for the page tag? When your content is all controlled by the same template, why obfuscate the process with a custom tag?
Indeed, I am using a single layout page "article.cfm" in the latest BlogMX example application (not the one on benorama.com), so the benefits of page.cfm custom tag are not clear.
In our "real" application we have many different layout pages : one for each functionnality (news.cfm, article.cfm, forum.cfm, directory.cfm...), so the page.cfm tag is shared accross those layout pages.
In fact,
if you don't like the page.cfm tag, you might replace it by two pagelets, a
header pagelet and a footer pagelet.
I'm using a
<layout:page></layout:page> because I find it nice for the
readability of the page, to clearly define the start and the end of the
page.
Moving on:
Do you anticipate any scalability problems with your CFCs-as-models? Will you be surprised if you discover some once your application is in production? If not, will you please share why not?
We
are not in production yet and we have just made some load testing for the
moment.
But, I don't see why we would have scalability
problems directly linked to the choice of CFCs-as-models (except that it might
consume more RAM than before).
It is true that I was not sure about this ...
until the new macromedia.com was launched. It is the best proof of scalability
of CFMX (and CFCs).
Figures show that CFCs don't add so much overhead compared to cfinclude or cfmodule.
How is your entity CFC (below, called "NewsEntity" and stored as newsEntityInstance) persistent? Do you maintain it across requests, or am I misunderstanding your use of "persistence" (or persistence in general)?
Yes, "persistence" is very often a confusing
term.
Many people use "persistent" for the session/application scope, I
prefer to use stateful (!= stateless) to define if an object "persists" accross
requests.
Entity CFCs are "database persistent" :
-
the get() method correspond to a SQL
select.
- the create() method correspond to a SQL
insert.
- the update() method
correspond to a SQL update.
- the delete() method correspond to a SQL
delete.
(they could also be "XML persistent" if you don't need a database use
file-based datasources...)
Have a look at the article.cfc on the blogMX example application, it is typically an Entity CFC representing an article Entity in the database.
Entity CFCs or Utility CFCs are usually stateless
(do not persists accross requests).
Only Session CFC are stateful (in the
session scope).
Those Entity/Session, Stateful/Stateless terms have
been taken from J2EE EJB principles.
Benoit Hediard
www.benorama.com
