Paul,
Good ideas, though I would like to try and keep it as simple as possible:
what Hal suggested was to use ListFirst() in the CFSWITCH (then there is no
variables.fuseaction - I put it in the example to try and clarify what
happens).
About trying to keep backward compatibility - either the fuseaction has a
single action and then all works fine - or it has more than one (nested
case) and then it breaks which is correct - shouldn't pass a nested
fuseaction to a fusebox which doesn't support it.
Noam
P.S. please turn off the MIME when sending to the list - it creates messages
double the size... (both MIME and plain text)
----------
From: Paul Johnston [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 24 July 2000 12:25
To: '[EMAIL PROTECTED]'
Subject: RE: Nested Fuesbox apps
This message is in MIME format. Since your mail reader does not
understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01BFF559.5E91EF60
Content-Type: text/plain;
charset="iso-8859-1"
How about instead of having a fuseaction with lots of fuseactions in
it,
call it a fusewire? That way you cannot get confused with
attributes.fuseaction and variables.fuseaction? You can then put
attributes.fuseaction = ListFirst(attributes.fusewire) and remove
that
element to create the fusewire to pass on. One variable passed, two
separate variables used. The fusewire can then be available at any
point
with an easy and intuitive name.
Home Fusebox
request.callerFuseaction: BookStore.Cart.AddItem
fusewire: BookStore.Cart.AddItem
fuseaction: Bookstore
Bookstore Fusebox
request.callerFuseaction: BookStore.Cart.AddItem
fusewire: Cart.AddItem
fuseaction: Cart
Cart Fusebox
request.callerFuseaction: BookStore.Cart.AddItem
fusewire: AddItem
fuseaction: AddItem
Another possible way of doing it, is to call
request.callerFuseaction the
fusewire and add a numerical variable at the end of it to say at
which level
you're at so only using one variable for each of the three parts:
Get the fuseaction with (allowing for backwards compatibility with
non-fusewire apps)
<!--- set fusewire to fuseaction if not set --->
<!--- (bear in mind that if fusewire is set, this won't be, and if
it --->
<!--- isn't, then fuseaction will be --->
<cfparam name="attributes.fusewire"
default="#attributes.fuseaction#">
<!--- if fusewire has more than 1 element, then it must have a
number --->
<!--- and if it doesn't, add a 1 to the end --->
<cfif ListLen(attributes.fusewire,".") gt 1>
<cfset variables.listnum =
ListLast(attributes.fusewire,".")>
<!--- check to see if not numeric, and add 1 if not --->
<cfif NOT IsNumeric(variables.listnum)>
<cfset attributes.fusewire = attributes.fusewire &
".1">
</cfif>
<cfelse>
<cfset variables.listnum = 1>
</cfif>
attributes.fuseaction =
ListGetAt(attributes.fusewire,variables.listnum,".")
Home Fusebox
fusewire: BookStore.Cart.AddItem.1
fuseaction: Bookstore
Bookstore Fusebox
fusewire: BookStore.Cart.AddItem.2
fuseaction: Cart
Cart Fusebox
fusewire: BookStore.Cart.AddItem.3
fuseaction: AddItem
This has the advantage of being blind to the coder because all they
have to
do is to put the fusewire in like BookStore.Cart.AddItem and the
fusebox
will add the 1 at the end to begin with, and get the first
fuseaction.
Every subsequent fusebox can then increment this end number to pass
the
fusewire on.
Just a couple of thoughts. Any good?
Paul
> -----Original Message-----
> From: BOROVOY Noam [mailto:[EMAIL PROTECTED]]
> Sent: 24 July 2000 09:39
> To: '[EMAIL PROTECTED]'
> Subject: RE: Nested Fuesbox apps
>
>
> Yes, that's the whole idea:
> Each fusebox will take it's fuseaction by using
> ListFirst(request.CallerFuseAction, ".")
> Then cut it off so the next fusebox down can also do the same.
> to use the same example of a three level nested fusebox:
>
> Fusebox1(Home Fusebox)
> In
> request.CallerFuseAction = ""
> attributes.Fuseaction = BookStore.Cart.AddItem
> Variables.Fuseaction = BookStore (this will be used in
> the CFSWITCH /
> CFCASE)
> Out:
> request.CallerFuseAction = BookStore.Cart.AddItem
> attributes.Fuseaction = Cart.AddItem
>
> Fusebox2 (BookStore fusebox)
> In
> request.CallerFuseAction = BookStore.Cart.AddItem
> attributes.Fuseaction = Cart.AddItem
> variables.Fuseaction = Cart
> Out:
> request.CallerFuseAction = BookStore.Cart.AddItem
> attributes.Fuseaction = AddItem
>
> Fusebox3 (Cart Fusebox)
> In
> request.CallerFuseAction = BookStore.Cart.AddItem
> attributes.Fuseaction = AddItem
> variables.Fuseaction = AddItem
>
> In any display performed in any of the fuseboxes they can
> keep the context
> so that the same parent fusebox will receive the call by using:
>
> variables.ParentFuseaction = Left( request.CallerFuseAction,
> Len(request.CallerFuseAction) - Len(attributes.fuseaction) ).
>
> and then:
> <A
> href="#CGI.ScriptName#?fuseaction=#variables.ParentFuseaction#
> ChildAction">
>
> Again using the above example:
> If from the AddItem you want to go to ViewItems:
> variables.ParentFuseaction = "BookStore.Cart."
> <A
> href="#CGI.ScriptName#?fuseaction=#variables.ParentFuseaction#
> ViewItems">
> which will become:
> <A href="index.cfm?fuseaction=BookStore.Cart.ViewItems">
>
> Regards,
> Noam
>
>
> > ----------
> > From: Hulsey, James Phillip[SMTP:[EMAIL PROTECTED]]
> > Reply To: [EMAIL PROTECTED]
> > Sent: Monday, 24 July 2000 1:26
> > To: '[EMAIL PROTECTED]'
> > Subject: RE: Nested Fuesbox apps
> >
> > Noam,
> > Again. Great stuff.
> > So, given what you're stating, we would actually have an
> n-tier fusebox
> > solution? We could keep building request.CallerFuseAction
> by adding to it
> > as
> > it passes through each sub-app....couldn't we?
> >
> > Sounds good to me! We need to standardize on this stuff as
> this is a big
> > step toward portability and reuse :) Plug and play fusebox!
> >
> > Phil
> >
> > -----Original Message-----
> > From: BOROVOY Noam
> > To: '[EMAIL PROTECTED]'
> > Sent: 7/21/00 9:45 AM
> > Subject: RE: Nested Fuesbox apps (also RE: Other security
> considerations a
> > nd fusebox methodologies...)
> >
> > > How about refining the method to allow any fusebox to
> nest any other
> > > fusebox
> > > and allow all links to be built automatically:
> > >
> > > If the variable request.CallerFuseAction is defined then
> all links can
> > be
> > > built using:
> > >
> > > fuseaction for links: request.CallerFuseAction
> &".ChildFuseAction"
> > > Which then will be passed to the CGI.ScriptName which
> will be the top
> > > level
> > > Index.cfm
> > > Such as: <A
> > >
> >
> href="#CGI.ScriptName#?fuseaction=#request.CallerFuseAction#.C
> hildAction
> > "
> > >
> > > So an example for a three level nesting:
> > > BookStore.Cart.AddItem
> > > The top level index.cfm has an action store which forwards to
the
> > store
> > > sub
> > > directory index.cfm with the action:
> > > Cart.AddItem
> > > Which in turn forward to Cart sub directory index.cfm
> with the action:
> > > AddItem
> > >
> > > This way the top level index.cfm files each only have a
> single case
> > > statement for each child fusebox and they append this
> fuseaction to
> > the
> > > request.CallerFuseAction so that each included sub
> fusebox knows how
> > to
> > > build the links properly without having to hard code them.
> > >
> > > With this and RFA's (return fuseactions) you could easily
reuse
> > modules at
> > > any level without needing to know the internals of what you
are
> > including.
> > >
> > > Let me know what you think,
> > > Noam
> > >
> >
> --------------------------------------------------------------
> ----------------
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=list
s/fusebox or send a message to [EMAIL PROTECTED]
with
'unsubscribe' in the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
