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