Masterview devel - Jul 2006 - Bug: direct-to-erb-view-cache doesn''t worth when tmplt dir paths modified

Jeff - Got sidetracked on my way to adding config paths for asset root refs
per pending discussion started by Ed H; was trying to figure out why my app
broke when I ran it with the new 0.2.x build with direct-to-erb.  Got
"template not found" on every page.

Turns out that the problem appears to be caused when template src/dst dir
paths are modified from the default app/views.

I''m currently only using mv templates in a specific area of my site
(''content'' controller), so my settings.rb has:

config.template_src_dir_path = ''app/views/content''
config.template_dst_dir_path = ''app/views/content''

This worked before; broke when I ran with the new 0.2.x.  Tracked down the
problem with some clues that the admin controller shows - in this config, a
template ''app/views/content/foo.html'' went into the cache as
''foo.html'', not
''content/foo.html'' as needed by the operational system.

If I just drop out my path changes and run with the MV default (operate on
entire app/views dir), things work again.

Might be a simple fix, but I''m tabling for the moment; feel free to
take a
look/fix.

Couple notes on admin controller: was trying to fix the config page to use a
layout so we can share that across the admin pages.  Doesn''t quite
work, so
I committed the code to make it easier to return to later but it''s
disabled.
If you drop my draft version of the admin guy''s
layouts/masterview_admin.rhtml in your own app''s layouts dir and turn
on the
render-with-layout version of the code, it works, but haven''t found the
right hook to get into the underlying template rendering service we need
s.t. I can use the option for indicating that the template ref is an abs
path, not a rel ref in the app/views/layouts.

Suggestion: any downside to turning the template items in the main admin
list into links so it''s easy to open them in a local view?  We make it
easy
to see the generated output now, but it''s hard to get back to the
original
template from whence that came.

~ Deb

Hmm.

Normally I would suggest that people simply set things to app/views for both
src and dst, even if not using the templates except in a subdirectory.

Gets back to how the relative directories are applied. If you set your root
of the content to be app/views/content then the relative paths to content
will be what gets used for direct to erb. The idea was that if you wanted to
have a tree structure outside of app/views you could but that you would want
to duplicate the directory structure in there.

Is there any reason you wouldn''t want to simply set your src/dst to
app/views??

I think that is what we would strongly recommend users to do if they are
going to be using inside of the app/views tree, otherwise the first time
they add something else (different subdirectory), it won''t show up
either.

If you think we should support things as you have described (src/dst as
subdirectory of app/views) then I can take a look at the relative path
stuff, however it could make this a little ugly compared to what it is now.
Let me know what you think.

And on the MV admin page, did you mean creating live links to the pages off
of admin or view of the template itself? We could do either.

Jeff




On 7/3/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - Got sidetracked on my way to adding config paths for asset root
> refs
> per pending discussion started by Ed H; was trying to figure out why my
> app
> broke when I ran it with the new 0.2.x build with direct-to-erb.  Got
> "template not found" on every page.
>
> Turns out that the problem appears to be caused when template src/dst dir
> paths are modified from the default app/views.
>
> I''m currently only using mv templates in a specific area of my
site
> (''content'' controller), so my settings.rb has:
>
> config.template_src_dir_path = ''app/views/content''
> config.template_dst_dir_path = ''app/views/content''
>
> This worked before; broke when I ran with the new 0.2.x.  Tracked down the
> problem with some clues that the admin controller shows - in this config,
> a
> template ''app/views/content/foo.html'' went into the cache
as ''foo.html'',
> not
> ''content/foo.html'' as needed by the operational system.
>
> If I just drop out my path changes and run with the MV default (operate on
> entire app/views dir), things work again.
>
> Might be a simple fix, but I''m tabling for the moment; feel free
to take a
> look/fix.
>
> Couple notes on admin controller: was trying to fix the config page to use
> a
> layout so we can share that across the admin pages.  Doesn''t quite
work,
> so
> I committed the code to make it easier to return to later but it''s
> disabled.
> If you drop my draft version of the admin guy''s
> layouts/masterview_admin.rhtml in your own app''s layouts dir and
turn on
> the
> render-with-layout version of the code, it works, but haven''t
found the
> right hook to get into the underlying template rendering service we need
> s.t. I can use the option for indicating that the template ref is an abs
> path, not a rel ref in the app/views/layouts.
>
> Suggestion: any downside to turning the template items in the main admin
> list into links so it''s easy to open them in a local view?  We
make it
> easy
> to see the generated output now, but it''s hard to get back to the
original
> template from whence that came.
>
> ~ 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/20060705/6582a04e/attachment.html

Just to add to the previous comment.

Currently when using direct to erb, the dst is ignored since it only uses
the relative path for things.

If we make the hard assumption that whatever src is specified is the root of
masterview html then what we have today works in direct to erb mode. Kind of
like what we were saying before that if you use app/masterview as your root,
then underneath that you would have
app/masterview/controllername/action.html. I think it would be best to steer
people away from situations like you came up with app/views/content src and
dst. Dst should always be the root of view, src should always be the root of
your source tree (although one can develop a mirrored structure if one
chooses to store those outside of app/views).

Does this make sense?

I am just seeing all sorts of other issues and headaches if we go down that
path.

On 7/5/06, Jeff Barczewski <jeff.barczewski at gmail.com>
wrote:
>
> Hmm.
>
> Normally I would suggest that people simply set things to app/views for
> both src and dst, even if not using the templates except in a subdirectory.
>
> Gets back to how the relative directories are applied. If you set your
> root of the content to be app/views/content then the relative paths to
> content will be what gets used for direct to erb. The idea was that if you
> wanted to have a tree structure outside of app/views you could but that you
> would want to duplicate the directory structure in there.
>
> Is there any reason you wouldn''t want to simply set your src/dst
to
> app/views??
>
> I think that is what we would strongly recommend users to do if they are
> going to be using inside of the app/views tree, otherwise the first time
> they add something else (different subdirectory), it won''t show up
either.
>
> If you think we should support things as you have described (src/dst as
> subdirectory of app/views) then I can take a look at the relative path
> stuff, however it could make this a little ugly compared to what it is now.
> Let me know what you think.
>
> And on the MV admin page, did you mean creating live links to the pages
> off of admin or view of the template itself? We could do either.
>
> Jeff
>
>
>
>
>
> On 7/3/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> > Jeff - Got sidetracked on my way to adding config paths for asset root
> > refs
> > per pending discussion started by Ed H; was trying to figure out why
my
> > app
> > broke when I ran it with the new 0.2.x build with direct-to-erb.  Got
> > "template not found" on every page.
> >
> > Turns out that the problem appears to be caused when template src/dst
> > dir
> > paths are modified from the default app/views.
> >
> > I''m currently only using mv templates in a specific area of
my site
> > (''content'' controller), so my settings.rb has:
> >
> > config.template_src_dir_path = ''app/views/content''
> > config.template_dst_dir_path = ''app/views/content''
> >
> > This worked before; broke when I ran with the new 0.2.x.  Tracked down
> > the
> > problem with some clues that the admin controller shows - in this
> > config, a
> > template ''app/views/content/foo.html'' went into the
cache as '' foo.html'',
> > not
> > ''content/foo.html'' as needed by the operational
system.
> >
> > If I just drop out my path changes and run with the MV default
(operate
> > on
> > entire app/views dir), things work again.
> >
> > Might be a simple fix, but I''m tabling for the moment; feel
free to take
> > a
> > look/fix.
> >
> > Couple notes on admin controller: was trying to fix the config page to
> > use a
> > layout so we can share that across the admin pages.  Doesn''t
quite work,
> > so
> > I committed the code to make it easier to return to later but
it''s
> > disabled.
> > If you drop my draft version of the admin guy''s
> > layouts/masterview_admin.rhtml in your own app''s layouts dir
and turn on
> > the
> > render-with-layout version of the code, it works, but haven''t
found the
> > right hook to get into the underlying template rendering service we
need
> >
> > s.t. I can use the option for indicating that the template ref is an
abs
> > path, not a rel ref in the app/views/layouts.
> >
> > Suggestion: any downside to turning the template items in the main
admin
> > list into links so it''s easy to open them in a local view? 
We make it
> > easy
> > to see the generated output now, but it''s hard to get back to
the
> > original
> > template from whence that came.
> >
> > ~ 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/20060705/bbd657e0/attachment-0001.html

Jeff - thanks for the explanations of some of your thinking.   Let''d
not do
anything right now about this - my config change to restrict MV template
processing to specific subdir of my app/views can be considered a side
effect of earlier versions when we were generating .rhtml files back into
views.  I don''t think it''s that interesting now that we
compile directly
into the view cache, so unless there''s issue such as perf that would
lead
you to want to restrict the template checking I''d say leave it be.
 
I changed my config back to leave the default app/views as the template
src/dst dir settings and I''m once again a happy masterview user.
 
This would be a good for the "tips and troubleshooting" doc that we
need to
write one of these days, though - someone might run into this and it''s
quite
baffling, took me several hours to hunt down the problem.
 
Side note: we''d  briefly kicked around some thoughts on whether it
might be
important to be able to specify some of the config settings on multiple MIO
trees vs. the single MIO structure that we currently have.  Was thinking
about that and I''m informally convinced that it would be fairly do-able
without breaking the existing config protocol if we ever wanted to do so.
To support multiple MIO trees, existing protocol would remain and map behind
the scenes to the "primary" MIO tree, with some additional protocol
provided
to allow adding and configuring options for additional sections.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060706/05ebd046/attachment.html