Barry...
I'll grant you that I'm not entirely as pattern-aware as I should be,
but if I were doing this I'd offload the file-system access to a
composition class. For anything I've done like this, like Pinger or
PayPalMX, I use a standard xmlHandler.cfc and fileHandler.cfc... so
PayPalMX has access to the xmlHandler's methods, and xmlHandler.cfc
uses fileHandler for it's disk access... that way each CFC stays true
to it's original purpose but gains the functionality needed to do it's
job.
I would strongly recommend against writing direct file-system access
into the CFCs, but use a composition member or two ('enablers' or
'providers') to handle the low-level functions and your persistence
tier to wrap methods provided by those low-level enablers.
See my nOOb's entry about composition on my blog for a little deeper
info and the source code for both xmlHandler and fileHandler.
Incidentally, the fileHandler in the blog entry is stateful, and
maintains a string (unparsed) version of the XML file in instance
data. There are 2 ways to approach it's use. First is a one-off read()
method that returns the file contents. The other is an init("path")
method that keeps the file's contents in memory. Why would you use
either one?
I incorporated the stateful idea after some discussion with Sean
because that fileHandler will probably grow to include write and/or
append methods and possibly string parsing/regex functionality for
handling text files as I refactor it. Hence it could init() to get the
file, reReplace() to edit the file and save() to write the new file
back to disk.
But it can still be used effectively as a stateless object by calling
init("path").read() if all you want to do is get the contents of the
text file.
Here's a link to the blog entry (beware the wrapperwocky):
http://www.web-relevant.com/blogs/cfobjective/index.cfm?mode=entry&entry=F2BEA2B4-BDB9-5320-E5C3E71176231252
On 4/26/05, Barry Beattie <[EMAIL PROTECTED]> wrote:
> hi all
>
> I'm just about to add xml functionality using cffile, cfdirectory to
> the persist layer. (each persist decorates it's service which
> decorates a singleton in server scope). The files are on the
> webserver, not uploaded.
>
> this is sort of the idea (but the thread petered out...)
> http://www.mail-archive.com/[email protected]/msg06983.html
>
> But since CFFILE is a global scope like URL, FORM, or REQUEST (and we
> don't break encapsulation by accessing external scopes within a CFC),
> I'm a bit unsure if this is actually a good idea.
>
> also, none of the cfc's (so far) access the filesystem directly - and
> I'm quite happy about that, especially when it comes to file locking,
> etc. If it's database access the persist needs then the db connection
> pool will take care of db access - but what about file access in this
> case? If any locking is done, it's done at the UI/view layer - there's
> no locks within CFC's
>
> any suggestions, etc?
> thanx
> barry.b
--
---------------
-------------------------------------
Buy SQLSurveyor!
http://www.web-relevant.com/sqlsurveyor
Never make your developers open Enterprise Manager again.
----------------------------------------------------------
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).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
