Masterview devel - Jul 2006 - I added the default generate feature

I added the default generate feature we discussed prior. If you don''t
have
any mv:generate or mv:gen_partials in your template then it will add a
mv:generate="{template_path}" to either your body (if found) or the
root
element. If it adds to the body then it also adds in a mv:omit_tag=""
as
well.

I implemented this as a filter which uses a regex scan, so this made it
simple to tack on.

Since it is a filter it is configured using config.default_parser_options

I named the option for this filter :default_generate with a default value of
true, however if you think a different name would be clearer I am all ears.

I also noted that in our configuration if a user sets the hash absolutely
like
config.default_parser_options = { :tidy => true }
then they have effectively set tidy true, but also set all the others to
false including new ones that we would might add in the future. Since I
think we would rather just force users to set them to false when they want
them disabled and also allow us to pick up future options as they are
available, I changed the configuration slightly to take the users
default_parser_options and to merge them with the original set. This gives
us the desired effect in that future options are picked up by default, and
users can still disable by setting an option to false or nil.

I enabled the default_generate option in the interactive view as well so
that when they are testing things they can try out things easily.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060729/756fd6f5/attachment.html

>> I added the default generate feature 
 
Good, had been thinking further about that last week while at OSCON and I
think it''s a good default behavior.  Makes it easy to bring existing
content
pages into your rails app; just get the pages in and working, then you can
decide whether/how to start exploiting rails markup or revising the page to
fit into the site layout.  Might be mainly a transition strategy feature,
but useful nonethless.  Haven''t thought of a downside yet and if so the
feature can always be disabled.
 
Still contemplating whether parser options is the right place for that
setting, though; I think it may be more appropriate as a config setting
related to an input directory area.  I''m thinking through a case where
I may
want to be able to pull in content pages to map into a view section that
aren''t physically stored under app/views; that would also require
revisiting
our deferred item on being able to configure multiple i/o trees.  I''ll
play
with that this week, it ties into the area of my site that I''m trying
to get
reworked and published under rails.
 
RE: rework in how Config handles parser options to protect against user
bashing the original hash and losing some of our settings
 
Good spot, I wasn''t real happy with that area but hadn''t put
much thought
into cleaning it up.  I actually think I''d like to go back into that
one
more time and revise it to disallow direct access to the hash.  Maybe better
to have explicit get/set parser option protocol and not allow clients to
(inadvertantly) bash the options hash in the first place.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/masterview-devel/attachments/20060730/6c16d11f/attachment.html