You keep getting it wrong. The key request.IN.FIELDNAMES must always
exist, just like form.fieldnames. So it must be declared specifically.
"Do you intend to support other databases at some point?" Now that is
a fair question. At this time, the tool uses the ANSI SQL Standard
Information_Schema views for meta-data. (Information_Schema is a
non-conforming extension to the standard) If the database supports
that part of the standard, and supports stored procedures, I would
consider the database. Since the code is open source, you are free to
build an information_schema.cfc for another database.
"And yet you get upset when someone suggests improvements?" The tool
has had many improves thanks to suggestions by others. If you have
something constructive to offer put it on cfopen.
You see Sean you cannot wear 2 hats as you claim. The Macromedia hat
is to big. When you make flaming attacks on someone's products, you
are the cause of restraint of trade and that reflects on Macromedia.
So I ask you again:
You said, " if someone is looking to learn *good* OO practices, CFSQLTool
look." So if CFQLTool outputs getter and setter will you retract this
statement?
At 10:19 PM 11/8/2005, you wrote:
On 11/8/05, Joseph Flanigan <[EMAIL PROTECTED]> wrote:
> 1. The tool clearly states MSSQL 2000. The tool does not make
any claims to
> support other databases.
Do you intend to support other databases at some point?
> 4. Request.IN.FIELDNAMES must be set to a value before calling
> structKeyList because: "A list of keys; if structure does not exist,
> ColdFusion throws an exception"
Earlier in that function you do this:
if(not isDefined("request.IN")) {request.IN = structNew();}
That ensures that request.IN has a struct value so the assignment to
request.IN.FIELDNAMES is not required, as I said.
> 5. "Joseph's whole point is about best practices and arguing
that CFSQLTool
> is a good example to follow." That is not the whole point. The
point is that
> CFSQLTool is a new design tool for creating CRUD queries. I published the
> entire code on CFOpen so people can choose to improve.
And yet you get upset when someone suggests improvements?
> It is correct that I do not agree what some of the things you preach are
> best practices, certainly not always good architecture. I have said before
> you are a good with programing tricks.
We certainly do disagree on a lot of things :)
> I will ask this again.
>
> You said, " if someone is looking to learn *good* OO practices, CFSQLTool
> is definitely not the place to
> look." So if CFQLTool outputs getter and setter will you retract this
> statement?
Sorry, but it would take a lot more than that small change to change
my opinion of CFSQLTool.
--
Sean A Corfield -- http://corfield.org/
Got frameworks?
"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' as the
subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
-----------------------------------------------------------------------
http://www.switch-box.org/CFSQLTool/Download/
Switch_box MediaFirm, Inc.
www.Switch-box.org Loveland, CO USA
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
