<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=497451015-02062006>believe I like that approach - TemplateLoader or
something like that. I'll wander around the code a bit more today and see
how that "feels" when I've gotten a bit more oriented to some of the pieces of
what's going on.</SPAN></FONT></DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=497451015-02062006></SPAN></FONT> </DIV>
<DIV dir=ltr align=left><FONT face=Arial color=#0000ff size=2><SPAN
class=497451015-02062006>When the new config/init mechanism is committed, we can
also start pushing some of the constants currently bolted onto the MasterView
module itself down into specific classes that they belong to when general scope
isn't appropriate, e.g., maybe proposed TemplateSrcRelativePath should
actually own the MasterView::TemplateSrcRelativePath constant (or
whatever it wants to call it)
<P></SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN
class=497451015-02062006>~ Deb</SPAN></FONT></P></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Jeff Barczewski
[mailto:jeff.barczewski@gmail.com] <BR><B>Sent:</B> Friday, June 02, 2006 8:02
AM<BR><B>To:</B> dlewis@glaivestone.com<BR><B>Subject:</B> I am thinking of
creating a class to encapsulate file reads<BR></FONT><BR></DIV>
<DIV></DIV>In thinking about your file read problem, I am thinking about
consolidating our file reading to a single class so we can insure that things
are being handled the same everywhere. Also it will make it easy to test since
we can have a hook so that instead of reading from a file it can go to a hash,
and when we start having the ability to store things in db, then it could read
from there. <BR><BR>I have to flush out the idea a little but I think this would
be a powerful approch and will help us insure that no files are being left open
since we can test that function heavily. I may have to be able to tell it to
read from file system for these types of files and from db for others. We could
also encapsulate all the root path logic in that class as well. Caching could be
done there as well as logging. <BR><BR>Thus far I was not able to reproduce the
problem you described running on my linux system, but when I create this class
then I will test it heavily including testing lock
scenarios.<BR><BR>Jeff<BR></BODY></HTML>