On Wed, 29 Sep 2004 18:28:15 -0400, John D Farrar
<[EMAIL PROTECTED]> wrote:
> Encapsulation debate rages like a cult blindness. There is good reason for
> encapsulation... but if you follow that using request variables is always
> bad (or functions) then you could never use a CGI variable inside a CFC
> either... that would have to be passed it.

Correct, CFCs should not reference CGI scope either - unless the CFC
is specifically a service for retrieving CGI data (in the same way
that session scope should not be used inside a CFC except for specific
CFCs that act as session fa�ades).

> 1. If your CFC is designed to work in a Framework/Methodology ... like mine
> are, then this is less of an issue. It's like the CGI issue mentioned above.

Nonsense. That just says the framework is broken.

It's why the Mach II team are looking very closely at the (mistaken)
choice to use request scope as a data bus. It was a bad decision and
it can lead to poorly encapsulated code.

I'm already working with two new invokers in Mach II that store
results into the event object instead of the request scope. That's
something that can be done today, within the framework, to create
better encapsulated code. We still have to address <view-page> and
<event-arg> but it won't happen for 1.0.10.

> ...therefore calling the library and running the UDFs
> in request scope is a GOOD design pattern.

I disagree.

> Frameworks change the tenure of the
> discussion.

I disagree.
-- 
Sean A Corfield -- http://www.corfield.org/
Team Fusebox -- http://www.fusebox.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to