Your view on MasterView!

Has anybody tried (or will check out) the MasterView plugin? Anything
else similar to or better than this?

From http://wiki.rubyonrails.org/rails/pages/MasterView+Plugin
“MasterView is a ruby/rails optimized HTML/XHTML friendly template
engine. It is designed to use the full power and productivity of rails
including layouts, partials, and rails html helpers while still being
editable/styleable in a WYSIWYG HTML editor.”

What do you think/feel about it?

Doug,

If you decide to take a look at the project let me know what you think.

I just put it up on Rubyforge recently. I was planning on creating a
‘how it
works’ video and a bunch more documentation around it before I announced
it
on this list. I have just the bare minimum of documentation completed at
this point. I demonstrated the project at the St. Louis Ruby user group
this
past weekend to get some ideas about what questions I need to cover in
the
documentation.

However, all that being said it installs easily (as either gem or
plugin)
and has a generator to be able to get something up to try out, so one
can
try it out fairly easily.

I was hoping to get more of that done this week so I could announce on
the
list soon, but in the meantime, feelfree to email me directly if you run
into any problems or confusion. That will help me know where to focus my
documentation/video efforts.

I would also love to hear any ideas or things to add to the wish list
for
this. I am planning on adding an ajax table list component, database
storage
for masterview files, amongst other features. I also plan on making it
easy
for developers to add their own components(directives). To do this I
need
some good documentation and maybe some work on the api so that things
are
clear, but at least the system was designed with this in mind.

PS. In regards to your question about whether there is anything similar.
The
closest ones are Liquid, Amrita, and Kwartz, all of which are good
projects
(and inspired/shaped MasterView to some degree). In developing
MasterView I
had different goals than each of these projects. Some of the primary
goals
were:

  • 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
  • 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. Scaffold generate initial
    templates or work from existing html prototype.
  • Use one master file to drive all related sections, simplifying
    editing.
  • 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

Let me know if I can help with anything and would love to hear your
feedback.

Blessings,

Jeff

Jeff,

I read about the project and it’s pretty cool looking. You really nailed
integrating Ruby/Rails constructs into HTML. My one concern is it seemed
that everything had to be in one file. Rather than the “generation”
step,
where layouts, partials and RHTML are generated - would it make more
sense
to “execute” the templates directly? That would be a more natural
programming model for someone coming to it from RHTML/ERB.

Just my two cents - excellent work!

Thanks for the feedback, Justin.

A few others had mentioned the same concern about too many things in one
file. In actuality, you don’t have to put everything in one file, even
though that’s the way I generate it. You could use as many files as you
want, however the reason I put into one file is to make it more DRY so
that
if you are editing a layout that is used to wrap many different views. I
didn’t want to have this code duplicated, yet it needs to be there if
you
want to get a real picture of what it will look like in your WYSIWYG
editor
with everything wrapped around it like it should be.

To help things at design time, I use design time only stylesheets to
hide
the parts you are not working on in the WYSIWYG editor and I have some
runtime javascript to allow you to view a single part at a time when
viewing
standalone in browser (without rails running). This lets you visually
work
with one page at a time while still not having code duplicated. Of
course
when you look at the source it is all there and could get large going
that
route.

You can still split out into many files, if you want, it just won’t be
as
DRY. This might be necessary for larger projects or ones that share
layouts
heavily. We’ll have to kick some ideas around in this area to see if we
can
come up with anything to give you the best of both worlds. I could
create
some sort of rake task that lets you update the layouts of other files
from
the main one, that would allow you to break things out and yet still be
DRY.
It’s a little more complicated doing that, but it should work.

And yes, I had considered going direct from the masterview file calling
ERb
directly without generating intermediate (rhtml) files, and this could
be
the way we move in the future. However I decided to start with the
generation approach so that we could see what was being created and
executed
by ERb (so if anyone had any doubt they could simply look at the
generated
code). This allows one to learn by trying and will make it easy for
people
to find bugs in the code. It also has a side effect of allowing you to
generate the files on a different box and copy them to any rails server
even
one without the masterview plugin since they are pure ERb (however
that’s
not a big feature since we could have a rake option to generate those or
something). It was mainly done for debugging, clarity, and to start
simple
with the intent to re-evaluate at a later date. It is certainly
something
that can be changed going forward or maybe even be made configurable.

Thanks for taking the time to check it out and provide some feedback!! I
really appreciate it.

Jeff