John,

Take a computer science course, and if the instructor says "yeah this
whole encapsulation thing... don't bother", come back and tell us.
Otherwise, I don't see how the burden is on Sean to make a supporting
argument to something that you can find in every single software
engineering textbook out there, with chapters upon chapters of
information as to "why" (not just "cuz we say so").

Anyways... you want "Separation in API of Tiers (Data, Logic, Content,
Presentation)". So if you have a data-model CFC, which directly
references the request scope, that is in clear violation of something
you claim to support. What if some day someone clever figures out how to
make apps interact with your CFC's without the use http? (*hint*)...
that will pretty much make your request-scope-dependent CFCs fall flat
on their face. Same thing with frameworks... what if someday you want to
use framework x because it does y... oh but wait you coded all of your
business logic to rely on something provided by the original framework
you used and has become obsolete or unsupported. These are just a few
benefits of encapsulation, and trust me there are many, many more.

-Dave


>>> [EMAIL PROTECTED] 9/30/2004 9:04:35 AM >>>

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
Of Sean Corfield
Sent: Thursday, September 30, 2004 1:51 AM
To: [EMAIL PROTECTED] 
Subject: Re: [CFCDev] Function Libraries

On Wed, 29 Sep 2004 21:18:02 -0400, John D Farrar
<[EMAIL PROTECTED]> wrote:
> Yet, I am not much of a respecter of persons... so "I disagree" is
> merely a statement... give me some facts.

I've mostly given up arguing with you because you have such strange
views. Sorry but you seem to be very uninformed about the vast body of
software engineering information out there and you persist with ideas
that run counter to decades of well-tested and well-established best
practices.

Answer: You haven't argued... that is my point. You simple state
"standards"
without supporting them. You say, "I disagree"... which is fine. But
the
fact that you disagree isn't a "reason". That is what I keep asking
for...
you haven't argued. You have simply stated principles that the "less
enlightened" are suppose to accept based on your experience. Yet, you
won't
explain to me the why! That is why I don't accept them... and that is
what I
am telling you. ... And, the vastness of opinion doesn't make
something
truth. Galileo presented a scientific study dropping two objects from
the
tower of Piza to show how mass and gravity worked. After making his
point,
(which was "strange views") they went on teaching the same thing. They
couldn't see it. All I am asking, is give me some Galileo type
proof...
rather than your bragging about your credentials. I am more willing to
look
at what you have to say because of your credentials, but not just
accept it
because you have them.

> Does Mach II have a Framework that covers API
> rules from coding methodology to presentation layer variable rules
and
> techniques?

That question makes no sense. Mach II *is* a framework.

Answer: Again... back to the illusive term framework. You are playing
word
games... and as you said below. 

> That is how I term Framework...

Well, that's just confusing the issue then - why not use the same
terms with the same meanings as the rest of the software industry?

Answer: I have not spent 25 years defining terms. You have, what is the
term
for a system with these features.

1. API to build software around. (so you can build programs in windows
like
fashion vs. DOS approach... and you say my ideas are strange... heh,
what a
laugh, APIs are not strange)

2. Separation in API of Tiers (Data, Logic, Content, Presentation)
where
appropriate and productive. (Some more strange ideas?)

3. Code reuse and accomplish number 2 through CFTags, CFCs, UDF
Libraries
and variable scheme.

4. Creation of Web Skins... so multiple methodologies can be used on
one
site with same look and feel. Applications built on sites can be
installed
without touching presentation layer to integrate.

5. Common user/authentication system. Same as number 4... application
integration without rewriting.

Now, I have done much of this work on my own... so someone with as
much
experience as you can certainly find flaws in the "grand scheme" of
practice. Yet, if you consider the 5 goals I listed above as strange...
that
would be amazing!

Lastly... you are speaking of enterprise. This seems to be the focus of
most
of the "standards" groups. That is how something like Mach II likely
shines!
Yet, if you have a small business... say a auto glass store, or a
local
health food coop store.... are you going to learn Mach II to build a
web
site? Well, yes... you would. :) Yet, very few others would. That is
what my
efforts are about. They are about SOHO software that allows small
business
to do business in the big business world without enterprise budgets.
(Another one of my strange ideas... compassionated engineering)

I am sure you can pick me apart, and using your credentials and
industry
experience you can make it sound good... and beat me in the status
game.
What I am asking you for is knowledge and answers... not rhetoric. That
is
the difference between contributing and arguing. All I did was give
answer
from what I know. And you shot me down based on "who you are". I find
that
attitude offensive... and would ask you to be a bit more respectful of
your
fellow man. If my ideas are strange... use your knowledge and shine a
little
light.

Thanks,

John Farrar

----------------------------------------------------------
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]
----------------------------------------------------------
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