RE: [CFCDev] MVCF at benorama.com

[Davis, Eric]

Title: Message

Thanks for the comments, Benoit. I believe I'm starting to understand your methodology a bit better.

 

Some followup:

 

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.)?

 

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?

 

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?

 

 

That's all for now. :) and thanks!

 

ecd.

 

-----Original Message-----
From: Benoit Hediard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 2:46 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] MVCF at benorama.com

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).

Each application has its own ui and layout cftags.

But if you wish to share it accross your applications, you could do it (and add the required dynamic attributes if necessary).

This is up to you.

 

In fact, only the pagelet tag is a generic custom tag that you can use in any application (the only "framework" tag).

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. 

I don't think that it would be difficult : as soon as you use correct namespaces for CFC and Pagelets to avoid name clashes, you should not have any issues.

 

If you don't want a single shared "/CF-INF" and "/com" mapping, you could have a local "system" folder for each one of your applications and use the corresponding application prefix as it is explained here :

http://www.benorama.com/coldfusion/patterns/part8.htm

In fact, the BlogMX example application uses this technique : you don't have to define any mappings, it works "as this" (you just need to define the datasource). 

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