Sorry, Jim, I had missed your earlier email. I think I like the idea of a new CFMAPPING tag better than redefining the CFAPPLICATION tag to have a tag body and contain CFAPPLICATIONPARAM tags. The former seems less radical.
Vince > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Davis > Sent: Friday, September 30, 2005 12:21 PM > To: [email protected] > Subject: RE: [CFCDev] Java CFCProxy info? > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Vince Bonfanti > > Sent: Friday, September 30, 2005 12:05 PM > > To: [email protected] > > Subject: RE: [CFCDev] Java CFCProxy info? > > > > BTW, this exact discussion is happening on > BlueDragon-Interest right now. > > Here are two proposals: (1) a new tag: > > > > <cfmapping path="C:\mapped\path1"> > > <cfmapping path="D:\mapped\path2,E:\mapped\path3"> > > This is nice for one reason: it's not application specific, > it's request specific. That could come in handy. > > > or, (2) a new optional attribute to the CFAPPLICATION tag: > > > > <cfapplication > > mappings="C:\mapped\path1,D:\mapped\path2,E:\mapped\path3"> > > > > Is this what you had in mind? > > Of course both solutions you offer are missing parameters > (you need both the system path and the mapping name - so > lists of mappings aren't very elegant since you'd have to use > either positional processing or multiple delimiters). > > My suggestion was in the thread already, I'd prefer to see > things more structured. Something like: > > <cfapplication .... > > > <cfapplicationparam type="mapping" systempath="c:\mycfcs\" > mappedpath="/mycfcs/" /> > <cfapplicationparam type="mapping" systempath="c:\hiscfcs\" > mappedpath="/hiscfcs/" /> > > </cfapplication> > > The CFApplicationParam tag would be extensible to other > entities as well: > application-specific DSNs, debugging or logging settings, > timeouts, SMTP settings, etc - basically anything that you > might want override on an application-basis. > > Of course whether there's a single "<cfapplicationparam>" tag > or a set of sub tags ("<cfapplication_mapping>", > "<cfapplication_DSN>", "<cfapplication_Debug>", etc) is > really irrelevant as long as the capability exists. > > I could also see such a feature leverage an interface similar > to the existing CF Admin API CFCs. The interfaces would be > essentially the same but instead of making admin changes > these CFCs (and their altered > properties) could persist in the application scope and only > affect application templates. > > Jim Davis > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [email protected] with the words 'unsubscribe cfcdev' as > the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting (www.cfxhosting.com). > > CFCDev is supported by New Atlanta, makers of BlueDragon > http://www.newatlanta.com/products/bluedragon/index.cfm > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
