Hi all,

Thanks for the responses.

Firstly, looking at creating virtual mappings (as per Roger's Request),
one mustn't get confused between virtual directories on the webserver
and CF server mappings.

The one we would need is indeed a CF mapping, an IIS mapping (in our
case), wouldn't work, as the webserver knows nothing about whats up in
CF and there could be no inheritance of the master app.  In my example,
the "forums" app would inherit layout, datasources and other goodies
from the calling app.  (Also a good reason for having XFA's, as the
calling ap could define say different exits back to the main program...
Anyway, I digress...)

CF mappings require that there is a leading slash to call them.  This is
a problem is FuseQ and FB3 as they don't let you put a slash in there
(in fact the delimiter is a slash - I think a pipe (|) or comma would
have been better.:

If someone can tell me how this could work...

LeeBB (thanks Lee) and I had a discussion on this very issue a while
ago, and I ended up using a modifed version of the core to handle this.
Problem is, I don't want to use a model that substantially modifies the
core.  FuseQ is good as "the usual stuff" still works if you want it to.

On the issue of MVC, my apps are not MVC, but I like the concept and
will look at architecting new apps with this in mind.  As an aside, if
someone could establish some standard well known "design patterns"
(originally in C++) for FB3, (refer the authority on Design Patterns -
the so-called Gang of Four book - a synopsis of this available at
http://hillside.net/patterns/DPBook/DPBook.html), or at least something
similar.  Perhaps with the introduction of CFMX, we may see this become
a reality, with CFCs and the fact that they can inherit classes.  Maybe
I could (what, me?) try and get some in place. 

Sorry, digressing again!

Currently my apps that I want all this fancy stuff for are in XFB and we
are wanting to convert the code to FB3 (FuseQ).

Lets look at another example:

I have one main app called Cow
I have another main app called Cat
We also have an app called Security.
But there are sections of security that we want to use in both Cow and
Cat, e.g. user management.  

Circuits files in XFB inside Cow worked like so:

<CFSET Request.Circuits.acusr = "Cow.SecurityMenu./Security.Users">

And in cat:

<CFSET Request.Circuits.acusr = "Cat.SecurityMenu./Security.Users">

Cat, SecurityMenu reside in the Cat Directory:

/Security and Users reside in the Security app directory structure.

|
+Cow
|  +--SecurityMenu
+Cat
|  +--SecurityMenu
+Security
   +--Users

There is a CF mapping for Security to its physical directory.  This is
needed as security is *outside* the cow and cat directory trees.

Problem is FB3, FuseQ use / as the delimiter, so no more / allowed in
the Circuits definition.

Using another directory one level higher to encapsulate all the code (as
John mentions) is also problematic, as there are multiple apps that need
to be defined, each one needing their own entry point (if you get my
drift).

John, despite the fact it looks like 0-60 in < 60 secs, its not the case
- we have been looking at this issue for a while now!

I really think we are onto something here - Lee summed it up nicely in
our earlier discussion:  

"My basic idea was to disconnect the physical nesting from the logical
nesting.  This has many implications, eg : one circuit can be reused in
multiple applications 
circuits can be "assembled" out of pre-existing components, by defining
the appropriate logical ancestors

Your solution is to define a new mapping that for a physical location,
to make it appear that the one physical location has multiple physical
pseudo-locations.  That's cool.  I'm just not thrilled about having to
define new CF-wide mappings.  In general, I only have two mappings on my
server, "/" and "CustomTags".  And expecting any kind of mapping AT ALL
is a worry on a shared server.  I had lots of hassles with my wireframe
app before I gave up and made the whole thing use relative
 
So my solution is to get away from mappings, ie pseudo-locations, which
seem like a workaround.  I want to come out and explicitly state, "To
get to Circuit X, first go through directory A, then directory H, then
finish in directory Q."  The physical locations of the directories
should have no bearing on the matter, just as long as I can tell my app
where to find them.
 
The trick is to be able to locate the directories unambiguously.  There
are two possibilities, absolute or relative.  Absolute is the way I have
done it in my example, but it requires a single mapping for "/".  Even
that can be a hassle on shared servers, so a universal solution that the
community could get behind would have to go relative.

I look forward to seeing where this goes...  And your solution that you
mention.

Regards

Steven.


-----------------------------------------
Steven Ringo
Tutuka.com
http://www.tutuka.com
tel: +27 11 803 3118 
fax: +27 11 237 0153


> -----Original Message-----
> From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
> Sent: 17 May 2002 05:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FuseQ and sharing fuses among apps
> 
> 
> Steven,
> 
> whew, you jumped right from zero to 60 in under a minute! :)
> 
> if you were starting from scratch, then I'd suggest definitely 
> investigating a MVC design pattern. Hal wrote some short articles on 
> MVC, both with and without FuesQ. They are on the Techspedition.com 
> site and I've linked them into the "FuseQ to the ResQ" article. MVC, 
> rather than FuseQ, goes a long way towards achieving what you'd asked 
> about; FuseQ just makes it easy with Fusebox.
> 
> What you've described is quite do-able, even without MVC. You'll just 
> have to think it through a bit, but it sounds to me like you've 
> thought through the *problem* quite well already.
> 
> OK, on to your actual question:  *if* you are writing all these apps 
> yourself, *then* you could create what you describe, particularly if 
> you use MVC.  FuseQ will help greatly in this regard. You are up 
> against a small issue with Fusebox which is the umbrella directory 
> structure you mentioned. I have a solution for that, unrelated to 
> FuseQ, but it's not ready for prime-time yet. When it is I'll just
> fold it into the Techspedition core file. In the meantime if 
> you are able to control all the parts of your app then you 
> should be ok -- is the forums app at least a FB3 app?
> 
> one thing you'll want to do is to define in each of the Bird/Dog/Cat 
> apps, pointers to a circuit which has the common code in it, just like

> a pointer to a "queries" circuit .  Try setting up a higher level 
> circuit as the parent to all those, and having no fuseactions in it. 
> All it does is direct the request into the appropriate Bird/Dog/Cat 
> application
> 
> 
> ---- Original Message -----
> From: "steven ringo" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, May 17, 2002 8:10 AM
> Subject: FuseQ and sharing fuses among apps
> 
> 
> > Hi,
> >
> > Lets say I have made three applications:
> >
> > - Bird
> > - Cow
> > - Dog
> >
> > Each one of these apps is self-contained, having their own fbx core 
> > files, index.cfm etc.
> >
> > To get to each of these, I would go: bird.site.com/index.cfm 
> > cow.site.com/index.cfm dog.site.com/index.cfm etc...
> >
> > The directory structure looks like this:
> >
> > wwwroot
> > +----Bird
> > +----Cow
> > +----Dog
> >
> >
> > Now the tricky part:
> > I need to "include" a Forums application inside each of these apps, 
> > but with inheritance of layout, datasources, etc.
> >
> > The current way of doing things says make a copy of Forums
> under each
> > app. This is not good as I have to maintain 3 instances of the same 
> > code.
> >
> > wwwroot
> > +----Bird
> > |   +---Forums
> > +----Cow
> > |   +---Forums
> > +----Dog
> >     +---Forums
> >
> >
> > Ideally I would want to have:
> >
> > wwwroot
> > +----Bird
> > +----Cow
> > +----Dog
> > +----Forums
> >
> > and then map the Forums' set of fuses appropriately to each of the 
> > apps.
> >
> > Problem is I cant get "past the root" or a directory higher
> than the
> > apps's root in the circuits file.
> >
> > "Normal" FB3 does not handle this situation.
> >
> > Does FuseQ handle this, and if so, how?  I am looking to
> this line of
> > text by John QvT for inspiration:
> >
> > "Heaven help you if you want all your query files to be in
> a physical
> > directory 8 directories up, 5 directories over, and 17 directories 
> > down. You can imagine what that would look like! Double Ugh!"
> >
> > Thanks all
> >
> > Steven Ringo
> >
> >
> 
> 
> 

==^================================================================
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]

T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================

Reply via email to