-- Topica Digest --
RE: paths in fb3
By [EMAIL PROTECTED]
RE: First Impressions of ColdFusion MX
By [EMAIL PROTECTED]
How to Build Components in Java?
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
FYI - Adalon talk at MDCFUG
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
RE: paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
Re: RE: paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
RE: paths in fb3
By [EMAIL PROTECTED]
RE: paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
RE: paths getting multiple cfid/cftokens
By [EMAIL PROTECTED]
SES - Removing index.cfm & Fuseaction?
By [EMAIL PROTECTED]
RE: SES - Removing index.cfm & Fuseaction?
By [EMAIL PROTECTED]
RE: SES - Removing index.cfm & Fuseaction?
By [EMAIL PROTECTED]
By [EMAIL PROTECTED]
------------------------------------------------------------
Date: Tue, 8 Oct 2002 07:32:25 -0400
From: "Patrick McElhaney" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
> Barney wrote:
>
> I've been using two UDFs since CFMX came out.
> runFuse("[circuit.]fuse") and
> runFuseaction("[circuit.]fuseaction"). They are
> a hard and fast way to get functionality across
> FB's internal separators.
>
> runfuse simple does an include on the right file,
> after computing the
> relative path from the fusebox struct.
>
> runfuseaction is really dirty. It includes the
> appropriate fbx_Switch file.
> It doesn't provide a complete fusebox struct for
> that circuit, it only provides fusebox.fuseaction.
Ouch! What's the point of using the framework if you're
going to circumvent it like that? IMHO, you would be better
off creating a BarneyBox that maps circuit aliases to
directories, and allows you to include a function
runFile([circuit.]fileNameMinusExtension). Then again, that
just mimics part of the functionality of CFCs, so you might
as well not use any framework and write all of your code in
CFCs.
Patrick
------------------------------
Date: Tue, 08 Oct 2002 08:14:39 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: RE: First Impressions of ColdFusion MX
Don't you just love dueling metaphor and illustrations?
>>> [EMAIL PROTECTED] 10/07/02 04:30PM >>>
Oh no! Not a metaphor! :)
------------------------------
Date: Tue, 08 Oct 2002 08:30:20 -0400
From: "John Farrar" <[EMAIL PROTECTED]>
Subject: How to Build Components in Java?
How about a few pointers and examples here. These are some of my concerns...
1. Can they run or be installed on shared hosting services? (Like Intermedia or
HostMyWebSite?)
2. What is the right way to build them?
3. Examples?
4. Community Support... nothing like 9/10ths of a cool project dead in the water over
something simple you can't quite see!
5. Will it run on all versions of MX?
6. What about data access... will it be easy to share the component with others who
use other databases?
7. What about bugs and needed modifications.
NOTE: Many of these issues are easier to deal with because CF code is easier to debug
and modify. If Java is a better tool, is it a better tool for the broader community?
------------------------------
Date: Tue, 8 Oct 2002 08:31:51 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
I'm never used it, but does FuseQ not supply very similar functionality?
Not to imply that FuseQ is a better solution that vanilla FuseBox, just a
different one.
However, I view FuseBox as a way to struture your application code, and from
that structure allow for some nice layout perks. I also see it as a way to
keep code segregated into groups that make sense, while still allowing that
code to be accessed from other locations.
Pure FB takes care of the first very well. My UDFs take care of the second.
The first is of primary concern, but the second makes some things a lot
easier. The two goals are not mutually exclusive, they can work very well
together, assuming you don't let the UDFs overpower the framework, which can
be easy to do. However, if you were to look at some of my app code, you
would see a vastly pure FB app with a few instances of circumventing the
framework that could easily be switched to CFMODULE calls to slow it down.
In the app i'm currently working on, I've got about 60 cirucits, ranging
from 10 to 30 fuseactions a piece, and in there I have about 10 runFuses
(many in the security circuits), and 4 or 5 runFuseactions, mostly for
taking multiple display fuseactions and turning them into a combined display
fuseaction. So, as you can see, the UDFs hardly dictate my app flow, they
just address a very specific need that happens quite rarely.
As I said in the paragraph after you stopped copying, this is significantly
more efficient that a bunch of CFMODULE calls, yet does exactly the same
thing. I certainly don't forsee anyone suddenly saying "Hey, I want those
functions", and even if someone did, I wouldn't give out the code, for the
simple reason that if you want to circumvent the system, you better know why
you need to well enough to write the hack yourself.
In a lot of ways the purpose of the UDFs was to increase the OO-like aspects
of a fusebox app, just as you said. Now my circuits are very much like
objects, and I can call "methods" of any circuit from anywhere else in the
app. But most of the time, the procedural version of CF is perfectly
adequate for elegantly expressing in code the functionality I need. Making
it all CFC-based would be more work, probably result in less readble code,
and certainly would make maintenance more difficut, which is why I haven't
gone that route. What I have done is let myself have the best of both
worlds, and let me choose freely between them for individual actions,
without changing any code or it's organization.
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 4:32 AM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
> Barney wrote:
>
> I've been using two UDFs since CFMX came out.
> runFuse("[circuit.]fuse") and
> runFuseaction("[circuit.]fuseaction"). They are
> a hard and fast way to get functionality across
> FB's internal separators.
>
> runfuse simple does an include on the right file,
> after computing the
> relative path from the fusebox struct.
>
> runfuseaction is really dirty. It includes the
> appropriate fbx_Switch file.
> It doesn't provide a complete fusebox struct for
> that circuit, it only provides fusebox.fuseaction.
Ouch! What's the point of using the framework if you're
going to circumvent it like that? IMHO, you would be better
off creating a BarneyBox that maps circuit aliases to
directories, and allows you to include a function
runFile([circuit.]fileNameMinusExtension). Then again, that
just mimics part of the functionality of CFCs, so you might
as well not use any framework and write all of your code in
CFCs.
Patrick
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 08 Oct 2002 11:53:27 -0400
From: "Douglas Smith" <[EMAIL PROTECTED]>
Subject: FYI - Adalon talk at MDCFUG
For those people interested in exploring Adalon to architect your Fusebox
apps, and who happen to be in the Washington, DC area, there will be a talk
at the MDCFUG this evening.
For more info: http://www.cfug-md.org/
"Adalon ColdFusion Architecting"
by Wells Burke
With so much emphasis put on technologies like object modeling and UML for
rigorous software modeling, Cold Fusion programmers are often left on their
own
to create design and documentation standards.
Adalon from Synthis Corporation is a visual Web application modeling and
design
tool that helps fill this void for Cold Fusion developers. With Adalon CF
developers can create rigorous functional designs, maintain always up to date
documentation, and automatically generate complete code skeletons for a
smoother and faster transition from design into development. For teams that
don't have set development standards,Adalon can help bring a method to your
ColdFusion madness. For teams that do have their own standards or use
documented standards like Fusebox or Java Struts, Adalon can help you achieve
new levels of productivity. This presentation will be beneficial for everyone
from project managers to the most experienced Cold Fusion developer.
Wells Burke serves as CEO of Synthis Corporation which is an Atlanta GA
company
that makes analysis tools.. Wells is a technology innovator and the visionary
behind Synthis' product offerings. His experience in architecting large-scale
Internet software solutions is the backbone of Synthis' technology development
efforts. He began building eBusiness solutions at IBM, and as part of IBM's
Multimedia and eBusiness divisions, Wells worked as a software
architect,supporting some of the company's largest eBusiness initiatives.
================================================
Douglas M. Smith - Application Architect
TeraTech - Tools for Programmers(tm) - www.TeraTech.com
[EMAIL PROTECTED], ICQ: 41044319
================================================
------------------------------
Date: Tue, 8 Oct 2002 12:44:35 -0400
From: "Patrick McElhaney" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
> Barney wrote:
>
> I'm never used it, but does FuseQ not supply very
> similar functionality?
Yes. That's why I don't like FuseQ.
> In the app i'm currently working on, I've got
> about 60 cirucits, ranging from 10 to 30
> fuseactions a piece, and in there I have about
> 10 runFuses (many in the security circuits), and
> 4 or 5 runFuseactions, mostly for taking multiple
> display fuseactions and turning them into a
> combined display fuseaction.
To me, that's a reason to not use those functions. You're
not getting much mileage out of them. You've increased the
complexity of the framework significantly to accommodate a
very small part of the app.
> As I said in the paragraph after you stopped
> copying, this is significantly more efficient
> that a bunch of CFMODULE calls, yet does exactly
> the same thing.
It doesn't do exactly the same thing. You said so yourself.
You're not supplying the full fusebox API. You're not going
through the core file and thus including all of the
fbx_settings files before the fuseaction. And the fuseaction
isn't running in its own memory space.
> ... if you want to circumvent the system, you
> better know why you need to well enough to write
> the hack yourself.
Good point. What about the next person responsible for
maintaining the app? How do you ensure that he understands
why you needed to write the hack?
> In a lot of ways the purpose of the UDFs was to
> increase the OO-like aspects of a fusebox app, just
> as you said.
Fusebox doesn't have any OO-like aspects.
Patrick
------------------------------
Date: Tue, 8 Oct 2002 11:17:35 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
>
> > Barney wrote:
> >
> > I'm never used it, but does FuseQ not supply very
> > similar functionality?
> Yes. That's why I don't like FuseQ.
Hey, something we agree on. I know I wouldn't want to build a whole
application this way. It just doesn't make sense for most situations. It
was kind of interesting after I wrote the functions, I had an epiphany that
FuseQ must be pretty much the same functions as I have. I almost scrapped
them then and there. But they provided such a nice tool for certain
situations that I couldn't leave them behind.
> > In the app i'm currently working on, I've got
> > about 60 cirucits, ranging from 10 to 30
> > fuseactions a piece, and in there I have about
> > 10 runFuses (many in the security circuits), and
> > 4 or 5 runFuseactions, mostly for taking multiple
> > display fuseactions and turning them into a
> > combined display fuseaction.
> To me, that's a reason to not use those functions. You're
> not getting much mileage out of them. You've increased the
> complexity of the framework significantly to accommodate a
> very small part of the app.
I haven't touched the framework at all. The framework doesn't know that I'm
using the functions. I created them to fulfill a very specific need, which
they do admriably, and nothing more.
Let say you create a tag-based UDF that reads a file (passed as an
argument), runs xmlParse() and returns the XML object.
I say, "that's great, but it should be in a fuseaction somewhere (probably a
library circuit), and you should use CFMODULE to call it. That way you can
reference it any time, without worrying about having to include the right
function library"
"But that's expensive," you say.
"Hey, I have this great function that'll run stand-alone fuseactions really
fast."
If you set up the functionality as a UDF, you have to make sure you include
the library whenever you use it. This makes the application's functionality
have two different organizations, circuits/fuseactions/fuses, and functions.
If you set up a fuseaction, then you can call the fuseaction across the
fusebox at any time, as long as the right circuit is present, just like any
other piece of functionality. runFuseaction just makes it faster. Note
that I picked a task that has no dependance on environment, it's a
stand-alone action. If you're looking at something dependant on
environment, then runFuseaction isn't going to help you, and CFMODULE will
be your only solution.
> > As I said in the paragraph after you stopped
> > copying, this is significantly more efficient
> > that a bunch of CFMODULE calls, yet does exactly
> > the same thing.
> It doesn't do exactly the same thing. You said so yourself.
> You're not supplying the full fusebox API. You're not going
> through the core file and thus including all of the
> fbx_settings files before the fuseaction. And the fuseaction
> isn't running in its own memory space.
I should have qualified that sentance by adding "for the purpose at hand" to
the end of it. My bad.
> > ... if you want to circumvent the system, you
> > better know why you need to well enough to write
> > the hack yourself.
> Good point. What about the next person responsible for
> maintaining the app? How do you ensure that he understands
> why you needed to write the hack?
I don't know that I could replicate FuseQ, and I bet that most people who
use it couldn't either. There is a distinct difference between WRITING a
hack and USING a hack. Encapsulation is one of the most powerful concepts
in programming, and this is a perfect example. It is the job of the
encapuslator (hacker) to make the encapsulation appropriate and easy to use.
People don't have to know how or why it was done, just how to use it. Take
this code as an example from a fbx_Switch file (for a timecard circuit):
<cfcase value="home,fusebox.defaultfuseaction">
<cfset runFuseaction("clock") />
<h3>Today's Log</h3>
<cfset runFuseaction("dailylog") />
</cfcase>
<cfcase value="clock">
<cfinclude template="qry_getcurrentlog.cfm" />
<cfif getcurrentlog.recordcount>
<cfset runFuseaction("clockout") />
<cfelse>
<cfset runFuseaction("clockin") />
</cfif>
</cfcase>
<cfcase value="clockin">
<cfset xfa.submit = fusebox.targetcircuit & ".recordclockin" />
<cfinclude template="frm_clockin.cfm" />
</cfcase>
<cfcase value="clockout">
<cfset xfa.submit = fusebox.targetcircuit & ".recordclockout" />
<cfset xfa.delete = fusebox.targetcircuit & ".delete" />
<cfinclude template="qry_getprojects.cfm" />
<cfinclude template="qry_getrecentprojects.cfm" />
<cfinclude template="qry_getcurrentlog.cfm" />
<cfinclude template="qry_getlastlog.cfm" />
<cfinclude template="frm_clockout.cfm" />
</cfcase>
<cfcase value="dailylog">
<cfset xfa.delete = fusebox.targetcircuit & ".delete" />
<cfset attributes.startdate =
createDate(year(now()), month(now()), day(now())) />
<cfset attributes.enddate =
dateAdd("s", -1, dateAdd("h", 24, attributes.startdate)) />
<cfinclude template="qry_getlogs.cfm" />
<cfinclude template="qry_getcurrentlog.cfm" />
<cfinclude template="qry_getweeklytotal.cfm" />
<cfinclude template="dsp_dailylog.cfm" />
</cfcase>
Compare the first CFCASE to this code, and I think you'll agree that my
version is significantly cleaner and easier to read.
<cfcase value="home,fusebox.defaultfuseaction">
<cfmodule template="#fusebox.rootpath##self#"
fuseaction="#fusebox.targetcircuit#.clock"
suppresslayouts="True" />
<h3>Today's Log</h3>
<cfmodule template="#fusebox.rootpath##self#"
fuseaction="#fusebox.targetcircuit#.dailylog
suppresslayouts="True" />
</cfcase>
Also of note is that the runFuseaction() calls are all within the same
circuit so it already has all the needed settings and such, because the
"parent request" is in the same circuit, so the API variables will be
identical in the "child request".
In my expiernce, API variables are useful for doing output (making XFAs,
selecting layout files, etc). When I use runFuseaction for display, it's
always within the same circuit, so I'm safe there. If I want to go
cross-circuit, I still use CFMODULE and suppress my layouts.
> > In a lot of ways the purpose of the UDFs was to
> > increase the OO-like aspects of a fusebox app, just
> > as you said.
> Fusebox doesn't have any OO-like aspects.
That's a matter of opinion that I don't even want to get into. I stand by
my statment (note the "-like" in there), but I will ammend it by saying that
I certainly agree that the FuseBox framework is not object oriented in any
way.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 8 Oct 2002 14:35:52 -0400
From: <[EMAIL PROTECTED]>
Subject: paths getting multiple cfid/cftokens
I'm getting url's like this, but only in certain parts of my app:
"http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/26214052/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.ShippingAddress";
Most of the places it's fine, this seems to be the only one that is causing the
problem. I am using ses convertor, but I do have the proper basehref in the header.
I do have a few(well, quite a few) recursive cfmodule calls, but use
#fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as attributes for
those.
Any ideas of where to look?
------------------------------
Date: Tue, 8 Oct 2002 11:57:46 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths getting multiple cfid/cftokens
it looks like you're assembling a URL recusively, adding one piece at a
time. If I wanted to build the string "eatAtJoes", I would do this:
string = "eat" & "At" & "Joes";
>From your URL , it looks like you're building it like this:
string = "eat" & "eatAt" & "eatAtJoes";
where "eat" represents "/index.cfm/cfid/10/cftoken", "at" represents
"/26214052/fuseaction" and "joes" represents "/checkout.ShippingAddress".
if you tack them together with the two mechanisms i listed, you'll get the
URL you want and then URL you're getting.
That should help you see WHAT's happening, which should help you figure out
WHERE and HOW it's happening. I'm guessing you're doing this somewhere in
your code, which the recursive calls are causing to behave strangely:
<cfset modself = modself & "more_stuff" />
cheers,
barneyb
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 11:36 AM
To: [EMAIL PROTECTED]
Subject: paths getting multiple cfid/cftokens
I'm getting url's like this, but only in certain parts of my app:
"http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/262140
52/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.Shippin
gAddress"
Most of the places it's fine, this seems to be the only one that is causing
the problem. I am using ses convertor, but I do have the proper basehref in
the header.
I do have a few(well, quite a few) recursive cfmodule calls, but use
#fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as
attributes for those.
Any ideas of where to look?
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 8 Oct 2002 15:05:52 -0400
From: <[EMAIL PROTECTED]>
Subject: Re: RE: paths getting multiple cfid/cftokens
(root fbx_settings)
<cfset self="index.cfm">
<cfset modself = self>
<cfif isDefined("url.fakeCgiServerName") and not findNoCase("/fakeCgiServerName/",
self, 1)>
<cfset self = self & "/fakeCgiServerName/#attributes.fakeCgiServerName#">
</cfif>
<cfif ListLen(GetClientVariablesList()) and not find( "cfid", self )>
<cfset self = self & "/cfid/#cfid#">
</cfif>
<cfif ListLen(GetClientVariablesList()) and not find( "cftoken", self )>
<cfset self = self & "/cftoken/#cftoken#">
</cfif>
The last two looking for cfid and cftoken were an attempt to fix this, but are not
helping. They shouldn't be doing anything anyway, as self is re-set back to just
"index.cfm" just before. So the problem is happening down the line within the app
somewhere.
I had this problem awhile back because I had the first line setting self as a cfparam
instead of a cfset. I thought the change had fixed this, but apparently not.
I have been doing #fusebox.rootpath##modself# for cfmodule calls, and
#fusebox.rootpath##self# for cflocations and form actions.
>
> From: Barney Boisvert <[EMAIL PROTECTED]>
> Date: 2002/10/08 Tue PM 02:57:46 EDT
> To: [EMAIL PROTECTED]
> Subject: RE: paths getting multiple cfid/cftokens
>
> it looks like you're assembling a URL recusively, adding one piece at a
> time. If I wanted to build the string "eatAtJoes", I would do this:
>
> string = "eat" & "At" & "Joes";
>
> From your URL , it looks like you're building it like this:
>
> string = "eat" & "eatAt" & "eatAtJoes";
>
> where "eat" represents "/index.cfm/cfid/10/cftoken", "at" represents
> "/26214052/fuseaction" and "joes" represents "/checkout.ShippingAddress".
>
> if you tack them together with the two mechanisms i listed, you'll get the
> URL you want and then URL you're getting.
>
> That should help you see WHAT's happening, which should help you figure out
> WHERE and HOW it's happening. I'm guessing you're doing this somewhere in
> your code, which the recursive calls are causing to behave strangely:
>
> <cfset modself = modself & "more_stuff" />
>
> cheers,
> barneyb
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 11:36 AM
> To: [EMAIL PROTECTED]
> Subject: paths getting multiple cfid/cftokens
>
>
> I'm getting url's like this, but only in certain parts of my app:
>
> "http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/262140
> 52/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.Shippin
> gAddress"
>
> Most of the places it's fine, this seems to be the only one that is causing
> the problem. I am using ses convertor, but I do have the proper basehref in
> the header.
>
> I do have a few(well, quite a few) recursive cfmodule calls, but use
> #fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as
> attributes for those.
> Any ideas of where to look?
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
------------------------------
Date: Tue, 8 Oct 2002 15:08:49 -0400
From: "Patrick McElhaney" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
> Barney wrote:
>
> Let say you create a tag-based UDF that reads a
> file (passed as an argument), runs xmlParse()
> and returns the XML object.
Sure. Functions work one way and fuseactions work another
way. When fuseactions work kind of like functions (but only
sometimes) I get concerned.
> I don't know that I could replicate FuseQ, and I
> bet that most people who use it couldn't either.
> There is a distinct difference between WRITING a
> hack and USING a hack.
I thought you just said the opposite, that a person who
doesn't know enough to write the hack himself shouldn't be
using it?
> People don't have to know how or why it was done,
> just how to use it.
Okay, I don't think the average Fuseboxer would know that
your UDFs shouldn't be used for a fuseaction that depends on
its environment.
> Take this code as an example from a fbx_Switch file
> (for a timecard circuit):
>
> Compare the first CFCASE to this code, and I
> think you'll agree that my version is
> significantly cleaner and easier to read.
I actually wrote a custom tag that literally encapsulates
the <cfmodule> call so that it looks cleaner. I didn't
change the way the fuseaction is called; I just hid away the
details that are always the same.
<cfcase value="home,fusebox.defaultfuseaction">
<cf_call fuseaction="clock"/>
<h3>Today's Log</h3>
<cf_call fuseaction="dailylog"/>
</cfcase>
Patrick
------------------------------
Date: Tue, 8 Oct 2002 15:39:52 -0400
From: <[EMAIL PROTECTED]>
Subject: RE: paths getting multiple cfid/cftokens
OK, it seems I've isolated it a bit better. The culprit seems to be a cflocation.
<cfcase value="updateQuantities">
<cfinclude template="act_updateQuantities.cfm">
<cflocation url="#self#/fuseaction/#fusebox.thisCircuit#.start" addtoken="No">
</cfcase>
act_updateQuantities just manipulates some client variables.
For the following values for the url attribute of cflocation, this is where the page
ends up:
cflocation url value:
#self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/26214052/fuseaction/YourShoppingCart.start
cflocation url value:
#fusebox.rootpath##self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/index.cfm/cfid/10/cftoken/26214052/fuseaction/YourShoppingCart.start
cflocation url value:
/#self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/10/cftoken/26214052/fuseaction/YourShoppingCart.start
So the last works, but what happens when the entire app lives in a subdirectory?
What is the proper value to use for self in cflocation when using ses urls? Do I have
to hard code the "/" before each cflocation, or should self always have a "/" in front
of it throughtout the app?
>
> From: Barney Boisvert <[EMAIL PROTECTED]>
> Date: 2002/10/08 Tue PM 02:57:46 EDT
> To: [EMAIL PROTECTED]
> Subject: RE: paths getting multiple cfid/cftokens
>
> it looks like you're assembling a URL recusively, adding one piece at a
> time. If I wanted to build the string "eatAtJoes", I would do this:
>
> string = "eat" & "At" & "Joes";
>
> From your URL , it looks like you're building it like this:
>
> string = "eat" & "eatAt" & "eatAtJoes";
>
> where "eat" represents "/index.cfm/cfid/10/cftoken", "at" represents
> "/26214052/fuseaction" and "joes" represents "/checkout.ShippingAddress".
>
> if you tack them together with the two mechanisms i listed, you'll get the
> URL you want and then URL you're getting.
>
> That should help you see WHAT's happening, which should help you figure out
> WHERE and HOW it's happening. I'm guessing you're doing this somewhere in
> your code, which the recursive calls are causing to behave strangely:
>
> <cfset modself = modself & "more_stuff" />
>
> cheers,
> barneyb
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 11:36 AM
> To: [EMAIL PROTECTED]
> Subject: paths getting multiple cfid/cftokens
>
>
> I'm getting url's like this, but only in certain parts of my app:
>
> "http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/262140
> 52/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.Shippin
> gAddress"
>
> Most of the places it's fine, this seems to be the only one that is causing
> the problem. I am using ses convertor, but I do have the proper basehref in
> the header.
>
> I do have a few(well, quite a few) recursive cfmodule calls, but use
> #fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as
> attributes for those.
> Any ideas of where to look?
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
------------------------------
Date: Tue, 8 Oct 2002 13:38:25 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths in fb3
Fuseactions = functions. That's exactly what they are. it takes a set of
parameters and returns a result (attributes scope and HTML output). Usually
a page is generated by a call to a single function, but there's no reason
that a function can't call another function.
My 'hacks' are exactly that, but the end user doesn't know that they are
hacks. They might be perfectly legit, and they are within certain
situations. If the call references the same circuit as the 'main' request,
all environment is as it should be, just like a CFMODULE call. If people
want to run another fuseaction as part of a fuseaction, here's a perfect
solution, and it's faster than using a CFMODULE. Now if you use
runFuseaction across your circuit hierarchy, then you'd better know what
you're doing. But the functions that I've exposed don't allow you to. If
you want to know how the functions work, I'm not telling you, but I'll let
you use them. If you want to modify their behaviour, you have to start from
square one.
Your custom tag exposes the same interface (basically) as runFuseaction(),
but it's not just a CFMODULE, it's also got a custom tag call in there, so
it'll be doubly slow, and effeciency was the whole premise behind the
functions to begin with.
Anyway, I think the bottom line here is that FB will let you do what I want,
but slowly, and I'm willing to trade a little correctness for a bunch of
speed. I have the distinct feeling that in not too long the whole debate
will be moot, because we'll have a better internal system that'll let us
execute cross-circuit code without needing a whole new request to the
fusebox.
barneyb
-----Original Message-----
From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 12:09 PM
To: [EMAIL PROTECTED]
Subject: RE: paths in fb3
> Barney wrote:
>
> Let say you create a tag-based UDF that reads a
> file (passed as an argument), runs xmlParse()
> and returns the XML object.
Sure. Functions work one way and fuseactions work another
way. When fuseactions work kind of like functions (but only
sometimes) I get concerned.
> I don't know that I could replicate FuseQ, and I
> bet that most people who use it couldn't either.
> There is a distinct difference between WRITING a
> hack and USING a hack.
I thought you just said the opposite, that a person who
doesn't know enough to write the hack himself shouldn't be
using it?
> People don't have to know how or why it was done,
> just how to use it.
Okay, I don't think the average Fuseboxer would know that
your UDFs shouldn't be used for a fuseaction that depends on
its environment.
> Take this code as an example from a fbx_Switch file
> (for a timecard circuit):
>
> Compare the first CFCASE to this code, and I
> think you'll agree that my version is
> significantly cleaner and easier to read.
I actually wrote a custom tag that literally encapsulates
the <cfmodule> call so that it looks cleaner. I didn't
change the way the fuseaction is called; I just hid away the
details that are always the same.
<cfcase value="home,fusebox.defaultfuseaction">
<cf_call fuseaction="clock"/>
<h3>Today's Log</h3>
<cf_call fuseaction="dailylog"/>
</cfcase>
Patrick
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 8 Oct 2002 13:38:26 -0700
From: "Barney Boisvert" <[EMAIL PROTECTED]>
Subject: RE: paths getting multiple cfid/cftokens
This is happening because CFLOCATION doesn't get to see the <BASE> tag in
your HTML for computing the relative path to the new page. Try setting
'self' to be #cgi.script_name#, rather than 'index.cfm', that way it'll
always start with a slash, and have the full path to the right filename (for
if you're in a sub directory).
barneyb
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 08, 2002 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: paths getting multiple cfid/cftokens
OK, it seems I've isolated it a bit better. The culprit seems to be a
cflocation.
<cfcase value="updateQuantities">
<cfinclude template="act_updateQuantities.cfm">
<cflocation url="#self#/fuseaction/#fusebox.thisCircuit#.start"
addtoken="No">
</cfcase>
act_updateQuantities just manipulates some client variables.
For the following values for the url attribute of cflocation, this is where
the page ends up:
cflocation url value:
#self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/2621405
2/fuseaction/YourShoppingCart.start
cflocation url value:
#fusebox.rootpath##self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/index.cfm/cfid/10/cftoken/26214052/fuseactio
n/YourShoppingCart.start
cflocation url value:
/#self#/fuseaction/#fusebox.thisCircuit#.start
browser shows:
http://127.0.0.1/index.cfm/cfid/10/cftoken/26214052/fuseaction/YourShoppingC
art.start
So the last works, but what happens when the entire app lives in a
subdirectory?
What is the proper value to use for self in cflocation when using ses urls?
Do I have to hard code the "/" before each cflocation, or should self always
have a "/" in front of it throughtout the app?
>
> From: Barney Boisvert <[EMAIL PROTECTED]>
> Date: 2002/10/08 Tue PM 02:57:46 EDT
> To: [EMAIL PROTECTED]
> Subject: RE: paths getting multiple cfid/cftokens
>
> it looks like you're assembling a URL recusively, adding one piece at a
> time. If I wanted to build the string "eatAtJoes", I would do this:
>
> string = "eat" & "At" & "Joes";
>
> From your URL , it looks like you're building it like this:
>
> string = "eat" & "eatAt" & "eatAtJoes";
>
> where "eat" represents "/index.cfm/cfid/10/cftoken", "at" represents
> "/26214052/fuseaction" and "joes" represents "/checkout.ShippingAddress".
>
> if you tack them together with the two mechanisms i listed, you'll get the
> URL you want and then URL you're getting.
>
> That should help you see WHAT's happening, which should help you figure
out
> WHERE and HOW it's happening. I'm guessing you're doing this somewhere in
> your code, which the recursive calls are causing to behave strangely:
>
> <cfset modself = modself & "more_stuff" />
>
> cheers,
> barneyb
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 11:36 AM
> To: [EMAIL PROTECTED]
> Subject: paths getting multiple cfid/cftokens
>
>
> I'm getting url's like this, but only in certain parts of my app:
>
>
"http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/262140
>
52/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.Shippin
> gAddress"
>
> Most of the places it's fine, this seems to be the only one that is
causing
> the problem. I am using ses convertor, but I do have the proper basehref
in
> the header.
>
> I do have a few(well, quite a few) recursive cfmodule calls, but use
> #fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as
> attributes for those.
> Any ideas of where to look?
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
------------------------------
Date: Tue, 8 Oct 2002 16:47:54 -0400
From: <[EMAIL PROTECTED]>
Subject: RE: paths getting multiple cfid/cftokens
Hey, nice call. I was just going to hardcode it in the root fbx_settings as
"/index.cfm". If I had to move the app down a directory, it would only be a one spot
change, but your way saves me even that step.
Thanks to all for the help.
>
> From: Barney Boisvert <[EMAIL PROTECTED]>
> Date: 2002/10/08 Tue PM 04:38:26 EDT
> To: [EMAIL PROTECTED]
> Subject: RE: paths getting multiple cfid/cftokens
>
> This is happening because CFLOCATION doesn't get to see the <BASE> tag in
> your HTML for computing the relative path to the new page. Try setting
> 'self' to be #cgi.script_name#, rather than 'index.cfm', that way it'll
> always start with a slash, and have the full path to the right filename (for
> if you're in a sub directory).
>
> barneyb
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 12:40 PM
> To: [EMAIL PROTECTED]
> Subject: RE: paths getting multiple cfid/cftokens
>
>
> OK, it seems I've isolated it a bit better. The culprit seems to be a
> cflocation.
>
> <cfcase value="updateQuantities">
> <cfinclude template="act_updateQuantities.cfm">
> <cflocation url="#self#/fuseaction/#fusebox.thisCircuit#.start"
> addtoken="No">
> </cfcase>
>
> act_updateQuantities just manipulates some client variables.
>
> For the following values for the url attribute of cflocation, this is where
> the page ends up:
>
> cflocation url value:
> #self#/fuseaction/#fusebox.thisCircuit#.start
> browser shows:
> http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/2621405
> 2/fuseaction/YourShoppingCart.start
>
> cflocation url value:
> #fusebox.rootpath##self#/fuseaction/#fusebox.thisCircuit#.start
> browser shows:
> http://127.0.0.1/index.cfm/cfid/index.cfm/cfid/10/cftoken/26214052/fuseactio
> n/YourShoppingCart.start
>
> cflocation url value:
> /#self#/fuseaction/#fusebox.thisCircuit#.start
> browser shows:
> http://127.0.0.1/index.cfm/cfid/10/cftoken/26214052/fuseaction/YourShoppingC
> art.start
>
> So the last works, but what happens when the entire app lives in a
> subdirectory?
>
> What is the proper value to use for self in cflocation when using ses urls?
> Do I have to hard code the "/" before each cflocation, or should self always
> have a "/" in front of it throughtout the app?
>
>
>
> >
> > From: Barney Boisvert <[EMAIL PROTECTED]>
> > Date: 2002/10/08 Tue PM 02:57:46 EDT
> > To: [EMAIL PROTECTED]
> > Subject: RE: paths getting multiple cfid/cftokens
> >
> > it looks like you're assembling a URL recusively, adding one piece at a
> > time. If I wanted to build the string "eatAtJoes", I would do this:
> >
> > string = "eat" & "At" & "Joes";
> >
> > From your URL , it looks like you're building it like this:
> >
> > string = "eat" & "eatAt" & "eatAtJoes";
> >
> > where "eat" represents "/index.cfm/cfid/10/cftoken", "at" represents
> > "/26214052/fuseaction" and "joes" represents "/checkout.ShippingAddress".
> >
> > if you tack them together with the two mechanisms i listed, you'll get the
> > URL you want and then URL you're getting.
> >
> > That should help you see WHAT's happening, which should help you figure
> out
> > WHERE and HOW it's happening. I'm guessing you're doing this somewhere in
> > your code, which the recursive calls are causing to behave strangely:
> >
> > <cfset modself = modself & "more_stuff" />
> >
> > cheers,
> > barneyb
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, October 08, 2002 11:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: paths getting multiple cfid/cftokens
> >
> >
> > I'm getting url's like this, but only in certain parts of my app:
> >
> >
> "http://127.0.0.1/index.cfm/cfid/10/cftoken/index.cfm/cfid/10/cftoken/262140
> >
> 52/fuseaction/index.cfm/cfid/10/cftoken/26214052/fuseaction/checkout.Shippin
> > gAddress"
> >
> > Most of the places it's fine, this seems to be the only one that is
> causing
> > the problem. I am using ses convertor, but I do have the proper basehref
> in
> > the header.
> >
> > I do have a few(well, quite a few) recursive cfmodule calls, but use
> > #fusebox.rootpath##modself# (instead of self), and pass cfid/cftoken as
> > attributes for those.
> > Any ideas of where to look?
> >
> >
> > __________________________________________/Fusebox Conference!
> >
> > Sign up for the Fusebox Conference today!
> > October 26th & 27th: Orlando, FL, just before MACR DevCon.
> > 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> > Championship
> > http://www.fusebox.org/index.cfm?fuseaction=conference.main
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
> >
> >
> > __________________________________________/Fusebox Conference!
> >
> > Sign up for the Fusebox Conference today!
> > October 26th & 27th: Orlando, FL, just before MACR DevCon.
> > 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> > Championship
> > http://www.fusebox.org/index.cfm?fuseaction=conference.main
> >
> >
> >
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
------------------------------
Date: Tue, 8 Oct 2002 17:11:39 -0500
From: Chris Montgomery <[EMAIL PROTECTED]>
Subject: SES - Removing index.cfm & Fuseaction?
Howdy Fuseboxers,
I have two FB3 sites using SES URLs. Both sites are on a shared host
running Microsoft IIS5. I am using dummy filenames and extensions at the
end of the URL. The problem is, nothing after the index.cfm in
the URL is getting picked up in the web log files.
Wondering if it is possible to somehow remove the "index.cfm" and
"fuseaction" from the URLs. This way, the log files should pick up the
entire URL string. Anyone done this? If so, I'd be grateful to hear
about how you did it.
TIA.
Chris Montgomery monty @ airtightweb.com
--
Airtight Web Services http://www.airtightweb.com
Web Development, Web Project Management, Software Sales
210-490-3249/888-745-7603
------------------------------
Date: Tue, 8 Oct 2002 15:26:12 -0700
From: "Erik Voldengen" <[EMAIL PROTECTED]>
Subject: RE: SES - Removing index.cfm & Fuseaction?
It's a setting in IIS your host needs to adjust.
See the FAQ at www.fusium.com/go/ses
I'm going to release a second revision of the FAQ, but I
believe the current version has IIS tweak required for your
log files to pick up the ses stuff.
Be aware that some hosts will not make the adjustment
do to some sort of security risk. I don't know if it's
a big deal or not, but some people have issues with it
-Erik
> -----Original Message-----
> From: Chris Montgomery [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 3:12 PM
> To: Fusebox - Topica
> Subject: SES - Removing index.cfm & Fuseaction?
>
>
>
> Howdy Fuseboxers,
>
> I have two FB3 sites using SES URLs. Both sites are on a shared host
> running Microsoft IIS5. I am using dummy filenames and extensions at the
> end of the URL. The problem is, nothing after the index.cfm in
> the URL is getting picked up in the web log files.
>
> Wondering if it is possible to somehow remove the "index.cfm" and
> "fuseaction" from the URLs. This way, the log files should pick up the
> entire URL string. Anyone done this? If so, I'd be grateful to hear
> about how you did it.
>
> TIA.
>
> Chris Montgomery monty @ airtightweb.com
>
> --
> Airtight Web Services http://www.airtightweb.com
> Web Development, Web Project Management, Software Sales
> 210-490-3249/888-745-7603
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
------------------------------
Date: Tue, 8 Oct 2002 15:29:59 -0700
From: "Erik Voldengen" <[EMAIL PROTECTED]>
Subject: RE: SES - Removing index.cfm & Fuseaction?
BTW I am not sure which setting it is. I've installed IIS and I'll
take a look. I need to know for my SES presentation at the Fusebox
Conference, anyway.
-Erik
> -----Original Message-----
> From: Erik Voldengen [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 08, 2002 3:26 PM
> To: [EMAIL PROTECTED]
> Subject: RE: SES - Removing index.cfm & Fuseaction?
>
>
> It's a setting in IIS your host needs to adjust.
>
> See the FAQ at www.fusium.com/go/ses
>
> I'm going to release a second revision of the FAQ, but I
> believe the current version has IIS tweak required for your
> log files to pick up the ses stuff.
>
> Be aware that some hosts will not make the adjustment
> do to some sort of security risk. I don't know if it's
> a big deal or not, but some people have issues with it
>
> -Erik
>
> > -----Original Message-----
> > From: Chris Montgomery [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, October 08, 2002 3:12 PM
> > To: Fusebox - Topica
> > Subject: SES - Removing index.cfm & Fuseaction?
> >
> >
> >
> > Howdy Fuseboxers,
> >
> > I have two FB3 sites using SES URLs. Both sites are on a shared host
> > running Microsoft IIS5. I am using dummy filenames and extensions at the
> > end of the URL. The problem is, nothing after the index.cfm in
> > the URL is getting picked up in the web log files.
> >
> > Wondering if it is possible to somehow remove the "index.cfm" and
> > "fuseaction" from the URLs. This way, the log files should pick up the
> > entire URL string. Anyone done this? If so, I'd be grateful to hear
> > about how you did it.
> >
> > TIA.
> >
> > Chris Montgomery monty @ airtightweb.com
> >
> > --
> > Airtight Web Services http://www.airtightweb.com
> > Web Development, Web Project Management, Software Sales
> > 210-490-3249/888-745-7603
> >
> >
> > __________________________________________/Fusebox Conference!
> >
> > Sign up for the Fusebox Conference today!
> > October 26th & 27th: Orlando, FL, just before MACR DevCon.
> > 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> > Championship
> > http://www.fusebox.org/index.cfm?fuseaction=conference.main
> >
> >
> >
>
>
> __________________________________________/Fusebox Conference!
>
> Sign up for the Fusebox Conference today!
> October 26th & 27th: Orlando, FL, just before MACR DevCon.
> 2 jam-packed days, 15 speakers in three tracks, World Fuseball
> Championship
> http://www.fusebox.org/index.cfm?fuseaction=conference.main
>
>
>
------------------------------
Date: Wed, 9 Oct 2002 01:20:18 -0400
From: "Hal Helms" <[EMAIL PROTECTED]>
Subject:
Good news! First, the FB conference in Orlando, Oct.26-27. If you've
wanted to come but were put off by the cost, head over to:
http://fusebox.org/index.cfm?&fuseaction=conference.contestentry.
There's a simple entry form for a free registration. Over the next
couple of weeks, multiple winners will be selected using a secret
formula kept securely hidden in Steve Nelson's sock drawer.
While you're there, you'll see the spiffy new Fusebox site created by
Steve, Nat Papovich, and Erik Voldengen. The multi-talented David Huyck
did the graphics for the site.
See you at the conference!
Hal Helms
"Java for CF Programmers" class immediately
after Macromedia DevCon.
Info at www.halhelms.com
------------------------------
__________________________________________/Fusebox Conference!
Sign up for the Fusebox Conference today!
October 26th & 27th: Orlando, FL, just before MACR DevCon.
2 jam-packed days, 15 speakers in three tracks, World Fuseball
Championship
http://www.fusebox.org/index.cfm?fuseaction=conference.main
End of [EMAIL PROTECTED] digest, issue 965
