Yes, we are on pretty much the same page here.<br><br>I think that ultimately they should go in the app/views directory right where they belong. The only reason I didn't put them there originally is because I didn't want users to get confused and such. However once we can eliminate the erb intermediate file then there is no confusion.
<br><br>So app/views/controller/action.html will work out well. <br><br>I think I can add the direct to erb cache pretty soon, but if we wanted to so something like app/masterview in the meantime we could since that has the advantage of being the same subdirectory depth as app/views.
<br><br>As for the directives, I too wasn't sure where to put them. I put them down in the plugin directory because that seemed to be where to keep everything together, but it isn't necessarily the best place. And I was trying to think about ways where they could reuse the custom directives across apps, so it is fine to allow them to put things into an app config directory but I want to make sure to have a way for directives to be loaded in other directories too. It turns out though that as long as they load
masterview.rb first, then they can simply require anything else in that they want and they will show up as directives (if they inherited from directive_base)> <br><br>Your suggestion about using app/masterview/directives sounds like a good one.
<br><br>For keyword expansion, I started out with ruby inline substitution but since that conflicted with the erb inline substitution using the same notation, I fell back to plan B. <br><br>Plan B was to just do simple keyword expansion of simple text.
<br>Here is the keywords I used in my first iteration of this.<br><br>For template path = app/views/masterview/foo/bar.html where app/views/masterview is the template root<br>TEMPLATE_PATH = foo/bar.html<br>* = foo/bar<br>
SHORTNAME = foo/bar (same as *, its the template_path minus the extension)<br>CONTROLLER = foo<br>ACTION = bar<br>EXTENSION = .html<br><br>I originally had additional ones but I think these would be the core.<br><br>We could even allow this to be configurable too, if for instance someone wanted to use one of these. That would theoretically allow them to use something like {template_path} if they wanted to for the keyword rather than the all capital names.
<br><br>But I like this simplicity since upper case is typically seen as a replacement (or constant) and * is not typically used for a path, then something like this works well. It also stands out when you ready it and is cleaner than using {template_path} so they would do layouts/CONTROLLER.rhtml *.rhtml etc.
<br><br>We can also assume that if they don't specify an extension that it would use the default setup '.rhtml' that way they can just use * and be done.<br><br>The way I wrote the keyword expander is that it would start with the longest strings first so even if we ended up having keywords that used the same subwords (not recommended) but it would still work.
<br><br>Typically keyword expansion is only needed on generate, gen_* and import* commands so by having it default to on only for those it doesn't affect most other directives.<br><br>Jeff<br><br><br><div><span class="gmail_quote">
On 6/7/06, <b class="gmail_sendername">Deb Lewis</b> <<a href="mailto:djlewis@acm.org">djlewis@acm.org</a>> 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 - some thoughts on some of the current default config settings for key<br>locations that MV deals with.<br><br>[long, this is kind of a "thinking out loud" msg to elaborate some<br>alternatives]<br><br>Current MV config defaults:
<br><br>- template source directory;<br> - rails app: app/views/masterview<br> - non-rails config: not sure if there's a good default assumption<br> [I put in './masterview/templates' for now...]<br><br>- template output directory:
<br> - rails app: app/views<br> - non-rails config: nil - client needs to say what they want<br><br>- directives load path:<br> - initialized to load mv built-in directives:<br> [ "#{MV_LIB_DIR}/masterview/directives' ]
<br><br>I'm now quite happily in the process of converting some content pages for a<br>site that I'm moving onto rails into masterview templates. This is a<br>relatively simple use case scenario: mainly wrapping some existing, fairly
<br>static content in MV templates with mv:generate="*" specs to spit out body<br>content into an .rhmtl for the <%= @content_for_layout %> slot in the rails<br>site's layout. Some lightweight usage of mv/rails facilities (mv:attr to
<br>map some hrefs between ref in my template sandbox to how the urls look in<br>the real site).<br><br>Aside from still needing to settle on notation for mv:generate to provide<br>"magic values" ("*" or "#{template_rel_ref}" or a pythonic-style
<br>"__template_rel_ref_" or ...) or var subst for target path, I'm quite happy<br>with how this works. MV lets me create content pages as complete, valid<br>xhtml docs and supports declarative-style markup using the mv: attributes.
<br>Very nice.<br><br>But I've gone through several variations of "where do I want to keep my<br>template files" over the past week, partly just to play with the mechanisms<br>and test things. I've used:<br><br>
app/views/masterview - the default config<br> app/mv-templates - sibling structure which maps output into app/views<br><br>[and not tried but might consider: app/views/masterview/templates - fits in<br>with the MasterviewController structure]
<br><br>I somewhat prefer the sibling dir alongside app/views over the current<br>default w/in the views dir - I like the symmetry of the parallel structure,<br>rather than pushing masterview templates into a somewhat odd,
<br>not-used-in-quite-the-usual-fashion area within app/views.<br><br>But what I've actually settled on, which what I wanted in the first place<br>and is the right structure in the long run:<br><br> app/views - MV .html templates live right where they belong
<br><br>The fact that generated .rhtml files appear alongside my .html templates is<br>simply an artifact of the current MV implementation. Someday (*), the<br>.rhtml intermediate files won't need to be there - a view ref that maps onto
<br>a MV template will do the same magic compile-on-the-fly and caching that<br>rails does now for its .rhtml files.<br><br>(*) maybe even soon, because I can begin to see a way to do this, at least<br>for this simple scenario where there aren't inter-template generate/import
<br>dependencies<br><br>After first pass to settle the basic structure in my site, I now see an<br>opportunity to use a custom directive to simplify some annoying markup<br>redundancy in the original static impl. I'm going to give that a try and if
<br>it works out it'll be a good example to deliver with MV. Specific case is<br>that I have a number of pages which are just indexes to report files and<br>each report link has a little document icon indicating the form of the
<br>report (an html view or a printable view or a PDF file). So a little<br>icon_for_link directive would be a really handy gadget for this site.<br><br>All of which is the rationale leading into other thought on MV config
<br>defaults: believe it would be useful for the default config for a rails<br>application to have a point of view on where it might find app-specific<br>directives to automatically load. If app dir's directory exist, append to
<br>config.directive_paths after the MV built-ins.<br><br>Not sure putting directives code in config/masterview/directives is the<br>right place. Possible app/masterview/directives; possibly<br>app/lib/masterview/directives is better (but need to review rails loading
<br>magic to see if that would work, don't want rails itself to auto-load things<br>in there)<br><br>Opinion? I hypothesize that the empty directives dir in the masterview<br>trunk was your notion for providing a convention for this, but don't think
<br>that's the right place.<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>