erector with latest rails and development roadmap proposal

[Viktor Trón]

Hi Alex and all,

I would like to do some work on erector and rails to make erector a super-duper out-of-the box solution as ruby-only templating for rails.
In order to bring erector development up to speed with the newest rails, I fixed a number of issues, see my pull request here

https://github.com/pivotal/erector/pull/36

I believe these are the minimal changes to resolve all dependency conflicts and make all tests run and pass with ruby 1.9.3 and rails 3.2.8
legacy rails 2 and rails 3.1 integrations also tested and all dandy
ruby 1.9.3 needs version conflict fix for wrong >= 0.6.2, see https://github.com/sconover/wrong/issues/23

outstanding minor issues:
- Jeweler and rubyforge: Releasing gems to Rubyforge is deprecated. See details at http://wiki.github.com/technicalpickles/jeweler/migrating-from-releasing-gems-to-rubyforge
- DEPRECATION WARNING: Passing a template handler in the template name is deprecated. You can simply remove the handler name or pass render :handlers => [:erb] instead

Following on from this, I am planning to add some more fixes to make erector rails3-sellable :)

• add tests and fixes for proper rails templating
• layouts (fix content_for to allow example in the doc work)
• add tests for widget embedding and mixed template handlers
  
• global config
• extract config for needs/variables propagation
  
• config generator for rails initializer
• add option erector binary to control base widget class to allow application-wide subclassing of Erector::Widget
• add flexibility of template name to widget class mapping to rails template handler
  
• config option to customize template2class
• config paths to allow for scaffold widget libraries outside app/views 
• support some existing view parameter handling solutions interact smoothly with needs and allow for rails default render to work with needs
  
• proffer
• decent_exposure
• ...
  

Let me know if you guys endorse this and/or have ideas
best
Vik

[Viktor Trón]

commits added to https://github.com/pivotal/erector/pull/36
because this still really belongs to minimum changes for latest rails integration
but now I freeze this pull request until Alex gets back.

• add tests and fixes for proper rails templating

• fix content_for to allow example in the doc work (returns empty string to avoid double rendering errors)
  
• add tests for widget+layout rendering and mixed template handlers
• modify render tests to fix deprecation warnings for rails >=3.2 (and make sure also passes under <3.2)
  

[Viktor Trón]

with wrong 0.6.3 all good now
https://github.com/pivotal/erector/pull/36#issuecomment-10380522

I went ahead of my pull request on my ubermaster branch https://github.com/zelig/erector/tree/ubermaster

• global settings extracted, implemented the usual way with mattr_accessors on the Erector module
• core and rails-specific configs are separated in erector/config and erector/rails/config respctively, config tests are separated too
  
• set defaults and overrides implemented and tested where used (e.g., output, output_spec)
• erector script also reads config
  
• AbstractWidget.prettyprint_default deprecated
  
• added rails3 initializer config generator with tests
• full test coverage and some doc change
  

Alex, please let me know your thoughts on both

thx

[Viktor Trón]

new pull request https://github.com/pivotal/erector/pull/38 with major changes
docs not complete yet

[Alex Chaffee]

> Alex, please let me know your thoughts on both

I haven't had time to look at all the Rails-related stuff. To be
honest, I've always considered Rails integration to be frustrating and
inelegant. Isn't there some brilliant way for us to just make it all
work in a nice, clean, isolated, Railtie-compatible way?

- A

[Alex Chaffee]

Oh, and of course...

> I would like to do some work on erector and rails to make erector a super-duper out-of-the box solution as ruby-only templating for rails.

Big fat YAY! for this.


--
Alex Chaffee - al...@stinky.com
http://alexchaffee.com
http://twitter.com/alexch

[Viktor Trón]

i really dont think it is that bad :)

isolation: all rails related is separated nicely, we could extract rails integration in a separate gem but for a project that 2 people use and updated so rarely, it is not worth it.

clean: rails specific helper delegation, widget renderer are just fine. template handler was indeed a little inelegant but with my new pull request i refactored path resolvers as it should be in rails 3. config with initializer generator also make it elegant.

i think the way rails integration specs are structured is a little unorthodox, but other than that the messy part is not rails integration but rather the widget class hierarchy

let me know what you would like to see different.