On 4/4/07, <b class="gmail_sendername">David Koontz</b> <<a href="mailto:david@koontzfamily.org">david@koontzfamily.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>><br>> A) if I ever need to turn on rhtml rendering it will be a<br>> horrid mess, I would like to have a "generated" area that I can safely<br>> blow away when I'm done needing to generate the rhtml.
<br>><br>><br>><br>> I agree. We need an easy way to allow users to generate the rhtml to a<br>> new safe area other than the main project. I think this might best be<br>> served by using a rake command. We already have one that invokes the
<br>> generator, but in addition it should take an argument about where to<br>> generate the rhtml. This would allow you to generate the rhtml to a<br>> specified location without having to touch your config and not pollute
<br>> the main directory.<br>><br>> I think this will be an easy change. Would this meet your needs?<br><br>Well, after being alerted to config.template_src_dir_path a large chunk<br>of my concerns are mitigated. However if you did want to still enhance
<br>the rakefile to specify the location of the generated rhtml why keep the<br>location of the generated files out of the config file? From my<br>perspective, that info needs to be recorded so someone new can just be<br>
told, "run rake generate_rhtml" or whatever the command will be and bam,<br>it's done. If *I* have to type in a directory path each time it's a<br>guarantee I will mistype it once and get a bunch of rhtml files in the
<br>wrong directory.</blockquote><div><br><br>Currently the rake generate_rhtml does use the config locations to determine where to read and write to. However if you don't have the configuration set to write rhtml to file system, running this invokes the parser and all, but you won't see any output unless the config had been set to write_rhtml (probably not what you want). So we probably need a way for one to point to a different destination IO object via an arg. This would allow you to setup additional destinations in the config and just point to one of them via rake based on an argument, and if you mistype the argument, you'll get an error indicating that the IO object was not found and possibly mistyped. It would make it easy to re-run.
<br><br>Command could be something lilke <br><br>rake generate_rhtml DST_IO=foo<br><br>and foo would be setup in the config as a MasterView IO destination (could be the file system somewhere, in the future it could be a database location).
<br><br>Another thought about rendering the rhtml and cleaning up focuses on the cleaning up aspect. If a person sets his config to render the rhtml to file system and then decides to go back to the other way, then how does one cleanup. One idea was to have a rake command that could cleanup the rendered rhtml files. It would walk through the rendering process to determine what files it generates and then clean those up on the file system (so any other rhtml files that exist but were not generated would not be removed, knowing that some people may have mixed environments with some MasterView some direct (legacy) rhtml).
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">><br>> Second, could that process include some sort of pre-processing
<br>> where certain directories are copied to their "real" home, say<br>> /static/images goes to /public/images and /static/final/css goes to<br>> /public/stylesheets. You get the idea. I would be happy to help with
<br>> any of these changes as I think they would allow a nice separation<br>> between design and development worlds. If I'm insane feel free to<br>> point<br>> that out as well.<br>><br>
><br>><br>> I like those ideas as well. That makes it much easier to start from an<br>> existing prototype without having to manually move things into the<br>> right places. Let the application do it for you. Great idea! One
<br>> question, what should be the mechanism to configure this? Should one<br>> add these paths to the config settings or is there a better way? I<br>> don't know if we should just automatically look for files based on
<br>> extensions?? Any ideas along these lines?<br>><br>I like having everything in the config file, that way when you check out<br>the project from source control it's ready to rock. I would suggest 3<br>new lines in the config file, all having the same format:
<br><br>config.image_directory = ['app/html/images', 'public/images', ['gif',<br>'jpg', 'png']] # relative path from config.root_path<br> from directory to
<br>directory file extensions<br><br>Of course parameter #2 and #3 would be optional and default to<br>/public/whatever with the appropriate file extension(s). This would<br>allow various configurations, like your javascript in the main html dir
<br>mixed in with the html.<br><br>config.javascript_directory = ['app/html', 'public/javascript', ['js']]<br># javascript mixed in with regular html<br><br>or maybe<br><br>config.javascript_directory
= ['app/html', nil, ['js']] # javascript<br>mixed in with regular html, nil perhaps indicates "default"?<br><br>config.stylesheet_directory = ['app/html/css'] # stylesheets going to<br>default /public/stylesheets, no need to specify any other options
</blockquote><div><br><br>Yeah, I see where you are going with this. We could also go with something like this<br><br>config.auto_copy_files = {<br> 'app/html/images' => 'public/images', # copies everything in images including directories, keeps same structure in public/images
<br> ['app/html/myscripts', ['js']] => public/javascript', # copies all *.js files and subdirectories, keeping same structure<br> ['app/html/mycss', ['css', 'cs']] => public/stylesheets', # copies all *.css and *.cs files and subdirectories, keeping same structure
<br>}<br><br>This gives us an open ended way to copy anything and also to merge from multiple locations. So in the future if someone needs to copy anything else, they can do it without needing a code change. I also like the hash arrow syntax for indicating where we are copying to (kind of a directional visual indicator to help jog the mind of the syntax).
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Also, in keeping with the whole, edit => view changes nature of rails,<br>
it would be great if masterview could detect changes in these files and<br>do the auto-copy when you request a page. It's like above, if I have to<br>run a rake task each time, well that would get tedious very fast.<br>
Perhaps a config setting to auto-copy files vs waiting for the rake task?</blockquote><div><br><br>Seems like it might be nice to monitor these static files the the same way we monitor for changes in MasterView templates. We process on startup and then if in development mode we would check for changes on each request using timestamp, auto copying over any changes. In production mode only copy on startup and skip the currency checks.
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br>Any place I can help out?</blockquote><div><br><br></div></div>We can certainly use help in any area you would want to tackle now or anytime.
<br><br>If you would like to work on any of these enhancements, just let me know which one(s) and I can point you into the right direction in the code and make sure we don't step on each other's toes. <br><br>Our code is located at svn://rubyforge.org/projects/masterview/trunk/masterview (for the latest)
<br><br>Thanks,<br><br>Jeff<br>