Masterview devel - Jun 2006 - I am thinking of creating a class to encapsulate file reads

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.
 
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) 

~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Friday, June 02, 2006 8:02 AM
To: dlewis at glaivestone.com
Subject: I am thinking of creating a class to encapsulate file reads


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. 

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. 

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.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060602/da14f975/attachment.htm