<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2912" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
size=2>>> <FONT face="Times New Roman" size=3>I added the default generate
feature </FONT></FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
size=2>RE: rework in how Config handles parser options to protect against user
bashing the original hash and losing some of our settings</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006></SPAN><SPAN
class=445373915-30072006><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=445373915-30072006><FONT face=Arial
color=#0000ff size=2>~ Deb</FONT></SPAN></DIV></BODY></HTML>