First off, I think masterview is wickedly awesome. I''m converted both of my current projects over to it. Thank you Jeff for your presentation at MountainWest Ruby Conf. I don''t know why more buzz isn''t being generated about masterview, I seem to be the only one here in Phoenix really excited about it (that I know of). So with that said, I had a question on how people generally structure their view directory. I ask this because of a couple of problems I''ve run into. Here''s the situation. I have the xhtml given to me by our designer. It of course does not follow rails conventions, doesn''t have a public directory where the images and css goes, etc. Just to test masterview and get it started I dropped the xhtml structure into views and started adding directives. The problems I can see with this are twofold. A) if I ever need to turn on rhtml rendering it will be a horrid mess, I would like to have a "generated" area that I can safely blow away when I''m done needing to generate the rhtml. B) The stylesheet and image references, to work in both html design mode and rails rendering mode would have to be located in public which means the designers either have to know how rails lays out its files or I have to go and convert everything afterwards, neither of which sounds appealing. So, my question is, can I have my html parked in a directory such as static and have masterview look there to get its source files from? Second, could that process include some sort of pre-processing where certain directories are copied to their "real" home, say /static/images goes to /public/images and /static/final/css goes to /public/stylesheets. You get the idea. I would be happy to help with any of these changes as I think they would allow a nice separation between design and development worlds. If I''m insane feel free to point that out as well. David Koontz
Hi David, I''m not very experienced in this nice template plugin, but I think I have a answer for your question B.> B) The > stylesheet and image references, to work in both html design mode and > rails rendering mode would have to be located in public which means the > designers either have to know how rails lays out its files or I have to > go and convert everything afterwards, neither of which sounds > appealing. So, my question is, can I have my html parked in a directory > such as static and have masterview look there to get its source files > from? Second, could that process include some sort of pre-processing > where certain directories are copied to their "real" home, say > /static/images goes to /public/images and /static/final/css goes to > /public/stylesheets.to short, have another document root for your templates. here''s some hints. our project has the same directory structure as MasterView has in default, that is: RAILS_ROOT - public - stylesheets - images - app - views - controller - view.html you don''t need to touch anything of them. but you just set up RAILS_ROOT/app/views as a different document root or an alias from that of RAILS_ROOT/public. we''re using apache and our setup looks as following: <Location /project/> Options ExecCGI FollowSymLinks RewriteEngine On RewriteRule ^([^.]+)$ $1.html [QSA] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ dispatch.fcgi [QSA,L] </Location> Alias /project/ "/rails/root/public/" Alias /project "/rails/root/public/" Alias /project-templates/ "/rails/root/app/views/" so when you open your.domain/project/controller/view on your browser, you get rendered version and your.domain/project-templates/controller/view.html sends you the template. apache may not be very popular in rails world but you get some sense from it. the example above is configured with Location and Alias, but I''m sure that you can make a similar setting with virtual hosts. (change your domains instead.) hope this helps, hiro
On 4/3/07, David Koontz <david at koontzfamily.org> wrote:> > First off, I think masterview is wickedly awesome. I''m converted both > of my current projects over to it. Thank you Jeff for your presentation > at MountainWest Ruby Conf. I don''t know why more buzz isn''t being > generated about masterview, I seem to be the only one here in Phoenix > really excited about it (that I know of).Thanks for the kind words David. I think it''s just a new way of doing things and it takes time to get some traction (chicken and egg problem to some extent). There are a large number of Rails users who just won''t go off of the pure Rails track either, even though they should since more and more things are going to be made available via plugins going forward. Thanks for taking the time to write up your ideas, its these things that will propell MasterView forward and improve some of the difficult areas. My problem is that it is hard for me to know what the difficult areas are for people, so I am thankful for you to take the time to write this up. So with that said, I had a question on how people generally structure> their view directory. I ask this because of a couple of problems I''ve > run into. Here''s the situation. I have the xhtml given to me by our > designer. It of course does not follow rails conventions, doesn''t have > a public directory where the images and css goes, etc. Just to test > masterview and get it started I dropped the xhtml structure into views > and started adding directives. The problems I can see with this are > twofold.A) if I ever need to turn on rhtml rendering it will be a> horrid mess, I would like to have a "generated" area that I can safely > blow away when I''m done needing to generate the rhtml.I agree. We need an easy way to allow users to generate the rhtml to a new safe area other than the main project. I think this might best be served by using a rake command. We already have one that invokes the generator, but in addition it should take an argument about where to generate the rhtml. This would allow you to generate the rhtml to a specified location without having to touch your config and not pollute the main directory. I think this will be an easy change. Would this meet your needs? Alternatively one could have a different directory where all the MasterView source templates are stored (other than the normal location in app/views) and then we generate the rhtml into the normal app/views location. This could be accomplished by changing the config of where MasterView reads its files from, but a disadvantage is that new developers on the project would instinctively go to app/views and find the generated rhtml where they would edit things only to have it overwritten later. So this is an option too, but I think the enhancement to the rake command is a little better and safer. B) The> stylesheet and image references, to work in both html design mode and > rails rendering mode would have to be located in public which means the > designers either have to know how rails lays out its files or I have to > go and convert everything afterwards, neither of which sounds > appealing. So, my question is, can I have my html parked in a directory > such as static and have masterview look there to get its source files > from?Yes, we can change the directory of where MasterView reads from using the config.template_src_dir_path = ''yourstatic/masterview/dir'' Second, could that process include some sort of pre-processing> where certain directories are copied to their "real" home, say > /static/images goes to /public/images and /static/final/css goes to > /public/stylesheets. You get the idea. I would be happy to help with > any of these changes as I think they would allow a nice separation > between design and development worlds. If I''m insane feel free to point > that out as well.I like those ideas as well. That makes it much easier to start from an existing prototype without having to manually move things into the right places. Let the application do it for you. Great idea! One question, what should be the mechanism to configure this? Should one add these paths to the config settings or is there a better way? I don''t know if we should just automatically look for files based on extensions?? Any ideas along these lines? I will add both (rake generate enhancement and auto copy assets) of these onto my TODO list. Thanks for the input and ideas! Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20070404/49f12fe7/attachment.html
> > > So with that said, I had a question on how people generally structure > their view directory. I ask this because of a couple of problems > I''ve > run into. Here''s the situation. I have the xhtml given to me by our > designer. It of course does not follow rails conventions, doesn''t > have > a public directory where the images and css goes, etc. Just to test > masterview and get it started I dropped the xhtml structure into views > and started adding directives. The problems I can see with this are > twofold. > > > > A) if I ever need to turn on rhtml rendering it will be a > horrid mess, I would like to have a "generated" area that I can safely > blow away when I''m done needing to generate the rhtml. > > > > I agree. We need an easy way to allow users to generate the rhtml to a > new safe area other than the main project. I think this might best be > served by using a rake command. We already have one that invokes the > generator, but in addition it should take an argument about where to > generate the rhtml. This would allow you to generate the rhtml to a > specified location without having to touch your config and not pollute > the main directory. > > I think this will be an easy change. Would this meet your needs?Well, after being alerted to config.template_src_dir_path a large chunk of my concerns are mitigated. However if you did want to still enhance the rakefile to specify the location of the generated rhtml why keep the location of the generated files out of the config file? From my perspective, that info needs to be recorded so someone new can just be told, "run rake generate_rhtml" or whatever the command will be and bam, it''s done. If *I* have to type in a directory path each time it''s a guarantee I will mistype it once and get a bunch of rhtml files in the wrong directory.> > Alternatively one could have a different directory where all the > MasterView source templates are stored (other than the normal location > in app/views) and then we generate the rhtml into the normal app/views > location. This could be accomplished by changing the config of where > MasterView reads its files from, but a disadvantage is that new > developers on the project would instinctively go to app/views and find > the generated rhtml where they would edit things only to have it > overwritten later. So this is an option too, but I think the > enhancement to the rake command is a little better and safer.I think just having config.template_src_dir_path is good for externalizing your html files and then you can use the rake task to generate the rhtml if you need to debug. One point on not confusing devs though, if you do have files in app/views and aren''t using config.template_src_dir_path to make that directory external the devs are going to have to know what masterview is doing to make any sense of why there aren''t standard index.rhtml, edit.rhtml, etc. files. So I think spending effort to not confuse devs is not really going to pay you back as you can''t go very far without understanding what masterview is doing unless you have some other task to update your rhtml files whenever the html changes and the devs never edit the rhtml directly, not likely I think.> > > B) The > stylesheet and image references, to work in both html design mode and > rails rendering mode would have to be located in public which > means the > designers either have to know how rails lays out its files or I > have to > go and convert everything afterwards, neither of which sounds > appealing. So, my question is, can I have my html parked in a > directory > such as static and have masterview look there to get its source files > from? > > > > Yes, we can change the directory of where MasterView reads from using > the config.template_src_dir_path = ''yourstatic/masterview/dir'' >I really should have read the config docs before posting, most of my issues were solved by that one line.> > Second, could that process include some sort of pre-processing > where certain directories are copied to their "real" home, say > /static/images goes to /public/images and /static/final/css goes to > /public/stylesheets. You get the idea. I would be happy to help with > any of these changes as I think they would allow a nice separation > between design and development worlds. If I''m insane feel free to > point > that out as well. > > > > I like those ideas as well. That makes it much easier to start from an > existing prototype without having to manually move things into the > right places. Let the application do it for you. Great idea! One > question, what should be the mechanism to configure this? Should one > add these paths to the config settings or is there a better way? I > don''t know if we should just automatically look for files based on > extensions?? Any ideas along these lines? >I like having everything in the config file, that way when you check out the project from source control it''s ready to rock. I would suggest 3 new lines in the config file, all having the same format: config.image_directory = [''app/html/images'', ''public/images'', [''gif'', ''jpg'', ''png'']] # relative path from config.root_path from directory to directory file extensions Of course parameter #2 and #3 would be optional and default to /public/whatever with the appropriate file extension(s). This would allow various configurations, like your javascript in the main html dir mixed in with the html. config.javascript_directory = [''app/html'', ''public/javascript'', [''js'']] # javascript mixed in with regular html or maybe config.javascript_directory = [''app/html'', nil, [''js'']] # javascript mixed in with regular html, nil perhaps indicates "default"? config.stylesheet_directory = [''app/html/css''] # stylesheets going to default /public/stylesheets, no need to specify any other options Also, in keeping with the whole, edit => view changes nature of rails, it would be great if masterview could detect changes in these files and do the auto-copy when you request a page. It''s like above, if I have to run a rake task each time, well that would get tedious very fast. Perhaps a config setting to auto-copy files vs waiting for the rake task?> I will add both (rake generate enhancement and auto copy assets) of > these onto my TODO list. > > Thanks for the input and ideas! > > JeffAny place I can help out? David Koontz
Here''s another technique that can be used for structuring the rails view directory to deal with image and stylesheet refs so they work at design time. Won''t necessarily be the right solution in all cases, but happens to work nicely for a site I''m working on currently and can be used to get rid of the need for an outside designer to have to deal with the rails app dir structure. Basic approach: create local dirs in or alongside your app/views for stylesheets and images referenced from template .html files. Lets you write nice relative path refs to these resources (vs the rather awful .././../public/foo) and gives you option to just package up the views dir to hand off to a designer without them having to deal with the containing rails app dir structure in their environment. e.g., I have app/views/xstyles and app/views/ximages dirs in my rails view dir so I can write templates as: <link href="../xstyles/site.css" rel="stylesheet" type="text/css" /> <img src="../ximages/foo.gif" /> On *nix, these resource dirs can be symlinked to your rails app''s public dirs; on Windows or to decouple views from context dependency for design-time work, copy in some/all of the images you care about having rendered at design time and either copy stylesheets or create "relay" stylesheets in xstyles with the correct names but whose contents are obtained by using @import directive which references public/stylesheets. Note that having an "xstyles" dir for design-time refs can be also used to add/override styles that you might want only at design time, e.g., put special color on placeholder areas to remind yourself about something that gets filled in with real content by the runtime rendering. This approach works for styles as long as your pages are rendered using a rails layout which provides the real stylesheet refs in its header decl or if you use the MasterView config setting config.template_asset_base_ref_pattern[:stylesheets] with a suitable regexp to detect xstyles refs. The image refs will get mapped to your public resources at runtime if you set the MasterView config setting config.template_asset_base_ref_pattern[:images] with a regexp which matches your ximages references instead of/in addition the default regexp which detects public/images. Another approach to img ref mapping: install a custom masterview directive impl which is registered as a global directive to be applied to *all* <img> tags in your templates and handles src ref transformations. This is actually what I do since I don''t find the rails image helper fcn to be useful; my templates already have the necessary ref and my directive does some other mappings that I find useful on <img> elements. (I can post that if people are interested, it''s really easy to create this sort of directive now with the reworked directive infrastructure of the Nov. 0.3 release) ~ Deb
On 4/4/07, David Koontz <david at koontzfamily.org> wrote:> > > > > > > A) if I ever need to turn on rhtml rendering it will be a > > horrid mess, I would like to have a "generated" area that I can > safely > > blow away when I''m done needing to generate the rhtml. > > > > > > > > I agree. We need an easy way to allow users to generate the rhtml to a > > new safe area other than the main project. I think this might best be > > served by using a rake command. We already have one that invokes the > > generator, but in addition it should take an argument about where to > > generate the rhtml. This would allow you to generate the rhtml to a > > specified location without having to touch your config and not pollute > > the main directory. > > > > I think this will be an easy change. Would this meet your needs? > > Well, after being alerted to config.template_src_dir_path a large chunk > of my concerns are mitigated. However if you did want to still enhance > the rakefile to specify the location of the generated rhtml why keep the > location of the generated files out of the config file? From my > perspective, that info needs to be recorded so someone new can just be > told, "run rake generate_rhtml" or whatever the command will be and bam, > it''s done. If *I* have to type in a directory path each time it''s a > guarantee I will mistype it once and get a bunch of rhtml files in the > wrong directory.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. Command could be something lilke rake generate_rhtml DST_IO=foo 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). 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).> > > Second, could that process include some sort of pre-processing > > where certain directories are copied to their "real" home, say > > /static/images goes to /public/images and /static/final/css goes to > > /public/stylesheets. You get the idea. I would be happy to help > with > > any of these changes as I think they would allow a nice separation > > between design and development worlds. If I''m insane feel free to > > point > > that out as well. > > > > > > > > I like those ideas as well. That makes it much easier to start from an > > existing prototype without having to manually move things into the > > right places. Let the application do it for you. Great idea! One > > question, what should be the mechanism to configure this? Should one > > add these paths to the config settings or is there a better way? I > > don''t know if we should just automatically look for files based on > > extensions?? Any ideas along these lines? > > > I like having everything in the config file, that way when you check out > the project from source control it''s ready to rock. I would suggest 3 > new lines in the config file, all having the same format: > > config.image_directory = [''app/html/images'', ''public/images'', [''gif'', > ''jpg'', ''png'']] # relative path from config.root_path > from directory to > directory file extensions > > Of course parameter #2 and #3 would be optional and default to > /public/whatever with the appropriate file extension(s). This would > allow various configurations, like your javascript in the main html dir > mixed in with the html. > > config.javascript_directory = [''app/html'', ''public/javascript'', [''js'']] > # javascript mixed in with regular html > > or maybe > > config.javascript_directory = [''app/html'', nil, [''js'']] # javascript > mixed in with regular html, nil perhaps indicates "default"? > > config.stylesheet_directory = [''app/html/css''] # stylesheets going to > default /public/stylesheets, no need to specify any other optionsYeah, I see where you are going with this. We could also go with something like this config.auto_copy_files = { ''app/html/images'' => ''public/images'', # copies everything in images including directories, keeps same structure in public/images [''app/html/myscripts'', [''js'']] => public/javascript'', # copies all *.js files and subdirectories, keeping same structure [''app/html/mycss'', [''css'', ''cs'']] => public/stylesheets'', # copies all *.css and *.cs files and subdirectories, keeping same structure } 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). Also, in keeping with the whole, edit => view changes nature of rails,> it would be great if masterview could detect changes in these files and > do the auto-copy when you request a page. It''s like above, if I have to > run a rake task each time, well that would get tedious very fast. > Perhaps a config setting to auto-copy files vs waiting for the rake task?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.> > Any place I can help out?We can certainly use help in any area you would want to tackle now or anytime. 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. Our code is located at svn://rubyforge.org/projects/masterview/trunk/masterview (for the latest) Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20070405/01b02b68/attachment.html
On 4/5/07, Deb Lewis <djlewis at acm.org> wrote:> > > Another approach to img ref mapping: install a custom masterview directive > impl which is registered as a global directive to be applied to *all* > <img> > tags in your templates and handles src ref transformations. This is > actually what I do since I don''t find the rails image helper fcn to be > useful; my templates already have the necessary ref and my directive does > some other mappings that I find useful on <img> elements. > > (I can post that if people are interested, it''s really easy to create this > sort of directive now with the reworked directive infrastructure of the > Nov. > 0.3 release) > >I think this would be a nice example to have in our examples folder, with some info in the comments about what is specifically does. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20070405/484aca0a/attachment.html
On 4/5/07, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:> > > config.auto_copy_files = { > ''app/html/images'' => ''public/images'', # copies everything in images > including directories, keeps same structure in public/images > [''app/html/myscripts'', [''js'']] => public/javascript'', # copies all > *.js files and subdirectories, keeping same structure > [''app/html/mycss'', [''css'', ''cs'']] => public/stylesheets'', # copies > all *.css and *.cs files and subdirectories, keeping same structure > } >Or possibly this is clearer yet config.auto_copy_files << { :src => ''app/html/images'', :exts => [''gif'', ''jpg'', ''png''], :dst => ''public/images'' } # copy gif, jpg, png, keep subdir structure config.auto_copy_files << { :src => ''app/html/myscripts'', :dst => ''public/javascript'' } # copy all myscripts, keep subdir structure config.auto_copy_files << { :src => ''app/html/mycss'', :dst => ''public/stylesheet'' } # copy all mycss, keep subdir structure Thoughts? Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-users/attachments/20070406/97cc8711/attachment.html
The hash is fine from my perspective but personally I prefer less abbreviated names, :source vs :src and especially :extensions or :types vs :exts. David Koontz> On 4/5/07, *Jeff Barczewski* <jeff.barczewski at gmail.com > <mailto:jeff.barczewski at gmail.com>> wrote: > > > config.auto_copy_files = { > ''app/html/images'' => ''public/images'', # copies everything in > images including directories, keeps same structure in public/images > [''app/html/myscripts'', [''js'']] => public/javascript'', # > copies all *.js files and subdirectories, keeping same structure > [''app/html/mycss'', [''css'', ''cs'']] => public/stylesheets'', # > copies all *.css and *.cs files and subdirectories, keeping same > structure > } > > > > Or possibly this is clearer yet > > config.auto_copy_files << { :src => ''app/html/images'', :exts => > [''gif'', ''jpg'', ''png''], :dst => ''public/images'' } # copy gif, jpg, png, > keep subdir structure > config.auto_copy_files << { :src => ''app/html/myscripts'', :dst => > ''public/javascript'' } # copy all myscripts, keep subdir structure > config.auto_copy_files << { :src => ''app/html/mycss'', :dst => > ''public/stylesheet'' } # copy all mycss, keep subdir structure > > Thoughts? > > Jeff > > > ------------------------------------------------------------------------ > > _______________________________________________ > Masterview-users mailing list > Masterview-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-users
ditto [tho I don''t mind :dest rather than :destination]. But I definitely lean towards clear names at the expense of a bit more verbosity vs. unix-ish crypticness like :src. IMO generally easier for people to work with libraries when there''s a clear point of view on abbrevations [not], then they don''t have to remember what this package''s favorite variation of abbreviations are some set of termininology. Doesn''t eliminate the need/importance of clear, consistent choice of names on the part of the developer, but makes it easier for clients I think. ~ Deb -----Original Message----- From: masterview-users-bounces at rubyforge.org [mailto:masterview-users-bounces at rubyforge.org] On Behalf Of David Koontz Sent: Friday, April 06, 2007 1:32 PM To: masterview-users at rubyforge.org Subject: Re: [Masterview-users] View structure The hash is fine from my perspective but personally I prefer less abbreviated names, :source vs :src and especially :extensions or :types vs :exts. David Koontz