Masterview devel - Jun 2006 - On paths and expands and cleaning

Jeff - we''ll need to go over path handling one more time so our brains
and
code are both clear.

Assumption: we''ll always deal with normalized path representations (/
path
separator, not krufty windows \).  Initializer or other points where paths
can come in from the outside are responsible for doing any cleanup and
normalization.

Caveat: an abs path on Win32 has a drive letter prefix
(''X:/foo/bar''), but
not on *nix, and the ruby file services don''t necessarily work as
desired.
(eg, believe it told me that ''X:/foo'' is a relative path when
I was
experimenting with abs/rel path services)

Implications: the only place where we should need to do things like
expand_path and cleanpath are in initializer.rb, which bolts down all the
fundamental root dir path refs for the app session, or any subsequent points
where we provide services to establish an MIO onto a directory.  I think
there''s some now-unnecessary cases of this scattered around the MIO
world
that can be dropped.

Side note: cleanpath doesn''t on Windows, sigh - ugly things like
''../foo/../bing/bam'' clutter up my RAILS_ROOT, which is why I
made sure our
MV initializer tries to clean things up.  At least on Win32, expand_path
cleans up all the kruft so cleanpath seems unnecessary, but we can put that
back if needed on *nix.

Area we need to review: FileMIOTree''s root_path and set_root_parent - I
don''t quite understand the subtleties of what you''re trying to
do with the
latter in latest rails_init, we''ll need to review.  Not sure
it''s needed
since new initializer instantiates the MasterView::IOMgr with
FileMIOTree''s
whose root_paths are already properly resovled to abs dir refs w/in rails
app.  Muddling about in there this morning....

~ Deb

Yes, we''ll always deal with url style (*nix) paths and we''ll
primarily deal
with only relative paths letting FileMIO resolve to absolute. Only using
root paths for FileMIO when creating. Also to note I check that the exanded
relative path exists under the root_path to sandbox to a particular tree.
Using relative paths should keep things simple, except for times when we
want full_path for logging or messages. What I did in those cases was added
a full_pathname attribute for output which we can read from if from FileMIO
it has root+relative path, for all other MIO objects it just is the same as
relative path.

That''s a bummer that cleanpath doesn''t work on win32.

Yes, I actually had to add the set_root_path thing in after the fact, when I
realized that I didn''t have RAILS_ROOT yet when inside of
rails_init.rb. So
if you have that taken care of with initializer then we can simlify that. I
guess I wasn''t aware that RAILS_ROOT would be available in initializer.
If
you can update initializer how it needs to be then I can take out that
method to simplify. So I guess that''s why it didn''t make sense
to you, I
didn''t build it in originally either :-)

Is initializer also where we do the rest of rails_init.rb, the watcher
setup? I also added some code to there today to copy the stylesheets that
are needed for masterview admin if it is enabled and they don''t exist,
so I
wasn''t sure if you said this was going away (then let me know where I
should
put the code).

Jeff



On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - we''ll need to go over path handling one more time so our
brains and
> code are both clear.
>
> Assumption: we''ll always deal with normalized path representations
(/ path
> separator, not krufty windows \).  Initializer or other points where paths
> can come in from the outside are responsible for doing any cleanup and
> normalization.
>
> Caveat: an abs path on Win32 has a drive letter prefix
(''X:/foo/bar''), but
> not on *nix, and the ruby file services don''t necessarily work as
desired.
> (eg, believe it told me that ''X:/foo'' is a relative path
when I was
> experimenting with abs/rel path services)
>
> Implications: the only place where we should need to do things like
> expand_path and cleanpath are in initializer.rb, which bolts down all the
> fundamental root dir path refs for the app session, or any subsequent
> points
> where we provide services to establish an MIO onto a directory.  I think
> there''s some now-unnecessary cases of this scattered around the
MIO world
> that can be dropped.
>
> Side note: cleanpath doesn''t on Windows, sigh - ugly things like
> ''../foo/../bing/bam'' clutter up my RAILS_ROOT, which is
why I made sure
> our
> MV initializer tries to clean things up.  At least on Win32, expand_path
> cleans up all the kruft so cleanpath seems unnecessary, but we can put
> that
> back if needed on *nix.
>
> Area we need to review: FileMIOTree''s root_path and
set_root_parent - I
> don''t quite understand the subtleties of what you''re
trying to do with the
> latter in latest rails_init, we''ll need to review.  Not sure
it''s needed
> since new initializer instantiates the MasterView::IOMgr with
> FileMIOTree''s
> whose root_paths are already properly resovled to abs dir refs w/in rails
> app.  Muddling about in there this morning....
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/b4e42a79/attachment.htm

> > .. realized that I didn''t have RAILS_ROOT yet when inside of
rails_init.rb. 
>>  So if you have that taken care of with initializer then we can simlify
that.  
>> I guess I wasn''t aware that RAILS_ROOT would be available in
initializer.
>> ...
>>Is initializer also where we do the rest of rails_init.rb, the watcher
setup? 
>> I also added some code to there today to copy the stylesheets that are 
>> needed for masterview admin 
 
Yes, initializer is the guy that takes care of figuring out RAIL_ROOT etc.
Goes to a lot of effort to try to automagicallly always do the right thing;
maybe not quite right for all scenarios, but heading in the right direction
anyway.  
 
extras/rails_init.rb is going away, what it was doing is shared between
initializer.rb and new extra/init_rails_controller.rb.  I''ve been
synching
your changes last night/today that you''ve been doing in to
rails_init.rb
into the new code, so got your stylesheet thing.  
 
Not sure I''m wild about pushing the admin controller''s
stylesheets into
app''s public/stylesheets, may or may not be appropriate to litter their
space with "our" admin styles.  [tho I don''t yet have a
picture of how as an
app developer I''d want to integrate this into my app''s overall
styles and
layout...]
 
did you consider public/stylesheets/masterview?
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/4192321c/attachment.htm

On 6/15/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Yes, initializer is the guy that takes care of figuring out RAIL_ROOT
> etc.  Goes to a lot of effort to try to automagicallly always do the right
> thing; maybe not quite right for all scenarios, but heading in the right
> direction anyway.
>
> extras/rails_init.rb is going away, what it was doing is shared between
> initializer.rb and new extra/init_rails_controller.rb.  I''ve been
synching
> your changes last night/today that you''ve been doing in to
rails_init.rb
> into the new code, so got your stylesheet thing.
>
sounds good.


Not sure I''m wild about pushing the admin controller''s
stylesheets into
> app''s public/stylesheets, may or may not be appropriate to litter
their
> space with "our" admin styles.  [tho I don''t yet have a
picture of how as an
> app developer I''d want to integrate this into my app''s
overall styles and
> layout...]
>

Yeah, I thought twice about this too, but couldn''t come up with an easy
alternative. I figured if they use the generator which many of them will
then these will be generated anyway.  Of course we could move all of them
into a masterview folder below stylsheets like you mentioned, assuming the
asset_tag supports it which it probably does.


did you consider public/stylesheets/masterview?
>

Yes, I could change them to go there.


~ Deb
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060615/e3ab319d/attachment.htm