On 1/19/07, goodieboy email@example.com wrote:
- integrate seamlessly
- provide an easy syntax
- give access to helpers just like the Rails template engine
- provide ability to create custom tags
The MasterView template engine currently meets some of your goals.
It will integrate seamlessly with Rails.
It provides an easy syntax (attribute based but very similar to the
native syntax for Rails helpers).
It provides full access to helpers, partials, layouts just like ERB.
The directives allow the content to inherit their style from the html
so that you can design with WYSIWYG editor.
It was designed from the ground up to be customizable and extensible
with custom directives (like tags but attribute based). The API was
refactored to use a DSL to simplify directive creation.
MasterView is designed to allow designers to WYSIWYG the templates,
while still allowing full power of ERB (partials, helpers). We are
developing some power attributes that simplify the creation of Ajax’d
The MasterView system has plugable IO framework allowing the templates
to exist anywhere (file system, DB, memory, etc.) however we have not
implemented the DB version yet. The hooks are there but just haven’t
gotten to it yet.
As for the safety of doing things, here is my take:
If you are allowing your trusted developers to make changes to these
templates, then this is not much different than having it on the file
system. Assuming you secure it behind user authentication to access
these files, then it is not much different. Much more convenient than
requiring someone to scp or ftp the files up. However this is ruby
code with the same access as your code on the filesystem, so it should
be given the same respect and code reviews.
However if you are wanting to allow generic users (not just your
developers) to be able to change the templates, then you will want to
either prevent them from using evaling code or to use some sort of
sandboxing. We are planning to add some non-evaling or sandboxed
directives to MasterView but that is still a little ways off. Doing
this today, you might consider using Liquid for that aspect of things
if you need to allow users to edit templates and not simply content.
Liquid can be used in conjunction with MasterView as well. Hendy
Irawan has done this for his site.
If it were me, I would take the approach of trying to limit the end
users from being able to directly change templates. Provide them a way
to change the content all they want. Give them a way to change the
CSS. If you have the right hooks into the content for CSS you would be
suprised about the layouts you can get just be changing this. Check
out http://www.csszengarden.com/ to see how drastically sites can be
changed with CSS alone. This should get you most of the way there and
it can be made be totally safe. Then if this doesn’t meet all your
needs, you might provide several canned template layouts that you
created and they can choose one of them. Beyond that check out using
Liquid possibly with MasterView depending on your needs.
If you have any questions about this, I will do my best to help. If
you would like to know more how MasterView works we have some
illustrations and screencasts on the site. http://masterview.org/ as
well as mailing lists, etc. (We are preparing a new release that fixes
some smaller issues with Rails 1.2, should be out in the next few
days, trunk already has fixes).
Jeff B., MasterView project founder
Inspired Horizons Ruby on Rails Training and Consultancy
Next Ruby on Rails plus JRuby workshop Feb 22-24 St. Louis, MO
Limited seating, register now!