From jeff.barczewski at gmail.com Wed Feb 7 08:41:05 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 7 Feb 2007 07:41:05 -0600 Subject: [Masterview-devel] New MasterView custom authorization mixin Message-ID: <19cda190702070541l533e3211k5a4c52d59ec9de9@mail.gmail.com> Deb, I have changed the authorization to use a configurable mixin like we discussed. The changes are in the trunk. See what you think and feel free to augment the documentation accordingly. I included a sample mixin in the examples/rails_admin_auth directory and the corresponding config to use it. Note that module name needs to be at root level since we can't easily do nested (namespaced modules), I am using const_get to turn string into constant for include. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070207/df0d0093/attachment.html From jeff.barczewski at gmail.com Wed Feb 7 12:13:50 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 7 Feb 2007 11:13:50 -0600 Subject: [Masterview-devel] More explanation of how admin page custom authorization works Message-ID: <19cda190702070913y3f344ee9qbc1aae32c64ca13b@mail.gmail.com> Just to explain what I currently have in place in the trunk. I have moved the check_authorization method out of the masterview_controller and put it in a mixin. Additionally I setup a config.admin_auth_mixin accessor which defaults to nil but if set to a hash can be used to set the mixin and method to use instead of our default auth method (which currently just checks if local_request?) I also created an example of an authorization mixin and put it in examples/rails_app_admin_auth/auth_local_request_mixin.rb which does the same was what we do now. I figured we can create other examples of other mechanisms in this folder later. The configuration goes like this config.admin_auth_mixin = { :file => 'lib/whatever', :module => :MyAuthModule, :method => :check_authorization } These are each optional, for instance if you provide file, then it will require this path (assuming relative to RAILS_ROOT). If you provide module name (string or symbol) then it will include this into Masterview controller. If you specify method name then it will use this for the before_filter call (defaulting to check_authorization if not provided). Let me know what you think. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070207/9e4e9735/attachment.html From djlewis at acm.org Thu Feb 8 10:57:30 2007 From: djlewis at acm.org (Deb Lewis) Date: Thu, 8 Feb 2007 07:57:30 -0800 Subject: [Masterview-devel] Review comments on admin page custom authorization In-Reply-To: <19cda190702070913y3f344ee9qbc1aae32c64ca13b@mail.gmail.com> Message-ID: <20070208155736.XUK4586.fed1rmmtao101.cox.net@fed1rmimpo01.cox.net> > > I have moved the check_authorization method out of the masterview_controller and put it in a mixin. Wrong granularity, I think. The method that should be pluggable via the mixin is *only* the allow_access? predicate, not the referencing check_authorization method of the admin controller. Factoring the latter involves the client inappropriately in the operation of the admin controller, which shows up in the more complicated way you had to rewrite the before_filter spec in MasterviewController. I think it's not the client's business to have anything to say about what happens if access is not allowed (the redirect) - that's the controller's business. So I think the original check_authorization should be put back into MasterviewController and the mixin is responsible for supplying the allow_access? predicate. I don't think it's necessary to allow plugins to change this method name - if you want to customize the access checking, provide a module which implements an allow_access? method which is mixed into the controller (and thus can assume it is invoked in an ApplicationController instance) Other observation is that the logic for actually doing the mixing-in is rather messy to have in MasterViewController itself. Would rather have that done as part of MV init, though I think we can't just put into init_mv_admin_pages as I'd wish because of load order/startup timing issues [expect that's why you've got what you've got]. But even given that I'd prefer to have some one-liner spec in MasterviewController for the actual mixing-in step. I think the solution is to push logic back into MV init which actually decides what file to require and does so and which records a value which can be accessed from the MasterView module (?constant or addition the recorded configuration?) which is the mixin module itself. Then class MasterviewController < ApplicationController include MasterView::MIO::DefaultGenerateMIOFilter include MasterView::ADMIN_AUTH_MIXIN # or whereever we record the actual module #assert we now have an instance method named :allow_access? defined before_filter :check_authorization, :except => [ :access_not_allowed ] ... end ~ Deb #----------------------------------------------------------------- #ORIGINAL IMPL WAS: #----------------------------------------------------------------- # Default implementation of authorization check # to restrict access to administrative services def allow_access? # a more general solution might look something like: # current_user && user_has_perm?('mv-admin') # backstop: only allow for developer testing on local machine local_request? end # Check that the current user has authorization to access admin operations def check_authorization if ! allow_access? redirect_to :action => :access_not_allowed end end #----------------------------------------------------------------- From djlewis at acm.org Thu Feb 8 11:05:07 2007 From: djlewis at acm.org (Deb Lewis) Date: Thu, 8 Feb 2007 08:05:07 -0800 Subject: [Masterview-devel] Review comments on admin page custom authorization Message-ID: <20070208160509.XFLY1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> p.s. do you want me to make a revision pass per my comments or do you want to do that (assuming you agree with what I suggested, that is!) This does seem like the right approach, in general - I can write a normal method in the normal way w/out worrying about access constraints from a block. Other variation might be for app developer to supply just the text of the allow_access? predicate method, which we'd then compile into the MasterViewController (similar to dynamically generated method installation), but that seems a bit odd - I like it better to write a proper, legit ruby module used as a mixin. ~ Deb From jeff.barczewski at gmail.com Thu Feb 8 11:07:54 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Thu, 8 Feb 2007 10:07:54 -0600 Subject: [Masterview-devel] Review comments on admin page custom authorization In-Reply-To: <20070208160509.XFLY1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> References: <20070208160509.XFLY1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> Message-ID: <19cda190702080807g31cdc54drab0657ec4569460a@mail.gmail.com> On 2/8/07, Deb Lewis wrote: > > p.s. do you want me to make a revision pass per my comments or do you want > to do that (assuming you agree with what I suggested, that is!) > > This does seem like the right approach, in general - I can write a normal > method in the normal way w/out worrying about access constraints from a > block. > > Other variation might be for app developer to supply just the text of the > allow_access? predicate method, which we'd then compile into the > MasterViewController (similar to dynamically generated method > installation), > but that seems a bit odd - I like it better to write a proper, legit ruby > module used as a mixin. > > Yes, I agree with your comments. If you have time to fix this up like you mentioned that would be great!! And I do think that we would have to have something in the masterview_controller (but could be one liner) to do the mixin since controllers get dropped and reloaded in development mode, so we are not necessarily going to be able to hook it from elsewhere and guarantee that it is rehooked if reloaded later. Thanks, Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070208/7bd242b3/attachment.html From djlewis at acm.org Thu Feb 8 11:14:40 2007 From: djlewis at acm.org (Deb Lewis) Date: Thu, 8 Feb 2007 08:14:40 -0800 Subject: [Masterview-devel] MV admin controller template mgmt UI Message-ID: <20070208161443.FDOT1306.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> We need at some point to revisit this guy's UI - a flat list of templates doesn't scale when your site starts to grow past a relatively small number of pages. Not sure if a lazy-loading tree is better solution, or perhaps a path-pattern entry field where user could type a pattern to match templates they want (or even some combi of filter pattern + dir tree...) ~ Deb From jeff.barczewski at gmail.com Thu Feb 8 11:40:08 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Thu, 8 Feb 2007 10:40:08 -0600 Subject: [Masterview-devel] MV admin controller template mgmt UI In-Reply-To: <20070208161443.FDOT1306.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> References: <20070208161443.FDOT1306.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> Message-ID: <19cda190702080840k16215a90nb2aed58500c2fdc8@mail.gmail.com> Agreed. I thought we supported any hierarchy of templates (that was the original intent), but maybe we lost this somewhere long the way. It shouldn't be hard to put back in. Jeff On 2/8/07, Deb Lewis wrote: > > We need at some point to revisit this guy's UI - a flat list of templates > doesn't scale when your site starts to grow past a relatively small number > of pages. > > Not sure if a lazy-loading tree is better solution, or perhaps a > path-pattern entry field where user could type a pattern to match > templates > they want (or even some combi of filter pattern + dir tree...) > > ~ Deb > > > _______________________________________________ > Masterview-devel mailing list > Masterview-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-devel > -- Jeff Barczewski, MasterView core team Inspired Horizons Ruby on Rails Training and Consultancy Next Ruby on Rails plus JRuby workshop Feb 22-24 St. Louis, MO http://inspiredhorizons.com/training/rails/index.html Limited seating, register now! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070208/f8a1e0f0/attachment.html From gauldong at gmail.com Thu Feb 8 21:01:06 2007 From: gauldong at gmail.com (Hendy Irawan) Date: Fri, 9 Feb 2007 02:01:06 +0000 Subject: [Masterview-devel] New MasterView custom authorization mixin In-Reply-To: <19cda190702070541l533e3211k5a4c52d59ec9de9@mail.gmail.com> References: <19cda190702070541l533e3211k5a4c52d59ec9de9@mail.gmail.com> Message-ID: <3c4c8fa60702081801m189faa4cr4870e1ba44f92648@mail.gmail.com> On 2/7/07, Jeff Barczewski wrote: > Deb, > > I have changed the authorization to use a configurable mixin like we discussed. > > The changes are in the trunk. > > See what you think and feel free to augment the documentation accordingly. I included a sample mixin in the examples/rails_admin_auth directory and the corresponding config to use it. Note that module name needs to be at root level since we can't easily do nested (namespaced modules), I am using const_get to turn string into constant for include. Wow seriously it seems lots have been improved since the last time I checked... :-) You guys rock!! -- Hendy Irawan Web: http://hendy.gauldong.net Mobile: +62 856 24889899 Yahoo Messenger: ceefour666 LinkedIn: http://www.linkedin.com/in/ceefour From jeff.barczewski at gmail.com Thu Feb 8 21:35:13 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Thu, 8 Feb 2007 20:35:13 -0600 Subject: [Masterview-devel] New MasterView custom authorization mixin In-Reply-To: <3c4c8fa60702081801m189faa4cr4870e1ba44f92648@mail.gmail.com> References: <19cda190702070541l533e3211k5a4c52d59ec9de9@mail.gmail.com> <3c4c8fa60702081801m189faa4cr4870e1ba44f92648@mail.gmail.com> Message-ID: <19cda190702081835o671de8bdw765440f2372e40c0@mail.gmail.com> On 2/8/07, Hendy Irawan wrote: > > On 2/7/07, Jeff Barczewski wrote: > > Deb, > > > > I have changed the authorization to use a configurable mixin like we > discussed. > > > > The changes are in the trunk. > > > > See what you think and feel free to augment the documentation > accordingly. I included a sample mixin in the examples/rails_admin_auth > directory and the corresponding config to use it. Note that module name > needs to be at root level since we can't easily do nested (namespaced > modules), I am using const_get to turn string into constant for include. > > Wow seriously it seems lots have been improved since the last time I > checked... :-) > > You guys rock!! > Thanks! We are trying :-) Deb is improving on this even a little more as we speak. We'll be rolling this and the rest of the changes/fixes into the next release (which we are hoping to pub out soon). Of course it is available now in the trunk for edge riders. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070208/4eb6ea9f/attachment.html From djlewis at acm.org Tue Feb 13 13:51:55 2007 From: djlewis at acm.org (Deb Lewis) Date: Tue, 13 Feb 2007 10:51:55 -0800 Subject: [Masterview-devel] Revised version of customized admin access check Message-ID: <20070213185211.MMCA21668.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> Jeff - I reworked your initial version of allowing app developers to customize the MasterView admin auth checking, per our discussions of factoring and use of mixins. Before I commit, see below for summary of the new version. ~ Deb -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- By default, the MV admin controller restricts access to local requests (essentially, developer testing configuration). To provide customized access checking for your application, you can override the default auth checking by providing a mixin module for the MV admin controller which implements a predicate method named allow_access?. The mixin is installed in an ApplicationController subclass, so your allow_access? method has access to all standard Rails controller services as well as any services defined in your ApplicationController (notably your own authentication and authorization methods). By default, if you implement your mixin as module MasterViewAdminAuthMixin and place it in file admin_auth_mixin.rb in your rails app/masterview directory (alongside any custom directives in app/masterview/directives), MasterView will automatically install your allow_access? method in the admin controller's auth check. If you want to use a different module name or load the mixin module from a different location, specify this information in the MasterView admin_auth_mixin config setting in your config/masterview/settings.rb or env-specific settings. # To load a different file from app/masterview or use a different module name: # # config.admin_auth_mixin = { # :file => 'alt_admin_auth_mixin', # module file in #{RAILS_ROOT}/app/masterview dir # :module => :AltMasterViewAdminAuthMixin, # default is :MasterViewAdminAuthMixin # } # # To load a mixin from the rails app's lib directory: # # config.admin_auth_mixin = { # :file => 'lib/custom/mv_admin_auth_mixin', # module file in rails lib dir # :file_loc => :RAILS_ROOT, # default location for rel refs is #{RAILS_ROOT}/app/masterview # :module => :CustomMasterViewAdminAuthMixin, # default is :MasterViewAdminAuthMixin # } -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- From jeff.barczewski at gmail.com Tue Feb 13 14:11:32 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Tue, 13 Feb 2007 13:11:32 -0600 Subject: [Masterview-devel] Revised version of customized admin access check In-Reply-To: <20070213185211.MMCA21668.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> References: <20070213185211.MMCA21668.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> Message-ID: <19cda190702131111o6e2dfb8dx905d2f34ad0750b2@mail.gmail.com> Deb, This looks great! I like how it came out. I'm glad we have the flexibility to load from anywhere in RAILS_ROOT too since they might be running from a gem, in which case they will want to load from elsewhere. What you have here gives us that flexibility. So commit when you are ready. Jeff On 2/13/07, Deb Lewis wrote: > > Jeff - I reworked your initial version of allowing app developers to > customize the MasterView admin auth checking, per our discussions of > factoring and use of mixins. > > Before I commit, see below for summary of the new version. > > ~ Deb > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > By default, the MV admin controller restricts access to local requests > (essentially, developer testing configuration). > > To provide customized access checking for your application, you can > override > the default auth checking by providing a mixin module for the MV admin > controller which implements a predicate method named allow_access?. The > mixin is installed in an ApplicationController subclass, so your > allow_access? method has access to all standard Rails controller services > as > well as any services defined in your ApplicationController (notably your > own > authentication and authorization methods). > > By default, if you implement your mixin as module MasterViewAdminAuthMixin > and place it in file admin_auth_mixin.rb in your rails app/masterview > directory (alongside any custom directives in app/masterview/directives), > MasterView will automatically install your allow_access? method in the > admin > controller's auth check. > > If you want to use a different module name or load the mixin module from a > different location, specify this information in the MasterView > admin_auth_mixin config setting in your config/masterview/settings.rb or > env-specific settings. > > # To load a different file from app/masterview or use a different > module > name: > # > # config.admin_auth_mixin = { > # :file => 'alt_admin_auth_mixin', # module file in > #{RAILS_ROOT}/app/masterview dir > # :module => :AltMasterViewAdminAuthMixin, # default is > :MasterViewAdminAuthMixin > # } > # > # To load a mixin from the rails app's lib directory: > # > # config.admin_auth_mixin = { > # :file => 'lib/custom/mv_admin_auth_mixin', # module file in rails > lib dir > # :file_loc => :RAILS_ROOT, # default location for rel refs is > #{RAILS_ROOT}/app/masterview > # :module => :CustomMasterViewAdminAuthMixin, # default is > :MasterViewAdminAuthMixin > # } > > -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- > > > _______________________________________________ > Masterview-devel mailing list > Masterview-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/masterview-devel > -- Jeff Barczewski, MasterView core team Inspired Horizons Ruby on Rails Training and Consultancy Next Ruby on Rails plus JRuby workshop Feb 22-24 St. Louis, MO http://inspiredhorizons.com/training/rails/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070213/a6f3a318/attachment-0001.html From djlewis at acm.org Tue Feb 13 19:27:07 2007 From: djlewis at acm.org (Deb Lewis) Date: Tue, 13 Feb 2007 16:27:07 -0800 Subject: [Masterview-devel] Code review request: mv Configuration#add_plugin_directives Message-ID: <20070214002710.SWQW21177.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net> Jeff - look this over and let me know what you think. I desk-checked the rails 1.2.2 config/init logic to confirm that this should also work on 1.2. I'm using this in my own site right now, not sure if this is solid enough to expose as part of MasterView. Tho if you think this looks reasonable we can put out an inquiry on the users list to see if this has wider interest. Background: I'm finding it useful to package a masterview directives dir in plugins that I build for my apps and want a simple notation in my masterview config to say "add all {plugin_dir}/directives directories found on my rails plugin load path to the masterview directives load path". There doesn't seem to be a clear, separable notion of "the plugin directories" in rails, so with regret I cloned the find_plugins method out of rails's init logic so I could build find_plugin_directives on top of that. This implementation does not support the new notion in rails 1.2 that allows app developer to configure the *order* in which plugins are loaded. ~ Deb From djlewis at acm.org Tue Feb 13 19:27:07 2007 From: djlewis at acm.org (Deb Lewis) Date: Tue, 13 Feb 2007 16:27:07 -0800 Subject: [Masterview-devel] Revised version of customized admin access check In-Reply-To: <20070213185211.MMCA21668.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> Message-ID: <20070214002710.XAGO1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> Jeff - commited. I changed the example so it follows the default module naming convention. Suggest we also rename the file from examples/rails_app_admin_auth/auth_local_request_mixin.rb to the default name admin_auth_mixin.rb so that someone can copy that directly to their app/masterview dir and simple customize, w/out having to add mv config settings to pick up alt file name or mixin module name. ~ Deb From jeff.barczewski at gmail.com Tue Feb 13 22:57:46 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Tue, 13 Feb 2007 21:57:46 -0600 Subject: [Masterview-devel] Revised version of customized admin access check In-Reply-To: <20070214002710.XAGO1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> References: <20070213185211.MMCA21668.fed1rmmtao102.cox.net@fed1rmimpo01.cox.net> <20070214002710.XAGO1349.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net> Message-ID: <19cda190702131957s2e4a7191x535e0feed2da67d4@mail.gmail.com> On 2/13/07, Deb Lewis wrote: > > Jeff - commited. > > I changed the example so it follows the default module naming convention. > Suggest we also rename the file from > examples/rails_app_admin_auth/auth_local_request_mixin.rb to the default > name admin_auth_mixin.rb so that someone can copy that directly to their > app/masterview dir and simple customize, w/out having to add mv config > settings to pick up alt file name or mixin module name. > Yes, I agree, with the way you have things it makes sense to have the name ready to go so they can copy it in there and run. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070213/9996dbec/attachment.html From jeff.barczewski at gmail.com Tue Feb 13 23:15:06 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Tue, 13 Feb 2007 22:15:06 -0600 Subject: [Masterview-devel] Code review request: mv Configuration#add_plugin_directives In-Reply-To: <20070214002710.SWQW21177.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net> References: <20070214002710.SWQW21177.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net> Message-ID: <19cda190702132015t4dc068beka4cedc8671c7e39c@mail.gmail.com> On 2/13/07, Deb Lewis wrote: > > Jeff - look this over and let me know what you think. I desk-checked the > rails 1.2.2 config/init logic to confirm that this should also work on 1.2 > . > > I'm using this in my own site right now, not sure if this is solid enough > to > expose as part of MasterView. Tho if you think this looks reasonable we > can > put out an inquiry on the users list to see if this has wider interest. > > Background: I'm finding it useful to package a masterview directives dir > in > plugins that I build for my apps and want a simple notation in my > masterview > config to say "add all {plugin_dir}/directives directories found on my > rails > plugin load path to the masterview directives load path". > > There doesn't seem to be a clear, separable notion of "the plugin > directories" in rails, so with regret I cloned the find_plugins method out > of rails's init logic so I could build find_plugin_directives on top of > that. > > This implementation does not support the new notion in rails 1.2 that > allows > app developer to configure the *order* in which plugins are loaded. > > Looks good to me. I am fine with including this especially if you find it useful for your own work, those are exactly the kinds of changes we should put in. And if I understand correctly this is optionally called from config by adding in config.add_plugin_directives(...). Thus if one doesn't call that method on config then this code isn't even invoked. So I think it looks good. If you want to hold off on publicizing that for a while we can do that, but otherwise I think it sounds like a good add and lets get it in there. So I think we are getting close to a release here. I need to take a quick look if I can fix Ed's problem he found and then we should get it out there. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070213/84ddbef1/attachment.html From jeff.barczewski at gmail.com Tue Feb 20 14:01:27 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Tue, 20 Feb 2007 13:01:27 -0600 Subject: [Masterview-devel] Are we in a good place to do a MasterView release? Message-ID: <19cda190702201101r300ac6b9k4b60e8c977c41d92@mail.gmail.com> Just checking to see if we ready to do a MasterView release. The new code seems to fix Ed's issue, fixed the blank screen on Rails 1.2bad view rhtml, and we have added the customizable authorization. I am ready on this end. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070220/591a8d15/attachment.html From deblewis at cox.net Tue Feb 20 15:30:01 2007 From: deblewis at cox.net (deblewis at cox.net) Date: Tue, 20 Feb 2007 12:30:01 -0800 Subject: [Masterview-devel] Are we in a good place to do a MasterView release? Message-ID: <26281094.1172003401315.JavaMail.root@fed1wml12.mgt.cox.net> Jeff - ok by me, I think, the rework of the admin config hooks was my main thing for now. Documenting my other addition of add-plugin-path-directives can wait for a point update. and in any case I'm hosed for the day, so I can't do anything right now - in SF for meetings all day and last night the latest batch of windows security patches hosed something in the system drivers so my machine doesn't boot at all, I'm completely trashed until I can (hopefully!!) get some help salvaging the system config in the morning. I'm borrowing a colleague's web browser right now for emergency mail checking ~ Deb ---- Jeff Barczewski wrote: > Just checking to see if we ready to do a MasterView release. > > The new code seems to fix Ed's issue, fixed the blank screen on Rails > 1.2bad view rhtml, and we have added the customizable authorization. > > I am ready on this end. > > Jeff From jeff.barczewski at gmail.com Wed Feb 21 12:25:41 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Wed, 21 Feb 2007 11:25:41 -0600 Subject: [Masterview-devel] [ANN] MasterView rails-optimized (x)html friendly template engine - Release 0.3.2 Message-ID: <19cda190702210925w7a3f77bcof399218f1349d012@mail.gmail.com> MasterView is a rails-optimized (x)html friendly template engine plugin that provides another option to the existing rails view templates (rhtml and rxml). The main idea is to provide a template engine that would provide all the power of layouts, partials, and rails helpers but still be editable/styleable in a WYSIWYG editor. It was also a major goal that the syntax of these attribute directives be very similar to rails helpers so that one could intuitively start using MasterView with little learning curve other than knowing rails. MasterView was inspired by Amrita, Kwartz, Tapestry, Zope/PHP TAL, Liquid, and Web Objects but designed with a fresh approach and specifically targetted for rails users. Releae 0.3.2 is primarily a maintenance release to fix a minor incompatibility with Rails 1.2.2 which was causing a blank screen on a view compile error rather than the normal debug output. Also there was a defect in the parameter parsing when using multiple parameters that was corrected. Finally the authorization mechanism for accessing the MasterView admin pages was made customizable by allowing a user configurable module to be used. Tested with Rails 1.2.2 Release 0.3.1 was a maintenance release addressing an issue with ruby 1.8.5(wrong number of arguments 1 for 2 during scaffold generation), fixing a problem with the deprecated/directive_base used for custom directives, updating a few out of date docs, and accomodating a change to the API of the Rails 1.2 generator. Release 0.3.0 was a major release for MasterView with an emphasis on refactoring and simplifying the API for building directives. A DSL syntax was chosen to greatly simplify the creation of directives to both help the core team with directive development as to also enable developers to create their own custom directives easily. MasterView has been constructed to allow directives to be shared amongst the community and this refactoring will enable custom development. To further enhance sharing and prevent collisions, this release introduces custom namespaces to the directives allowing users to create their own namespaces to prevent conflict. Namespaces as well as many other metadata about directives can now be configured at both the app-level and installation-level providing flexibility. Video A short video which demos the basic operation is available at http://masterview.org/videos/demo_short.html Screenshots and illustrations http://masterview.org/media_list.html MasterView is released under MIT open source licensing. Main site: http://masterview.org/ Rubyforge Project site: http://rubyforge.org/projects/masterview Goals - Create/extend a template engine for rails that would be XHTML friendly and thus could be edited/styled with a WYSIWYG HTML editor even late in development without breaking template. - Keep it simple. DRY. No extra config files, simple syntax with ruby flavor. - Design it specifically for ruby and rails. Use the full power and not be limited in its capabilities over what can be done with ERb (rhtml) - Work nicely with layouts, partials, and rails html helpers. - Reduce complexity, work with existing rails code, no extra view logic or hashes than what is used by ERb (rhtml). Scaffold generate initial templates or work from existing html prototype. Make scaffolds nicely styled and easily useable for production with minor changes. - Reduce the numbers of files, simplifying editing. Define partials and layouts naturallyl right in the template, no need to go to another file. - Preview in browser without running an app. Allow for dummy data in the template so that the page can be viewed and styled independently of the application. - Performance equal to ERb (rhtml) Release Notes: == Recent changes (Release 0.3.2 - Maintenance release plus custom admin auth) This release addresses a compatibility problem with Rails 1.2 where a view syntax error would not display the normal debug output but instead displayed only a blank screen. Also fixed a parsing problem with multiple parameters in some directives. Added the ability to use custom mixin for authorization to MasterView admin screens. Changed the MasterView generator to use request, flash, and params rather than deprecated @request, @flash, and @params. Tested with Rails 1.2.2 == Recent changes (Release 0.3.1 - Maintenance release This release addresses an issue with ruby 1.8.5, fixes a problem with the deprecated/directive_base used for custom directives, updates a few out of date docs, and accomodates a change to the API of the Rails 1.2 generator == Recent changes (Release 0.3.0 - Major update - refactoring of directive API (for developing directives) The directive API for creating directives has been refactored and simplified. This will enable directives to be developed more easily by both core developers and MasterView users. The end goal is to make it extremely simple for anyone to create their own custom directives and to share those with the community, and thus the project can live and grow into many specialty areas. The directive API refactoring is one more step towards those goals. The old directive_base.rb which provided the API for directives has been deprecated and moved to deprecated/directive_base.rb, MasterViewdevelopers which have developed custom directives should upgrade those directives to the new API as soon as possible. During the transition period one can use the original API by requiring the deprecated/directive_base.rb file and changing their directive to inherit from DirectiveBaseOld rather than DirectiveBase. == Recent changes (Release 0.2.5) Fix AdminPage compatibility with Rails 1.1.5+ which uses safe_load_paths to find controllers Fix rake mv:view_rhtml RHTML=foo/_bar.rhtml was not able to find partials Visit the online documentation page at http://masterview.org/ for screenshots, illustrations, complete installation and usage information. We would love to hear your feedback and ideas around this project! Visit the rubyforge project to join the users mailing list or to add yourself to the announce list to receive future announcements. Check out the videoto see MasterView in action! Thanks for your time!! MasterView Development Team Jeff Barczewski and Deb Lewis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070221/1807b9cf/attachment-0001.html From jeff.barczewski at gmail.com Mon Feb 26 17:12:36 2007 From: jeff.barczewski at gmail.com (Jeff Barczewski) Date: Mon, 26 Feb 2007 16:12:36 -0600 Subject: [Masterview-devel] Combine Layout + Theme == Multiple Look & Feel for Masterview... In-Reply-To: <4209097b0702211248q5100fb01qef4999ebaa10e703@mail.gmail.com> References: <4209097b0702211248q5100fb01qef4999ebaa10e703@mail.gmail.com> Message-ID: <19cda190702261412g26f60d01w55b429722639cf5@mail.gmail.com> On 2/21/07, Dino Lopez wrote: > > I wonder if you guys see Layoutgala [ http://blog.html.it/layoutgala/ ] > > Maybe for the support to layouts Masterview can combine Layout + Theme. > the layout will control the Regions and the Theme will define the colors of > the Layout. > > Layout: http://blog.html.it/layoutgala/ > Theme: Green [ Default Masterview with no extra graphics ] > > Masterview can combine Layout with Themes for change the Look & Feel of > the Sites. > > Extra graphics always can be added just like CSSZenGarden does it. this > will allow to have instant sites in no time. > > I wonder if would be necesary to create a gem for Layout+Theme or > integrate this as part of the Masterview gem. then just add the Layout and > Theme of the site with: Seems like a nice idea. gem install masterview_theme_template_pack > > How hard would it be to change the application with: > > ./script/generate masterview layout 1 theme green [ Where Layout indicates > the first in the Layout repository and geen the Theme color ] I believe we already have a command line switch to allow it to use an existing custom css, but it sounds like maybe you are suggesting that it can use a different generator source as well? I will take a look at the code to see what we would need to change to support this. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20070226/4e23c275/attachment.html