-- Topica Digest --
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
Re: FB3 layout confusion
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
RE: Fusebox MX
By [EMAIL PROTECTED]
fuseQ mailing list?
By [EMAIL PROTECTED]
Re: Fusebox MX
By [EMAIL PROTECTED]
RE: MX Books
By [EMAIL PROTECTED]
<cf_reuseform>'s datasource attribute?
By [EMAIL PROTECTED]
------------------------------------------------------------
Date: Mon, 01 Jul 2002 08:16:27 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Hal,
If we were just talking about the steering Com. setting a standard for MX. That would
be fine. Those guys have been working as available, and have spent months making the
progress they have made! Now, my thought is would be a narrowing of the subject... and
a delay on solutions if we were to move the discussion to SteerFB. Come one HAL...
PLEASE!!! May we have your blessing to talk about it here??? (I hate begging!)
John
>>> [EMAIL PROTECTED] 06/28/02 03:31PM >>>
Let's move this discussion to [EMAIL PROTECTED]
-----Original Message-----
From: John Farrar [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 1:21 PM
To: [EMAIL PROTECTED]
Subject: Fusebox MX
Here are some thoughts on FuseBox with Coldfusion MX.
1. Move all queries to cfc's.
2. Move common actions to cfc's.
3. Keep the index file concept for a central "switch" file, and
"settings" file in each circuit.
That is basically how I see mx differing from current fusebox. The
switch file or the settings file will be calling cfc's directly. There
may even be occassions where someone may call cfc's from the display
page. The bigger issue with that is when you are reviewing where the
data cfc's are used, you will not know where they are used as easy as
scanning the switch file. This does not make the query embeding "wrong"
before the horn blowers wear out another trumpet. It just would vary
from the current concept.
4. It is possible that some of the core file should be moved to cfc's.
5. There should be a standard function library file like the one
included in John's FuseQ technology. 6. We should consider moving some
layout technology to a cfc. 7. THESE ARE JUST IDEAS... let's have some
feedback.
John Farrar
------------------------------
Date: Mon, 01 Jul 2002 08:19:11 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
I was thinking of using them as "Display Handlers". You would store the content of say
a "Price List" in a structure with a function or a CFC (used to use Custom tags to do
this)... then use a CFC to pull the structure and convert it for web display.
John
>>> [EMAIL PROTECTED] 06/28/02 02:12PM >>>
All I can tell you from personal experience so far is that CFC's
will provide the greatest value when used within the MODEL portion of your
app design...(for me this means a large portion of my act_ file contents and
qry fuses) and typically that's where you'd also find the functionality
you'd typically want to expose as a service.
I'm not suggesting there's nothing *beyond* this...but at this point
that's where I'm seeing the immediate and significant benefits.
Stace
-----Original Message-----
From: Ken Beard [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 2:04 PM
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
how do you call a fusebox app as a web service?
seems like you'd make the core file a cfc itself (each of the sections an
internal method, each fusebox. var an external property, each fb_ var an
internal property, and one external method=init)
maybe the core file automatically suppresses layouts if it is called as a
webservice?
ideasideas
ken
-----Original Message-----
From: John Farrar [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 28, 2002 1:21 PM
To: [EMAIL PROTECTED]
Subject: Fusebox MX
Here are some thoughts on FuseBox with Coldfusion MX.
1. Move all queries to cfc's.
2. Move common actions to cfc's.
3. Keep the index file concept for a central "switch" file, and "settings"
file in each circuit.
That is basically how I see mx differing from current fusebox. The switch
file or the settings file will be calling cfc's directly. There may even be
occassions where someone may call cfc's from the display page. The bigger
issue with that is when you are reviewing where the data cfc's are used, you
will not know where they are used as easy as scanning the switch file. This
does not make the query embeding "wrong" before the horn blowers wear out
another trumpet. It just would vary from the current concept.
4. It is possible that some of the core file should be moved to cfc's.
5. There should be a standard function library file like the one included in
John's FuseQ technology.
6. We should consider moving some layout technology to a cfc.
7. THESE ARE JUST IDEAS... let's have some feedback.
John Farrar
AVIS IMPORTANT:
-------------------------------
Les informations contenues dans le present document et ses pieces jointes sont
strictement confidentielles et reservees a l'usage de la (des) personne(s) a qui il
est adresse. Si vous n'etes pas le destinataire, soyez avise que toute divulgation,
distribution, copie, ou autre utilisation de ces informations est strictement
prohibee. Si vous avez recu ce document par erreur, veuillez s'il vous plait
communiquer immediatement avec l'expediteur et detruire ce document sans en faire de
copie sous quelque forme.
WARNING:
-------------------------------
The information contained in this document and attachments is confidential and
intended only for the person(s) named above. If you are not the intended recipient
you are hereby notified that any disclosure, copying, distribution, or any other use
of the information is strictly prohibited. If you have received this document by
mistake, please notify the sender immediately and destroy this document and
attachments without making any copy of any kind.
------------------------------
Date: Mon, 1 Jul 2002 08:35:05 -0400
From: [EMAIL PROTECTED]
Subject: Re: FB3 layout confusion
Thanks, Peter. http://www.grokfusebox.com under the Books page--you can
get any of a variety of CF books from there. (Half of those reading this might
want to buy from www.fusium.com--Nat's site :) )
- Jeff
On 29 Jun 2002 at 22:36, peter wrote:
> thanks, i've actually been looking for your book in the stores for the past
> week or so. i think amazon said it was available now, but have yet to see it
> anywhere locally here. maybe i'll just break down and buy it online and hope
> it can get to my door within a week.
>
> if i DO buy it online, do you have it somewhere in your amazon affiliate
> thingie where we should all be buying it from so you get a bigger kickback?
> or should we all just be mailing you cash and you can get them free from
> your book publisher, and then you autograph them and mail them out ;)
>
> thanks for the help
> peter
>
> ----- Original Message -----
> From: "Jeff Peters" <[EMAIL PROTECTED]>
> To: "peter" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Saturday, June 29, 2002 4:06 PM
> Subject: Re: FB3 layout confusion
>
>
> > Hi, Peter -
> >
> > Layouts work in a nested fashion, working from bottom to top. The output
> > produced by the target circuit (where the called fuseaction exists) is
> stored in
> > the variable fusebox.layout. That is then wrapped in the layout for the
> > target's parent. Since a layout file by definition must output
> fusebox.layout,
> > the two layouts are combined. If the parent is not the top-level circuit,
> the
> > result is again stored into fusebox.layout and the process repeats, going
> up
> > the structure until the top-level circuit is reached.
> >
> > Because of this behavior, you can put anything that should appear globally
> in
> > a home circuit's layout file, then put the things that should appear only
> in a
> > specific circuit's fuseactions into a layout file in that circuit.
> >
> > We cover nested layouts and nested circuit processing extensively in
> > "Fusebox:Developing ColdFusion Applications".
> >
> > - Jeff
> >
> > On 29 Jun 2002 at 14:36, peter wrote:
> >
> > > Ok, maybe I'm the only person not really getting this, but can somebody
> help
> > > explain to me how the layouts work now in FB3?
> > >
> > > I have a simple app that I am trying to build, and it has a couple
> circuits
> > > and what I'm trying to do is override the current display file for some
> > > fuses and stop the inheritance if possible on a few other fuses.
> > >
> > > Since that was a really piss poor explanation, let me see if I can draw
> one
> > > of these cool diagrams.
> > >
> > > Home
> > >
> > > --| store
> > >
> > > ----| checkout
> > >
> > > Ok, it isn't even a very good diagram, but hey, it's Friday and I can't
> draw
> > > to save my life.
> > >
> > > So when my app is in the home circuit, I want it to show menus and my
> > > dsp_defaultLayout.cfm file. But when you are in the "Store" circuit, I
> want
> > > it to show the menus and everything else, but also have a small
> "mini-cart"
> > > off to the right hand side (so maybe override the local
> > > dsp_defaultLayout.cfm and use dsp_differentLayout.cfm or something a
> little
> > > less ambiguous). Now, when you are in the "checkout" circuit, I was
> trying
> > > to NOT have it display the mini-cart on the right but inherit from the
> base
> > > display file. and sometimes i want to have no header or footer at all
> > > (invoices and stuff).
> > >
> > > Is there a way in fusebox 3 to change layouts on a "per fuseaction"
> basis?
> > > Or would I have to put each one of these fuses that have "different"
> > > displays into their own circuits?
> > >
> > > Ideally the kind of layout I want is something like "amazon.com" where
> I'd
> > > have some navigation up top, and then categories or something off to the
> > > left, and then shopping cart, login, banners or something off to the
> right,
> > > but having a hard time conceptualizing how to do that in fb3.
> > >
> > > Whew!
> > >
> > > Thanks for reading this far.
> > >
> > > peter
> > >
> > >
> >
> >
> >
> >
>
>
------------------------------
Date: Mon, 01 Jul 2002 08:36:21 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
So... this is another developer who claims to see the light... but cannot discribe the
light to the common man. Is this like a Sci-Fi religion. It reminds me more of Logan's
Run. "Renew! Renew! Renew!"
Give us a break... and tell us why. It seems the whole issue is a separation of
layers! Right???
If separation of layers is the the issue... you can separate the layers fine... even
if you are using cfc's. You would then need to say that you do not make a cfc for
business logic that contains display logic. Let me quote Spike ... "Good CFC's allow
you to change the business logic that works in the cfc without changing the display
layer and vice versa as long as you maintain the same data types for the function
input and output." If the cfc's are separated physically and logically, then you have
done this! Right! And... if the cfc is not designed to feed Flash, Javascript... but
does make code universal for display... code reuse jumps up, development time drops,
features expand and there are more of them... come on... you've got to give us
something better than some guy named "Spike" said so... if he's good... which he
likely is... ask him for an explaination, or give me his email so he can explain it to
me. OK?
John
>>> [EMAIL PROTECTED] 06/30/02 07:09AM >>>
Take this comments from Spike, one of the best CF developers out there
at mo, and from what he understands via numerous posts with myself and
MM during the lengthy Neo beta program (1+ years)
1. CFCs should encapsulate business logic, not display logic.
2. They should return data which is rendered by the client for display.
3. The client could be Flash, Javascript, ColdFusion Custom Tags, or
some other system
4. Good CFC's allow you to change the business logic that works in the
cfc without changing the display layer and vice versa as long as you
maintain the same data types for the function input and output.
Bottom line, they should not be used for display.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]]
Sent: 30 June 2002 11:50
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Not at all, CFC's are should not be used for display. I am not saying
they cannot be used for it, just that they shouldn't be.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 22:00
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Neil Clark - =TMM= wrote:
> CFC should not be used for display at all, by all means pass a
paramter
> to the CFC which in turn can call/invoke a display layer but using
> display within a CFC itself it simply wrong.
Utter nonsense. The beautiful thing about MX is that it opens up all
sorts of possibilities. Those with a slavish devotion to objectifying
their code can go that direction... for others, CFCs can serve as really
handy web service wrappers, interesting replacements for FB switches,
custom tags with oomph, or perhaps just super-flexible UDFs.
None of those uses are wrong, simply or otherwise. And that kind of
freedom is one of the reasons I use CF in the first place.
--
Roger
------------------------------
Date: Mon, 1 Jul 2002 09:23:34 -0400
From: "Timothy Heald" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
It's not just a separation of layers issue John. Lets look at it like this.
It's a separation of clients also.
Clients available are:
1. HTML Browser
2. Flash Movie
3. Wireless device
4. Other server
So say I have an application, lets use the contact management idea.
Now I will have add, edit, delete and view contacts. Ok so to add a contact
I only need to expose the actual query that will add one so:
component contacts
function addUser access=remote returns=number
input into blah
values blah
select @@identity as contactid
return contactID
end function
That is a sound use of CFCs. Why because I have only business logic in it.
Any of the above clients can use that function, as it doesn't say how the
returned information is to be displayed. If you were to return HTML it
would break in some of those clients, or at least require a lot of
preprocessing, just to get a simple numeric value.
Now of course that was a very simple, psedo code example, but I am going to
sit down and really write a demo app one of these days, I have just been
super busy lately.
Couple of things to think about, when you are writing your CFC:
1. You don't expose CFCs, you expose functions contained inside those CFCS.
2. When writing a CFC you are trying to group like functionality, usually
that relates to a single object, such as a contact or a user or maybe a
shopping cart.
3. When writing an app today it is always good to consider future users.
With the web as it is today that means the list above. What that means next
year or the year after is anyone's guess. I would like to write my apps in
such a way that all of the clients we currently have can access them with
ease. I would also like to think that MM will allow me to take apps that
expose themselves correctly, and make them available as new technologies
emerge.
Another good way to frame this conversation is to separate applications from
web sites. I mainly work on web based applications. Personnel/HR, apps for
schools to administer their districts. We don't do a lot of web site
development. When I write lets say a user management tool, I want to give
them as many options for use as is possible. We have requirements for
Wireless access; some people don't use up to date browsers, so Flash may
make more sense; a county may have their own developers that need to tie in
to our personnel application, only they are C++ developers. Exposing
functionality is where I am going to win. I can write one personnel
application once. If written correctly, I create whatever front end I want
for each client, wireless, html or flash. Now the C++ guys, they don't need
display info. They can create their own interface however they want. All
they need to know is what they need to hand me, and what I am going to give
back.
Now the discussion has also turned into using CFC functions to display data
which is returned from another function So:
myCFC.getContacts();
myCFC.conatctsIntoTable();
I think I would have less of a problem with this, but I would probably still
use dspContactsTable.cfm because it is easier, and still maintains my
separation. One of my fuseactions might look like this:
<CFCASE value="contactsList">
<!--- use the contacts object which I create using
createObject("component","contact") in this circuits settings --->
<CFSCRIPT>
myContacts.getContacts();
/* lets say I created another function to return only contacts that are
"well formed"
*/
contactQuery = myContacts.cleanContacts();
<CFSCRIPT>
<!--- include the display template, which uses the query object
contactQuery --->
<CFINCLUDE template="dspContactTable.cfm">
</CFCASE>
Could you do the same thing with separate functions? Sure, I don't have a
problem with that, so long as the logic, data and the presentation are
separated. I am going to stick with display circuits though.
Am I making sense?
Tim
-----Original Message-----
From: John Farrar [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:36 AM
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
So... this is another developer who claims to see the light... but cannot
discribe the light to the common man. Is this like a Sci-Fi religion. It
reminds me more of Logan's Run. "Renew! Renew! Renew!"
Give us a break... and tell us why. It seems the whole issue is a separation
of layers! Right???
If separation of layers is the the issue... you can separate the layers
fine... even if you are using cfc's. You would then need to say that you do
not make a cfc for business logic that contains display logic. Let me quote
Spike ... "Good CFC's allow you to change the business logic that works in
the cfc without changing the display layer and vice versa as long as you
maintain the same data types for the function input and output." If the
cfc's are separated physically and logically, then you have done this!
Right! And... if the cfc is not designed to feed Flash, Javascript... but
does make code universal for display... code reuse jumps up, development
time drops, features expand and there are more of them... come on... you've
got to give us something better than some guy named "Spike" said so... if
he's good... which he likely is... ask him for an explaination, or give me
his email so he can explain it to me. OK?
John
>>> [EMAIL PROTECTED] 06/30/02 07:09AM >>>
Take this comments from Spike, one of the best CF developers out there
at mo, and from what he understands via numerous posts with myself and
MM during the lengthy Neo beta program (1+ years)
1. CFCs should encapsulate business logic, not display logic.
2. They should return data which is rendered by the client for display.
3. The client could be Flash, Javascript, ColdFusion Custom Tags, or
some other system
4. Good CFC's allow you to change the business logic that works in the
cfc without changing the display layer and vice versa as long as you
maintain the same data types for the function input and output.
Bottom line, they should not be used for display.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]]
Sent: 30 June 2002 11:50
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Not at all, CFC's are should not be used for display. I am not saying
they cannot be used for it, just that they shouldn't be.
Neil Clark
Team Macromedia
http://www.macromedia.com/go/team
Announcing Macromedia MX!!
http://www.macromedia.com/software/trial/
-----Original Message-----
From: Roger B. [mailto:[EMAIL PROTECTED]]
Sent: 28 June 2002 22:00
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Neil Clark - =TMM= wrote:
> CFC should not be used for display at all, by all means pass a
paramter
> to the CFC which in turn can call/invoke a display layer but using
> display within a CFC itself it simply wrong.
Utter nonsense. The beautiful thing about MX is that it opens up all
sorts of possibilities. Those with a slavish devotion to objectifying
their code can go that direction... for others, CFCs can serve as really
handy web service wrappers, interesting replacements for FB switches,
custom tags with oomph, or perhaps just super-flexible UDFs.
None of those uses are wrong, simply or otherwise. And that kind of
freedom is one of the reasons I use CF in the first place.
--
Roger
------------------------------
Date: Mon, 01 Jul 2002 09:56:15 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Tim,
So, it is not a technical functional constraint that keeps us from putting code in
cfc's for display. It is a methodology issue. There is some needed uniform methodology
for the Flash, Javascript, etc. That makes sense...
Help me here ...
A. What if the cfc was not designed to serve the Flash, Javascript, etc?
B. What if the cfc was built to kick back the appropriate structure for the requesting
container type?
These are my thoughts...
1. I don't thing every cfc will be designed for serving to FlashMX... therefore, it
seems like Flash compadibility is only an issue when it is an issue, or could be in
the future. (This would be the same for any form of display container.)
2. The goal is to build and extend functionality, simplify the interface, speed
development time, reduce errors and provide a more common develpment platform for code
reuse!
Your last post helped me see what your point was... or what the issue is. I have shown
many developers fusebox... and they kicked an bucked... that's not the way it was
designed. You could blame Steve and Hal... now they have to show me what the issue is,
not just say... "It wasn't designed to work that way." Thanks for your time... great
post!
John Farrar
------------------------------
Date: Mon, 1 Jul 2002 10:16:09 -0400
From: "Timothy Heald" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Help me here ...
A. What if the cfc was not designed to serve the Flash, Javascript, etc?
>> If it is not designed to server as a function for more than one layer
(presentation, application or data) Then I wouldn't have a problem with the
FUNCTION. Again I think we are using the terms CFC and Function
interchangeably, and they are not the same thing. A CFC is like a class a
grouping of functions, properties and attributes.
B. What if the cfc was built to kick back the appropriate structure for the
requesting container type?
>>Again you are talking about mixing layers. Would it work? Sure you could
easily ad another attribute to the function that would specify what the
target client was, and it would work great, but I still think it's a bad
idea.
1. I don't thing every cfc will be designed for serving to FlashMX...
therefore, it seems like Flash compadibility is only an issue when it is an
issue, or could be in the future. (This would be the same for any form of
display container.)
>> You are correct. But the way I look at is if you design the application
with this in mind at the beginning, when the user comes back a year later
and says they need wireless access to your application, it doesn't take a
complete rewrite to make it happen.
2. The goal is to build and extend functionality, simplify the interface,
speed development time, reduce errors and provide a more common develpment
platform for code reuse!
>> I think this does all of those things.
extend functionality: You can create functions, available anywhere with an
internet connection, all in cftags.
simplify the interface: Your developers need know nothing about the
functions you expose for them. Only what it needs in and what it will
return.
speed development time: You can have your advanced developers working on
the objects, and your junior developers working on the rest of the app.
Will allow people to use their skills in such a way as to improve the time
for development and the quality of the application
reduce errors: By encapsulating advanced application logic and data access,
you will see less errors by your junior developers. You are just giving
them access to functions.
provide a more common development platform for code reuse: This is where
CFCs shine. I have written a utilities CFC. It gives me access anywhere on
my server (and in some cases any where with a connection) to all of my
security modules, personnel modules, whatever I feel like adding. At the
top of my application I create an object form this CFC in the application
scope, I then have all of it's functions properties and attributes available
to me through the rest of the application, and for those I exposed as web
services anywhere at all. That is the greatest amount of reuse I have ever
heard of.
My couple a coppers
Tim
------------------------------
Date: Mon, 1 Jul 2002 17:45:06 +0300
From: "Murat Demirci" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Some CFCs should be used for display, HTML/WML/Flash output or for
returning just a recordset or null.
CFCs are useful for code reusing and can be used instead of switch.cfms.
I think, Fusebox MX's switch.cfms should be upgraded to
circuit_name.cfcs. And reusable fuses should be cfincluded in
cffunctions. Of course, cffunctions can contain cfinvokes.
Index.cfms should call appropriate circuit_name.cfc passing fuseaction
to it as a function name.
I think this way is the easiest way to integrate CF MX, Fusebox and Web
Services.
Note: I don't know where is the FBSteer, please show me the way..
Murat Demirci
-----Original Message-----
From: John Farrar [mailto:[EMAIL PROTECTED]]
Sent: 01 Temmuz 2002 Pazartesi 16:56
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Tim,
So, it is not a technical functional constraint that keeps us from
putting code in cfc's for display. It is a methodology issue. There is
some needed uniform methodology for the Flash, Javascript, etc. That
makes sense...
Help me here ...
A. What if the cfc was not designed to serve the Flash, Javascript, etc?
B. What if the cfc was built to kick back the appropriate structure for
the requesting container type?
These are my thoughts...
1. I don't thing every cfc will be designed for serving to FlashMX...
therefore, it seems like Flash compadibility is only an issue when it is
an issue, or could be in the future. (This would be the same for any
form of display container.) 2. The goal is to build and extend
functionality, simplify the interface, speed development time, reduce
errors and provide a more common develpment platform for code reuse!
Your last post helped me see what your point was... or what the issue
is. I have shown many developers fusebox... and they kicked an bucked...
that's not the way it was designed. You could blame Steve and Hal... now
they have to show me what the issue is, not just say... "It wasn't
designed to work that way." Thanks for your time... great post!
John Farrar
------------------------------
Date: Mon, 1 Jul 2002 09:36:03 -0500
From: "Foster, Lee" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
Ok,
A. I agree with Tim. You shouldn't be using CFC' for displays directly. For
whatever that is worth.
B. Hal wants us to move this thread to SteerFB.
C. I'm going back to looking for work. So I can get back into the game
cause sitting on the bench is tiring.
It seems everyone is talking and nobody is listening to the other. There
are valid points I have seen on both sides. But overall I think CFC's
shouldn't be used for output to a screen directly. Use it to do some
formatting if you want but the actual output should be done in the DSP.
Else you will have a mess and the standards will have to be totally
rewritten or ignored.
Don't mean to get rude but the bench life is getting me down as the bills
pile up,
Lee Foster
(e)consultant, Web developer, Web Architect
[EMAIL PROTECTED]
615-834-1876
http://www.l3enterprises.com
Nashville, TN
-----Original Message-----
From: Timothy Heald [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:16 AM
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Help me here ...
A. What if the cfc was not designed to serve the Flash, Javascript, etc?
>> If it is not designed to server as a function for more than one layer
(presentation, application or data) Then I wouldn't have a problem with the
FUNCTION. Again I think we are using the terms CFC and Function
interchangeably, and they are not the same thing. A CFC is like a class a
grouping of functions, properties and attributes.
B. What if the cfc was built to kick back the appropriate structure for the
requesting container type?
>>Again you are talking about mixing layers. Would it work? Sure you could
easily ad another attribute to the function that would specify what the
target client was, and it would work great, but I still think it's a bad
idea.
1. I don't thing every cfc will be designed for serving to FlashMX...
therefore, it seems like Flash compadibility is only an issue when it is an
issue, or could be in the future. (This would be the same for any form of
display container.)
>> You are correct. But the way I look at is if you design the application
with this in mind at the beginning, when the user comes back a year later
and says they need wireless access to your application, it doesn't take a
complete rewrite to make it happen.
2. The goal is to build and extend functionality, simplify the interface,
speed development time, reduce errors and provide a more common develpment
platform for code reuse!
>> I think this does all of those things.
extend functionality: You can create functions, available anywhere with an
internet connection, all in cftags.
simplify the interface: Your developers need know nothing about the
functions you expose for them. Only what it needs in and what it will
return.
speed development time: You can have your advanced developers working on
the objects, and your junior developers working on the rest of the app.
Will allow people to use their skills in such a way as to improve the time
for development and the quality of the application
reduce errors: By encapsulating advanced application logic and data access,
you will see less errors by your junior developers. You are just giving
them access to functions.
provide a more common development platform for code reuse: This is where
CFCs shine. I have written a utilities CFC. It gives me access anywhere on
my server (and in some cases any where with a connection) to all of my
security modules, personnel modules, whatever I feel like adding. At the
top of my application I create an object form this CFC in the application
scope, I then have all of it's functions properties and attributes available
to me through the rest of the application, and for those I exposed as web
services anywhere at all. That is the greatest amount of reuse I have ever
heard of.
My couple a coppers
Tim
------------------------------
Date: Mon, 1 Jul 2002 09:47:07 -0500
From: "Foster, Lee" <[EMAIL PROTECTED]>
Subject: RE: Fusebox MX
http://www.topica.com/lists/SteerFB
Lee Foster
(e)consultant, Web developer, Web Architect
[EMAIL PROTECTED]
615-834-1876
http://www.l3enterprises.com
Nashville, TN
-----Original Message-----
From: Murat Demirci [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 9:45 AM
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Some CFCs should be used for display, HTML/WML/Flash output or for
returning just a recordset or null.
CFCs are useful for code reusing and can be used instead of switch.cfms.
I think, Fusebox MX's switch.cfms should be upgraded to
circuit_name.cfcs. And reusable fuses should be cfincluded in
cffunctions. Of course, cffunctions can contain cfinvokes.
Index.cfms should call appropriate circuit_name.cfc passing fuseaction
to it as a function name.
I think this way is the easiest way to integrate CF MX, Fusebox and Web
Services.
Note: I don't know where is the FBSteer, please show me the way..
Murat Demirci
-----Original Message-----
From: John Farrar [mailto:[EMAIL PROTECTED]]
Sent: 01 Temmuz 2002 Pazartesi 16:56
To: [EMAIL PROTECTED]
Subject: RE: Fusebox MX
Tim,
So, it is not a technical functional constraint that keeps us from
putting code in cfc's for display. It is a methodology issue. There is
some needed uniform methodology for the Flash, Javascript, etc. That
makes sense...
Help me here ...
A. What if the cfc was not designed to serve the Flash, Javascript, etc?
B. What if the cfc was built to kick back the appropriate structure for
the requesting container type?
These are my thoughts...
1. I don't thing every cfc will be designed for serving to FlashMX...
therefore, it seems like Flash compadibility is only an issue when it is
an issue, or could be in the future. (This would be the same for any
form of display container.) 2. The goal is to build and extend
functionality, simplify the interface, speed development time, reduce
errors and provide a more common develpment platform for code reuse!
Your last post helped me see what your point was... or what the issue
is. I have shown many developers fusebox... and they kicked an bucked...
that's not the way it was designed. You could blame Steve and Hal... now
they have to show me what the issue is, not just say... "It wasn't
designed to work that way." Thanks for your time... great post!
John Farrar
------------------------------
Date: Mon, 1 Jul 2002 23:36:26 -0400
From: "ecd" <[EMAIL PROTECTED]>
Subject: fuseQ mailing list?
is there a fuseQ mailing list? i've got some questions after some
preliminary investigation, and don't want to clutter the fuseBOX board with
fuseQ questions.
any pointers will help.
ecd
code artist
- ubergroove.com
edge team leader
- jaggedpeak.com
the force is strong with me.
------------------------------
Date: Tue, 2 Jul 2002 15:51:55 +1200
From: "James Sleeman" <[EMAIL PROTECTED]>
Subject: Re: Fusebox MX
----- Original Message -----
From: "Lee Borkman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, June 30, 2002 1:48 AM
Subject: Re: Fusebox MX
>...
> But this is pointless. Fuses simply aren't designed to function on their
own;
> they are mindless little pieces of code, surrounded by all kinds of other
code
> that gives them context. This fuse in my example just won't work without
at
> least having fbx_settings executed beforehand, and who knows what else.
>
> So if you want a web service that optionally accepts a customerID, and
returns a
> recordset, then the service has to have a few more brains than a dumb fuse
does,
> despite the fact that you don't need all of the presentation layer, etc.
So you
>...
It's been a long time since I've posted on fusebox... but this sounds right
up my alley. Let me explain, first some background...
I started using FB a couple of years ago, all was good, but I wanted more.
Over these 2 years I have more-or-less redesigned what was FB2 into my own
way of doing things, quite advanced, quite different to FB3 but reasonably
similar to how I think FB will end up being applied to CFC's.
I pretty much discarded the idea of "fuses" (although they (qry_, act_ and
dsp_) still exist, I don't think of them as individuals), instead focusing
my attention on "services" (sometimes I call them fuseactions, sometimes
services, service is more accurate). Services are grouped into structures
called "plugins" (each plugin is stored in it's own directory, infact they
are more or less self sufficient/contained and may have child plugins inside
it). When the application is first started it recursively scans through the
plugins it can find and determines which plugins offer which services, these
become available as "fuseactions" (services have an integer level which
determines which ones is made available in the event of two services with
the same name).
Now, some of these services cause things to be displayed, some of the
services are merely "supporting" services, for example, I might have the
following services (I also show the files they use)
listProducts
qry_listProducts.cfm
dsp_listProducts.cfm
queryProducts
qry_queryProducts.cfm
dsp_queryProducts.cfm
here's what happens when the user wants to list the products
(fuseaction=listProducts)...
The user hits the listProducts service over the web,
qry_listProducts.cfm does a CFMODULE call to the queryProducts service
(it doesn't know where it is, could be in a completely different directory,
the plugbox system knows where to send the request though)
qry_queryProducts.cfm performs the database query, it sees that it has
been called via CFMODULE (ie not as a web service) and so it stores the
query back into a special place in the callers scope
dsp_queryProduct.cfm doesn't do anything this time, because it's not
being used from the web
dsp_listProducts.cfm takes the query returned by the queryProducts
service and displays it in whatever manor it sees fit
Ok, so there we have a service being used locally as a cfmodule and of
course the listProducts service is being used over the web. But we can also
use the queryProducts service over the web, if say another web site wants to
get a list of our products...
the remote user hits the queryProducts service over the web
(fuseaction=queryProducts)
qry_queryProducts.cfm performs the database query but as it has been
called remotely it does not save anything into the caller scope
dsp_queryProducts.cfm sees that it has been called remotely and so it
simply displays (without any layout (I call them husks), by signalling the
parent plugins that no layout is required) a WDDX packet of the query for
the remote user to grab, deserialize and use at thier discretion.
So there is a service that is starting to look an awful lot like a CFC
method, taking some parameters, doing something, and returning something
that can be used programatically - either locally (via CFMODULE) or remotely
(through a WDDX interface over the web).
I don't know if or how I will be morphing plugbox into CFMX, but I'm pretty
sure that many Plugins will be converted to CFC's with the services of the
plugin as methods of the CFC.
I don't know how that can be related back to FB3, as I havn't really looked
too hard at that spec, but I'd hazard a guess that you'll end up grouping
fuseactions into CFC's with the fuseactions as methods of the CFC's.
---
James Sleeman
Innovative Media Ltd
Ph: (03) 377 6262
http://www.websolutions.co.nz
CAUTION: The information contained in this email message is confidential
and may be legally privileged. If the reader of this message is not the
intended recipient you are notified that any use, dissemination,
distribution or reproduction of this message is prohibited. If you have
received this message in error please notify the sender immediately and
destroy the original message and any attachments.
Views expressed in this communication may not be those of Innovative Media
Ltd.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.372 / Virus Database: 207 - Release Date: 6/28/2002
------------------------------
Date: Mon, 01 Jul 2002 23:10:50 -0500
From: Michael 'Maxxwell Edison' Porter <[EMAIL PROTECTED]>
Subject: RE: MX Books
--=====================_1363400==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Inside Coldfusion MX
by John Cummings, Neil Ross
http://www.amazon.com/exec/obidos/ASIN/0735713049/qid=1025582753/sr=1-2/ref=sr_1_2/002-4690897-7687228
Robi Sen
At 01:01 AM 6/29/2002, you wrote:
>I couldn't find that book....do you know the ISBN or full title?
>
>-----Original Message-----
>From: Stacy Young [mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 28, 2002 10:11 PM
>To: '[EMAIL PROTECTED]'
>Subject: RE: MX Books
>
>Lemme tell u that man knows his stuff !!
>
>-----Original Message-----
>From: sputnikkk [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]]
>Sent: Friday, June 28, 2002 8:40 PM
>To: [EMAIL PROTECTED]
>Subject: Re: MX Books
>
>Robi Sen has a new one out on Amazon has CF MX in the title
>----- Original Message -----
>From: "Tangorre, Michael" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, June 28, 2002 11:26 AM
>Subject: MX Books
>
>What are the recommended CF MX books?
>
>Michael Tangorre
>
>MillenniuM Information Systems
>1101 Wilson Blvd, Suite 1200
>Arlington, Virginia 22209
>(703) 341-1438
>
>================================
>This email contains MillenniuM Information
>Systems, LLC. privileged information.
>================================
>
>
>
>
>
>AVIS IMPORTANT:
>-------------------------------
>Les informations contenues dans le present document et ses pieces jointes
>sont strictement confidentielles et reservees a l'usage de la (des)
>personne(s) a qui il est adresse. Si vous n'etes pas le destinataire,
>soyez avise que toute divulgation, distribution, copie, ou autre
>utilisation de ces informations est strictement prohibee. Si vous avez
>recu ce document par erreur, veuillez s'il vous plait communiquer
>immediatement avec l'expediteur et detruire ce document sans en faire de
>copie sous quelque forme.
>
>WARNING:
>-------------------------------
>The information contained in this document and attachments is confidential
>and intended only for the person(s) named above. If you are not the
>intended recipient you are hereby notified that any disclosure, copying,
>distribution, or any other use of the information is strictly prohibited.
>If you have received this document by mistake, please notify the sender
>immediately and destroy this document and attachments without making any
>copy of any kind.
>
>
end
***********************************************************
You can have it good
You can have it cheap
You can have it quick
Pick two
- Sign in a studio I worked in once.
***********************************************************
Michael "Maxx" Porter
Advanced Macromedia ColdFusion 5.0 Certified Developer
mailto:[EMAIL PROTECTED]
--=====================_1363400==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<br>
Inside Coldfusion MX<br>
<font face="verdana">by
</font><font face="verdana" color="#0000FF"><u>John
Cummings</u></font><font face="verdana">,
</font><font face="verdana" color="#0000FF"><u>Neil Ross<br><br>
</u></font><a
href="http://www.amazon.com/exec/obidos/ASIN/0735713049/qid=1025582753/sr=1-2/ref=sr_1_2/002-4690897-7687228";
eudora="autourl">http://www.amazon.com/exec/obidos/ASIN/0735713049/qid=1025582753/sr=1-2/ref=sr_1_2/002-4690897-7687228</a><br><br>
<br>
Robi Sen<br>
At 01:01 AM 6/29/2002, you wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">I
couldn't find that book....do you know the ISBN or full
title?</font><br>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> Stacy Young
[<a href="mailto:[EMAIL PROTECTED]";
eudora="autourl">mailto:[EMAIL PROTECTED]</a>]
<dd>Sent:</b> Friday, June 28, 2002 10:11 PM
<dd>To:</b> '[EMAIL PROTECTED]'
<dd>Subject:</b> RE: MX Books<br><br>
</font><font size=2>
<dd>Lemme tell u that man knows his stuff !!</font> <br><br>
<font size=2>
<dd>-----Original Message-----</font> <font size=2>
<dd>From: sputnikkk
[<a href="mailto:[EMAIL PROTECTED]";>mailto:[EMAIL PROTECTED]</a>]
</font><font size=2>
<dd>Sent: Friday, June 28, 2002 8:40 PM</font> <font size=2>
<dd>To: [EMAIL PROTECTED]</font> <font size=2>
<dd>Subject: Re: MX Books</font> <br><br>
<font size=2>
<dd>Robi Sen has a new one out on Amazon has CF MX in the
title</font> <font size=2>
<dd>----- Original Message ----- </font><font size=2>
<dd>From: "Tangorre, Michael"
<[EMAIL PROTECTED]></font> <font size=2>
<dd>To: <[EMAIL PROTECTED]></font> <font size=2>
<dd>Sent: Friday, June 28, 2002 11:26 AM</font> <font size=2>
<dd>Subject: MX Books</font> <br><br>
<font size=2>
<dd>What are the recommended CF MX books?</font> <br><br>
<font size=2>
<dd>Michael Tangorre</font> <br><br>
<font size=2>
<dd>MillenniuM Information Systems</font> <font size=2>
<dd>1101 Wilson Blvd, Suite 1200</font> <font size=2>
<dd>Arlington, Virginia 22209</font> <font size=2>
<dd>(703) 341-1438</font> <br><br>
<font size=2>
<dd>================================</font> <font size=2>
<dd>This email contains MillenniuM Information </font><font size=2>
<dd>Systems, LLC. privileged information.</font> <font size=2>
<dd>================================</font> <br><br>
<br><br>
<br><br>
<dd>AVIS IMPORTANT:
<dd>-------------------------------
<dd>Les informations contenues dans le present document et ses pieces
jointes sont strictement confidentielles et reservees a l'usage de la
(des) personne(s) a qui il est adresse. Si vous n'etes pas le
destinataire, soyez avise que toute divulgation, distribution, copie, ou
autre utilisation de ces informations est strictement prohibee. Si vous
avez recu ce document par erreur, veuillez s'il vous plait communiquer
immediatement avec l'expediteur et detruire ce document sans en faire de
copie sous quelque forme.<br><br>
<dd>WARNING:
<dd>-------------------------------
<dd>The information contained in this document and attachments is
confidential and intended only for the person(s) named above. If you are
not the intended recipient you are hereby notified that any disclosure,
copying, distribution, or any other use of the information is strictly
prohibited. If you have received this document by mistake, please notify
the sender immediately and destroy this document and attachments without
making any copy of any kind.<br><br>
</dl><br>
</blockquote>
<x-sigsep><p></x-sigsep>
<br>
end<br>
***********************************************************<br>
You can have it good<br>
You can have it cheap<br>
You can have it quick<br>
Pick two<br><br>
- Sign in a studio I worked in once.<br>
***********************************************************<br>
Michael "Maxx" Porter<br>
Advanced Macromedia ColdFusion 5.0 Certified Developer<br><br>
<a href="mailto:[EMAIL PROTECTED]"; eudora="autourl">mailto:[EMAIL PROTECTED]<br>
</a>
</html>
--=====================_1363400==_.ALT--
------------------------------
Date: Tue, 02 Jul 2002 16:48:23 +0900
From: =?ISO-8859-1?Q?Ney_Andr=E9_de_Mello_Zunino?= <[EMAIL PROTECTED]>
Subject: <cf_reuseform>'s datasource attribute?
Hello.
The example in the .txt file that accompanies the <cf_reuseform> custom
tag includes a "datasource" attribute in the call. I have checked the
tag's code and such attribute is not used. Was it supposed to be there
in the example code or was it just a mistake?
Thank you,
--
Ney Andr� de Mello Zunino
Media and Technology Laboratory
Campus Computing Centre
United Nations University
------------------------------
End of [EMAIL PROTECTED] digest, issue 846
