Just to add to the previous comment.<br><br>Currently when using direct to erb, the dst is ignored since it only uses the relative path for things. <br><br>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).
<br><br>Does this make sense? <br><br>I am just seeing all sorts of other issues and headaches if we go down that path.<br><br><div><span class="gmail_quote">On 7/5/06, <b class="gmail_sendername">Jeff Barczewski</b> &lt;
<a href="mailto:jeff.barczewski@gmail.com">jeff.barczewski@gmail.com</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;"><div>
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></div><div><span class="sg"><br>Jeff</span></div><div><span class="e" id="q_10c3fb8754ebb94b_2">
<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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">Masterview-devel@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/masterview-devel" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://rubyforge.org/mailman/listinfo/masterview-devel</a><br></blockquote>
</div><br>

</span></div></blockquote></div><br>