From jeff.barczewski at gmail.com  Wed Nov  1 11:28:54 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 1 Nov 2006 10:28:54 -0600
Subject: [Masterview-devel] [masterview] [ticket] tags...
In-Reply-To: <3c4c8fa60610312233y3c9a49bfk902fe89b14de2feb@mail.gmail.com>
References: <3c4c8fa60610312233y3c9a49bfk902fe89b14de2feb@mail.gmail.com>
Message-ID: <19cda190611010828y5eb6a803o61f1af4944ed69ed@mail.gmail.com>

On 11/1/06, Hendy Irawan <gauldong at gmail.com> wrote:
>
> I'm not sure if I like the {{{ tags }}} of MasterView.



Yeah, simply there for anyone who wants to do something else in raw erb in a
format that doesn't violate xhtml.


I find most of these tags only work well for simply printing a
> variable, for anything else, especially if/else for/while/loops I
> prefer the raw erb way.
>
> In Liquid though, I find the use of {{ tags }} understandable.  In
> MasterView, I don't know if I really need it. I like the XHTML
> namespace way in MasterView much more than using {{{ tags }}}



Right in MasterView you can simply pub an mv:if, mv:else, mv:block
(iterator), or use partials so you don't end up needing those other things
much at all.


Is there an option to disable this feature?



I will forward this question on to Deb since she has been enhancing the
configuration most recently. This feature is done with a single directive so
if it were removed from the load path then it wouldn't be utilized. I will
ask her if we have a nice way to not load directives in the configuration.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/66c649dc/attachment.html 

From djlewis at acm.org  Wed Nov  1 12:20:42 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 1 Nov 2006 09:20:42 -0800
Subject: [Masterview-devel] Release readiness, take 2
Message-ID: <20061101172044.QMLB22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>

Jeff - I thought it would be useful to find better namespace homes than the
top-level MasterView module for a few orphan gadgets that are mainly just
pieces of internal facilities (AttrStringParser, EscapeErbHelper and
TidyHelper from filter_helpers), but I kind of ran out of gas - wasn't quite
clear where to put them in the existing nested module structure and I didn't
want to introduce any new ones.

The latter two kind of go into TemplateProcessing for the parser, but then
they're also used from MIO.  AttrStringProcessor generally goes with
DirectiveProcessing, but only if we expand that module's point of view on
what it is - it currently thnks that it's simply the DirectiveDSL
infrastructure, which is a bit more constrained than general "directive
processing services".

So unless you have a clear point of view on where these belong in the
namespace structure, I'm declaring defeat for the moment and giving up,
let's just leave'em where they are for now.

~ Deb



From djlewis at acm.org  Wed Nov  1 12:58:39 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 1 Nov 2006 09:58:39 -0800
Subject: [Masterview-devel] [masterview] [ticket] tags...
In-Reply-To: <19cda190611010828y5eb6a803o61f1af4944ed69ed@mail.gmail.com>
Message-ID: <20061101175841.REXO22977.fed1rmmtao08.cox.net@fed1rmimpo02.cox.net>

Disabling the {{{...}}} notation processing feature is not currently
supported, but it wouldn't be hard to do and might be a useful perf knob to
have available.
 
RE: disabling the builtin directive implementation from MasterView which
processes this notation during template processing - the upcoming 0.3.0
MasterView release has a major rework of the directive mechanisms and
included in that is a much more powerful approach to managing the loading
and configuration of directives.  I haven't hooked it up yet, but have been
considered providing an "ignore these directives" option for directive
loading.   So that would certainly be one way the app to control this - in
their masterview settings, add an option setting on the directive path entry
for the builtin directives and put this inline-erb directive on the "ignore,
don't load" list.  [probably would provide a convenience service on
Configuration to make this simple to specify]
 
There's also an alternative approach for this kind of "global directive"
which by default is always applied, which would involve some alternate
techniques for providing directive-specific configuration options that we're
considering but haven't yet fully worked out.  Have to think about that area
a bit more.
 
Note that MasterView actually has two places where this "inline erb"
notation shows up.
 
First, there are configuration options to hook up some preprocessing filters
on incoming templates, one of which (on by default) maps <%..%>. markup in
the incoming document into {{{...}}} notation
 
http://masterview.org/configuration.html#mv_template_parsing_options
 
Then during template processing we handle mapping any uses of {{{...}}}
notation in the template into normal erb markup for rhtml.  And right now
that syntactic sugar processing is always done; there's currently no way for
client to disable that processing if they decide they don't like the
notation and don't want to incur the associated processing cost.
 
So if we want to allow app configs to disable the output processing when
this feature isn't desired, we'd want to check/ensure consistency of the
preprocessing filter setting.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, November 01, 2006 8:29 AM
To: Hendy Irawan; djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [masterview] [ticket] tags...


On 11/1/06, Hendy Irawan <gauldong at gmail.com> wrote: 

I'm not sure if I like the {{{ tags }}} of MasterView.



Yeah, simply there for anyone who wants to do something else in raw erb in a
format that doesn't violate xhtml.
 


I find most of these tags only work well for simply printing a
variable, for anything else, especially if/else for/while/loops I
prefer the raw erb way.

In Liquid though, I find the use of {{ tags }} understandable.  In 
MasterView, I don't know if I really need it. I like the XHTML
namespace way in MasterView much more than using {{{ tags }}}



Right in MasterView you can simply pub an mv:if, mv:else, mv:block
(iterator), or use partials so you don't end up needing those other things
much at all. 
 


Is there an option to disable this feature?



I will forward this question on to Deb since she has been enhancing the
configuration most recently. This feature is done with a single directive so
if it were removed from the load path then it wouldn't be utilized. I will
ask her if we have a nice way to not load directives in the configuration. 

Thanks,

Jeff


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/372f9a6e/attachment.html 

From djlewis at acm.org  Wed Nov  1 13:04:37 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 1 Nov 2006 10:04:37 -0800
Subject: [Masterview-devel] [masterview] [ticket] tags...
In-Reply-To: <19cda190611010828y5eb6a803o61f1af4944ed69ed@mail.gmail.com>
Message-ID: <20061101180439.YIPX16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>

Jeff - question for you about our impl of the filter preprocessing, you
probably know this faster than my brain can work through the code paths:
 
Parser.process explictly checks and applies preprocessing filters for tidy
and inline-erb mapping - this is longstanding code.
 
But we also have EscapeErbMIOFilter being hooked in by
default_mio_filter_block in MasterViewIOTreeMixin.
 
This is rather confusing to have similar things done in such different
sites/ways in the code - are these really disjoint and handling different
invocation cases?  Or is the parser's explicit checks superseded (and
duplicating?!) the way we hook this stuff in now with filters configured on
an MIOTree?
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/b03e9642/attachment-0001.html 

From jeff.barczewski at gmail.com  Wed Nov  1 13:48:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 1 Nov 2006 12:48:04 -0600
Subject: [Masterview-devel] [masterview] [ticket] tags...
In-Reply-To: <20061101180439.YIPX16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
References: <19cda190611010828y5eb6a803o61f1af4944ed69ed@mail.gmail.com>
	<20061101180439.YIPX16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190611011048h6ffac62coed3c26c08b1da276@mail.gmail.com>

On 11/1/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - question for you about our impl of the filter preprocessing, you
> probably know this faster than my brain can work through the code paths:
>
> Parser.process explictly checks and applies preprocessing filters for tidy
> and inline-erb mapping - this is longstanding code.
>
> But we also have EscapeErbMIOFilter being hooked in by
> default_mio_filter_block in MasterViewIOTreeMixin.
>
> This is rather confusing to have similar things done in such different
> sites/ways in the code - are these really disjoint and handling different
> invocation cases?  Or is the parser's explicit checks superseded (and
> duplicating?!) the way we hook this stuff in now with filters configured on
> an MIOTree?
>


yeah, I was just looking at that the other day. It needs to be cleaned up. I
think one was left in for unit tests to be able to do things without an
MIOTree object, however we really should be using the same mechanism for
things. I was going to double check this myself but I don't believe that it
passes any options in when coming from MIO so the escaping should only be
done once, but this is confusing and should be cleaned up.

We should just use MIO to handle all this and not have the additional calls
in Parser to Tidy and escaping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/5c0c4785/attachment.html 

From jeff.barczewski at gmail.com  Wed Nov  1 19:58:15 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 1 Nov 2006 18:58:15 -0600
Subject: [Masterview-devel] Release readiness, take 2
In-Reply-To: <20061101172044.QMLB22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>
References: <20061101172044.QMLB22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190611011658w5baab645r73145dbfedac6d11@mail.gmail.com>

On 11/1/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - I thought it would be useful to find better namespace homes than
> the
> top-level MasterView module for a few orphan gadgets that are mainly just
> pieces of internal facilities (AttrStringParser, EscapeErbHelper and
> TidyHelper from filter_helpers), but I kind of ran out of gas - wasn't
> quite
> clear where to put them in the existing nested module structure and I
> didn't
> want to introduce any new ones.
>
> The latter two kind of go into TemplateProcessing for the parser, but then
> they're also used from MIO.  AttrStringProcessor generally goes with
> DirectiveProcessing, but only if we expand that module's point of view on
> what it is - it currently thnks that it's simply the DirectiveDSL
> infrastructure, which is a bit more constrained than general "directive
> processing services".
>
> So unless you have a clear point of view on where these belong in the
> namespace structure, I'm declaring defeat for the moment and giving up,
> let's just leave'em where they are for now.



I think that is fine for now. We can restructure later if we need to, but
not a critical thing.

I hope to take one more look at things in the next few days and we can ship
it :-)

Thanks for all your hard work.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/62bac5df/attachment.html 

From djlewis at acm.org  Wed Nov  1 20:29:29 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 1 Nov 2006 17:29:29 -0800
Subject: [Masterview-devel] Release readiness, take 2
In-Reply-To: <19cda190611011658w5baab645r73145dbfedac6d11@mail.gmail.com>
Message-ID: <20061102012932.TTWA18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>

> > I hope to take one more look at things in the next few days and we can
ship it :-)  
 
ok, let me know if there's anything in particular you want me to review or
tweak.
 
>> Thanks for all your hard work. 
 
Ditto!
 
I'm going to give a quick overview talk tomorrow at the San Diego ruby group
on MasterView - lightning fly-by, if it goes over well maybe I can do a
longer talk another time.
 
~  Deb 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061101/2b14b303/attachment.html 

From jeff.barczewski at gmail.com  Fri Nov  3 13:04:57 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 3 Nov 2006 12:04:57 -0600
Subject: [Masterview-devel] [masterview] [ticket] docs
In-Reply-To: <3c4c8fa60611030240x4f66b980h2d8f35d87318c831@mail.gmail.com>
References: <3c4c8fa60610312215v5452a69bhf5dd481612917d66@mail.gmail.com>
	<19cda190611010810vce1df6bs40963092f5094522@mail.gmail.com>
	<3c4c8fa60611030240x4f66b980h2d8f35d87318c831@mail.gmail.com>
Message-ID: <19cda190611031004l5d645cfeveaf596bf99b84a3b@mail.gmail.com>

On 11/3/06, Hendy Irawan <gauldong at gmail.com> wrote:
>
> > I think that would be a good suggestion. Even though you can generate it
> is
> > generated from the installed gem, it would be nice to have access to
> that
> > separately. I will see what we can come up with.
>
> Really? I fired up gem_server and not all docs you provide on the site
> are provided by the gems.
>
>

No you are right. I forgot that we have more docs now then what is generated
by rdoc. The docs do ship in the gem and plugin, but there probably isn't a
link to them anyway unless you go digging manually. We need to provide a way
to get to those more easily.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061103/a85086d9/attachment.html 

From jeff.barczewski at gmail.com  Sat Nov  4 18:13:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 4 Nov 2006 17:13:24 -0600
Subject: [Masterview-devel] Admin page doesn't render properly in IE
In-Reply-To: <20061008050658.MKYV22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>
References: <Acbql5JZUX1DD0k6Rk2VQKEBVHPUuA==>
	<20061008050658.MKYV22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190611041513p265f61ebxc63eeda128740273@mail.gmail.com>

On 10/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
> it doesn't handle our layout styles.  haven't gotten around to looking at
> this in detail, but let's get it on our radar to fix.  Most of the world
> still uses IE, so it's not good if our stuff doesn't render properly
> [regardless of who's to blame]
>
>

I assume that you are referring to the fact that sometimes the table is
shifted down when the browser window is smaller??

Everything else looks pretty good.

I was trying to figure out what makes IE want to push the table down, has
something to do with if the table is going to have to wrap lines but I don't
know why it wants to push it down?? So I am still looking at it.

Was there anything else you were referring to?

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

From djlewis at acm.org  Sat Nov  4 18:44:09 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 4 Nov 2006 15:44:09 -0800
Subject: [Masterview-devel] Admin page doesn't render properly in IE
In-Reply-To: <19cda190611041513p265f61ebxc63eeda128740273@mail.gmail.com>
Message-ID: <20061104234411.YNPV18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

yeah, just the layout problems where the page content doesn't start
rendering until you get down to the bottom edge of the left sidebar, so you
have big top area gap where you wanted to see the page content filling in.
 
I assumed IE was just being stupid about floated layouts or something;
didn't think to try making the window larger, i was looking at things in my
usual (reasonably largish-size) browser.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Saturday, November 04, 2006 3:13 PM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Admin page doesn't render properly in IE




On 10/7/06, Deb Lewis <djlewis at acm.org> wrote: 

it doesn't handle our layout styles.  haven't gotten around to looking at
this in detail, but let's get it on our radar to fix.  Most of the world
still uses IE, so it's not good if our stuff doesn't render properly 
[regardless of who's to blame]





I assume that you are referring to the fact that sometimes the table is
shifted down when the browser window is smaller??

Everything else looks pretty good. 

I was trying to figure out what makes IE want to push the table down, has
something to do with if the table is going to have to wrap lines but I don't
know why it wants to push it down?? So I am still looking at it. 

Was there anything else you were referring to?

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061104/f37e7791/attachment-0001.html 

From jeff.barczewski at gmail.com  Sun Nov  5 15:57:59 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 5 Nov 2006 14:57:59 -0600
Subject: [Masterview-devel] Admin page doesn't render properly in IE
In-Reply-To: <20061104234411.YNPV18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <19cda190611041513p265f61ebxc63eeda128740273@mail.gmail.com>
	<20061104234411.YNPV18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190611051257p7c876819xb78d2067720b8bc4@mail.gmail.com>

On 11/4/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  yeah, just the layout problems where the page content doesn't start
> rendering until you get down to the bottom edge of the left sidebar, so you
> have big top area gap where you wanted to see the page content filling in.
>
> I assumed IE was just being stupid about floated layouts or something;
> didn't think to try making the window larger, i was looking at things in my
> usual (reasonably largish-size) browser.
>


Well after spending quite a bit of time looking into it and trying a variety
of things, the best that I could do was to reduce the margin on the right
for IE and this seems to allow the layout to work down a little below 1024
width before it bumps down.

The right side margin was there in case anyone wanted to use a right
sidebar, but since we aren't currently using that, I just reduced the
margin.

With Firefox it works as it did before since it doesn't have a layout
problem.

Hopefully that will make it work ok on your IE. I think if we need to
support smaller widths than that we'll have to spend more time with the CSS,
but I think it will do for now.

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

From jeff.barczewski at gmail.com  Sun Nov  5 15:59:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 5 Nov 2006 14:59:23 -0600
Subject: [Masterview-devel] deprecated/deprecated_directive_base.rb
In-Reply-To: <19cda190610300305l10e0411ek12c9014491614de1@mail.gmail.com>
References: <20061029161532.YCEX18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>
	<19cda190610300305l10e0411ek12c9014491614de1@mail.gmail.com>
Message-ID: <19cda190611051259k3f6dbe0eld8d503f7e8a2ad9f@mail.gmail.com>

> On 10/29/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> > ... might perhaps be better named simply deprecated/directive_base.rb
> > (per
> > original file name) or else deprecated/directive_base_old.rb (to go with
> > the
> > class name)
>
>

I renamed to deprecated/directive_base.rb and updated the corresponding test
and notes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061105/1caf4132/attachment.html 

From jeff.barczewski at gmail.com  Sun Nov  5 17:12:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 5 Nov 2006 16:12:04 -0600
Subject: [Masterview-devel] [masterview] [ticket] tags...
In-Reply-To: <19cda190611011048h6ffac62coed3c26c08b1da276@mail.gmail.com>
References: <19cda190611010828y5eb6a803o61f1af4944ed69ed@mail.gmail.com>
	<20061101180439.YIPX16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
	<19cda190611011048h6ffac62coed3c26c08b1da276@mail.gmail.com>
Message-ID: <19cda190611051412qa267071p849ae212cf35699@mail.gmail.com>

> On 11/1/06, Deb Lewis <djlewis at acm.org> wrote:
> >
> >  Jeff - question for you about our impl of the filter preprocessing, you
> > probably know this faster than my brain can work through the code paths:
> >
> > Parser.process explictly checks and applies preprocessing filters for
> > tidy and inline-erb mapping - this is longstanding code.
> >
> > But we also have EscapeErbMIOFilter being hooked in by
> > default_mio_filter_block in MasterViewIOTreeMixin.
> >
> > This is rather confusing to have similar things done in such different
> > sites/ways in the code - are these really disjoint and handling different
> > invocation cases?  Or is the parser's explicit checks superseded (and
> > duplicating?!) the way we hook this stuff in now with filters configured on
> > an MIOTree?
> >
>
>

It appears that the code was simply left over from before MIO and was not
being used anywhere. I have removed the redundant code.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061105/59d1da03/attachment.html 

From djlewis at acm.org  Mon Nov  6 00:56:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 5 Nov 2006 21:56:47 -0800
Subject: [Masterview-devel] Bug in Analyzer::Listener#doctype
Message-ID: <20061106055656.TZWI18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

Jeff - take a look and confirm, believe the Analyzer's sax listener has
wrong method signature for the doctype handler.

See below for my admin page problem stack dump;  analyzer's doctype method
has diff args than the parser one that you recently fixed.

Parser:
   def doctype(name, pub_sys, long_name, uri)
Analyzer:
    def doctype(name, pub, sys, long_name, uri)
      #todo
    end

~ Deb

wrong number of arguments (4 for 5)

#{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
ith_doctype_fix.rb:193:in `doctype'
#{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
ith_doctype_fix.rb:193:in `handle'
#{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
ith_doctype_fix.rb:192:in `handle'
#{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
ith_doctype_fix.rb:103:in `parse'
#{RAILS_ROOT}/../../vendor_plugins/masterview/lib/masterview/parser.rb:706:i
n `process'



From djlewis at acm.org  Mon Nov  6 01:07:23 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 5 Nov 2006 22:07:23 -0800
Subject: [Masterview-devel] Admin page doesn't render properly in IE
In-Reply-To: <19cda190611051257p7c876819xb78d2067720b8bc4@mail.gmail.com>
Message-ID: <20061106060728.YEJT16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>

well, probably time to declare (temporary) defeat on this one.
 
Firefox is fine, but in IE 6 on Windows I get the funky rendering on the
home page where the template info page gets pushed down to the bottom of the
left sidebar unless I pretty much go full-screen width on my  1440x900
display.
 
Let's just put this on a known-problems/todo list for now, I don't think we
should hold up the release on this one.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Sunday, November 05, 2006 12:58 PM
To: djlewis at acm.org
Cc: masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] Admin page doesn't render properly in IE


On 11/4/06, Deb Lewis <djlewis at acm.org> wrote: 

yeah, just the layout problems where the page content doesn't start
rendering until you get down to the bottom edge of the left sidebar, so you
have big top area gap where you wanted to see the page content filling in.
 
I assumed IE was just being stupid about floated layouts or something;
didn't think to try making the window larger, i was looking at things in my
usual (reasonably largish-size) browser.



Well after spending quite a bit of time looking into it and trying a variety
of things, the best that I could do was to reduce the margin on the right
for IE and this seems to allow the layout to work down a little below 1024
width before it bumps down. 

The right side margin was there in case anyone wanted to use a right
sidebar, but since we aren't currently using that, I just reduced the
margin.

With Firefox it works as it did before since it doesn't have a layout
problem. 

Hopefully that will make it work ok on your IE. I think if we need to
support smaller widths than that we'll have to spend more time with the CSS,
but I think it will do for now.

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061105/2796af10/attachment.html 

From jeff.barczewski at gmail.com  Mon Nov  6 06:16:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 6 Nov 2006 05:16:28 -0600
Subject: [Masterview-devel] Admin page doesn't render properly in IE
In-Reply-To: <20061106060728.YEJT16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
References: <19cda190611051257p7c876819xb78d2067720b8bc4@mail.gmail.com>
	<20061106060728.YEJT16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190611060316x25f642bdu7a4fa82d2e69206f@mail.gmail.com>

On 11/6/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  well, probably time to declare (temporary) defeat on this one.
>
> Firefox is fine, but in IE 6 on Windows I get the funky rendering on the
> home page where the template info page gets pushed down to the bottom of the
> left sidebar unless I pretty much go full-screen width on my  1440x900
> display.
>
> Let's just put this on a known-problems/todo list for now, I don't think
> we should hold up the release on this one.
>


Hmmm. I was testing on IE6 windows and had my window sized to less than
1024. I was looking at the main admin page, where you on maybe the
configuration or other page?

Yes, we'll have to revisit this, don't want to spend more time on it now. I
wonder if it is a problem on IE 7 or whether it renders better.

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

From jeff.barczewski at gmail.com  Mon Nov  6 06:24:31 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 6 Nov 2006 05:24:31 -0600
Subject: [Masterview-devel] Bug in Analyzer::Listener#doctype
In-Reply-To: <20061106055656.TZWI18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20061106055656.TZWI18816.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190611060324v19a90b4axd5a92b7785fe52b9@mail.gmail.com>

On 11/5/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - take a look and confirm, believe the Analyzer's sax listener has
> wrong method signature for the doctype handler.
>
> See below for my admin page problem stack dump;  analyzer's doctype method
> has diff args than the parser one that you recently fixed.
>
> Parser:
>    def doctype(name, pub_sys, long_name, uri)
> Analyzer:
>     def doctype(name, pub, sys, long_name, uri)
>       #todo
>     end
>
> ~ Deb
>
> wrong number of arguments (4 for 5)
>
>
> #{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
> ith_doctype_fix.rb:193:in `doctype'
>
> #{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
> ith_doctype_fix.rb:193:in `handle'
>
> #{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
> ith_doctype_fix.rb:192:in `handle'
>
> #{RAILS_ROOT}/../../vendor_plugins/masterview/lib/rexml/parsers/sax2parser_w
> ith_doctype_fix.rb:103:in `parse'
>
> #{RAILS_ROOT}/../../vendor_plugins/masterview/lib/masterview/parser.rb:706:i
> n `process'
>
>
>


Good catch. I had this wrong when I originally pasted it and only corrected
the one place.

It is resolved and checked in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061106/fe607498/attachment-0001.html 

From djlewis at acm.org  Mon Nov  6 13:41:43 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 6 Nov 2006 10:41:43 -0800
Subject: [Masterview-devel] [masterview] [ticket] docs
In-Reply-To: <19cda190611031004l5d645cfeveaf596bf99b84a3b@mail.gmail.com>
Message-ID: <20061106184148.OTFH16798.fed1rmmtao09.cox.net@fed1rmimpo01.cox.net>

good point and actually we should get this sorted out to go both ways so
that the main docs contain a reference to the rdoc and vice versa.
 
Need to figure out if gem install has the right hooks to handle some of
this, probably, so I think this goes on our todo list (hopefully resolved
soon).
 
The home page of the rdoc does have a link to masterview.org, so if you
installed the gem for the current release and were looking at its rdoc it
would get you to the main documentation, but this breaks down if someone's
working with an older version of the gem or a trunk version s.t. their
installed plugin is older or newer than the current release that would be on
the web site.
 
~ Deb

  _____  

From: masterview-devel-bounces at rubyforge.org
[mailto:masterview-devel-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Friday, November 03, 2006 10:05 AM
To: Hendy Irawan
Cc: masterview-devel at rubyforge.org
Subject: Re: [Masterview-devel] [masterview] [ticket] docs


On 11/3/06, Hendy Irawan <gauldong at gmail.com> wrote: 

> I think that would be a good suggestion. Even though you can generate it
is
> generated from the installed gem, it would be nice to have access to that
> separately. I will see what we can come up with.

Really? I fired up gem_server and not all docs you provide on the site
are provided by the gems.





No you are right. I forgot that we have more docs now then what is generated
by rdoc. The docs do ship in the gem and plugin, but there probably isn't a
link to them anyway unless you go digging manually. We need to provide a way
to get to those more easily. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061106/90a96f80/attachment.html 

From jeff.barczewski at gmail.com  Tue Nov  7 17:39:53 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 7 Nov 2006 16:39:53 -0600
Subject: [Masterview-devel] I found the issue that occured with gems,
	based on what you told me,
	it was missing .metadata because did not get picked up in packaging
Message-ID: <19cda190611071439h6af0671fr964c6089f77e5e0@mail.gmail.com>

Deb,

Thanks for the help with the gem issue. You were right on in that it wasn't
finding the .metadata file in the directives folder.

I had to add .metadata to our packaging (Rakefile) so that it would get
picked up. Normally we don't include any files starting with dot in the
packaging lists. So we'll need to remember to specifically add if use any
others.

Our network is painfully slow right now, so it is hard for me to continue my
testing. (I wanted to load the rails edge to verify MV works with the
current build). As soon as I can finish the verification we'll release 0.3.0.
Might be early tomorrow since I have a meeting to go to tonight. Charles
Nutter the jruby guy is speaking to a local JUG. Should be interesting.
Anything that bridges more Ruby into work is a good thing :-)

I will keep you updated of my progress.

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

From jeff.barczewski at gmail.com  Wed Nov  8 23:18:39 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 8 Nov 2006 22:18:39 -0600
Subject: [Masterview-devel] At last, MasterView article!!!!!!
In-Reply-To: <3c4c8fa60611081851vfcf7f2dm78ae125c721fbe67@mail.gmail.com>
References: <3c4c8fa60611081851vfcf7f2dm78ae125c721fbe67@mail.gmail.com>
Message-ID: <19cda190611082018q4c081f79n33ef7b6ee29748d5@mail.gmail.com>

On 11/8/06, Hendy Irawan <gauldong at gmail.com> wrote:
>
> Arghh.... After several weeks now I can make it live.
>
>
> http://web2withrubyonrails.gauldong.net/2006/11/08/easily-maintainable-designer-friendly-actionview-templates-using-masterview-liquid/
>
> It'd be great if you'd visit it and tell me what you think.
>
> It has barely touched anything, but demonstrates a good (I think)
> sample and in concert with Liquid. I think they make perfect mates.
> And I intentionally put multiple yield's in the same template, and
> also one sample uses mv:generate while the other uses render_partial
> inside content_for that uses actual Liquid template. I think it's one
> alternative (weird?) way to set up Rails but I guess it can be done
> and may actually be useful.
>
> Thanks for the images explanation, I thought I've read about that
> before somewhere but forgot it... It surely makes MasterView very very
> useful.
>
> Note that Nvu still doesn't work and this is Nvu's fault. I don't see
> a way turning off their 'tidy'ing feature. Lots of WYSIWYG editors now
> automatically 'tidy' without mercy, I hate them.



Nice article Hendy!! You did a good job of cutting to the meat of the
topics.  I love the visuals you put together, that really helps. I think
some of what you have done will help inspire us further with our
documentation.

I might suggest one minor clarification, the masterview admin page is
configurable as to whether it is enabled. By default it is only enabled in
development mode (not production) and also currently it is only available
from localhost not remote locations. We plan on enhancing the authentication
around this but took these steps to keep things relatively safe now. If you
want I can post this in comments to your site to help clarify.

NVU definitely needs a bit of work. There is a setting that is supposed to
leave your code as is, but it only partially works. And it also seems to
generate bad xhtml (no matter what you set the settings to). So one of these
days I hope to jump in there and fix both of those problems because
otherwise I think it has some good potential. I just need more time to do
everything I would like :-)

I am planning on putting on the todo list, the ability to make safe
templates with MasterView too since I agree there is a need for that where
consumers are going to change things. So I think we can clean that up even
further.

Thanks for mentioning the project in your article. We have some great things
coming in the next year, so stay tuned. And if you get some additional great
ideas, keep them coming.

All the best,

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

From jeff.barczewski at gmail.com  Thu Nov  9 01:44:24 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 9 Nov 2006 00:44:24 -0600
Subject: [Masterview-devel] [ANN] MasterView rails-optimized (x)html
	friendly template engine - Release 0.3.0
Message-ID: <19cda190611082244p602b5ca6o1b5a71a57ef5ead3@mail.gmail.com>

MasterView is a rails-optimized (x)html friendly template engine plugin that
provides another option to the existing rails view templates (rhtml and
rxml). The main idea is to provide a template engine that would provide all
the power of layouts, partials, and rails helpers but still be
editable/styleable in a WYSIWYG editor. It was also a major goal that the
syntax of these attribute directives be very similar to rails helpers so
that one could intuitively start using MasterView with little learning curve
other than knowing rails. MasterView was inspired by Amrita, Kwartz,
Tapestry, Zope/PHP TAL, Liquid, and Web Objects but designed with a fresh
approach and specifically targetted for rails users.

Release 0.3.0 was a major release for MasterView with an emphasis on
refactoring and simplifying the API for building directives. A DSL syntax
was chosen to greatly simplify the creation of directives to both help the
core team with directive development as to also enable developers to create
their own custom directives easily. MasterView has been constructed to allow
directives to be shared amongst the community and this refactoring will
enable custom development. To further enhance sharing and prevent
collisions, this release introduces custom namespaces to the directives
allowing users to create their own namespaces to prevent conflict.
Namespaces as well as many other metadata about directives can now be
configured at both the app-level and installation-level providing
flexibility.

**UPGRADE CONSIDERATIONS: (for MasterView deployments that have created
custom directives)
  default namespace of extensions directives changed from mv: to mvx:
(custom directive default namespace)
  upgrade any user created custom directives to use new directive API (see
release notes)


Video
A short video which demos the basic operation is available at
http://masterview.org/videos/demo_short.html<http://masterview.org/videos/masterview_quick_start.html>

Screenshots and illustrations
http://masterview.org/media_list.html

MasterView is released under MIT open source licensing.

Main site: http://masterview.org/
Rubyforge Project site: http://rubyforge.org/projects/masterview


Goals

   - 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 (rhtml)
   - 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 (rhtml). Scaffold generate initial
   templates or work from existing html prototype. Make scaffolds nicely styled
   and easily useable for production with minor changes.
   - Reduce the numbers of files, simplifying editing. Define partials
   and layouts naturallyl right in the template, no need to go to another file.

   - 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 (rhtml)


Release Notes:
== Recent changes (Release 0.3.0 - Major update - refactoring of directive
API (for developing directives)
The directive API for creating directives has been refactored and
simplified. This will enable directives to be developed more easily by both
core developers and MasterView users. The end goal is to make it extremely
simple for anyone to create their own custom directives and to share those
with the community, and thus the project can live and grow into many
specialty areas. The directive API refactoring is one more step towards
those goals.

The old directive_base.rb which provided the API for directives has been
deprecated and moved to deprecated/directive_base.rb, MasterViewdevelopers
which have developed custom directives should upgrade those directives to
the new API as soon as possible. During the transition period one can use
the original API by requiring the deprecated/directive_base.rb file and
changing their directive to inherit from DirectiveBaseOld rather than
DirectiveBase.


== Recent changes (Release 0.2.5)
Fix AdminPage compatibility with Rails 1.1.5+ which uses safe_load_paths to
find controllers
Fix rake mv:view_rhtml RHTML=foo/_bar.rhtml was not able to find partials



Visit the online documentation page at http://masterview.org/ for
screenshots, illustrations, complete installation and usage information.

We would love to hear your feedback and ideas around this project! Visit the
rubyforge project <http://rubyforge.org/projects/masterview> to join the
users mailing list or to add yourself to the announce list to receive future
announcements. Check out the
video<http://masterview.org/videos/demo_short.html>to see MasterView
in action!

Thanks for your time!!


MasterView Development Team
Jeff Barczewski and Deb Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061109/0f05cd8b/attachment-0001.html 

From ed.howland at gmail.com  Fri Nov 10 13:10:58 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Fri, 10 Nov 2006 12:10:58 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
Message-ID: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>

Jeff and Deb,

Turns out I had a project with many user defined directives. I
installed 0.3.0 and followed the instructions in your email.

What I did was this (in a typical directive in
<rails_app>/app/masterview/directives/text_field_tag.rb:)

require 'masterview/deprecated/directive_base'
module MasterView
  module Directives
    class Text_field_tag < MasterView::DirectiveBaseOld
...
# for testing this just redefines empty stag/etag methods

Then I went into all .html files that had custom directives and
changed the namespace from mv: to mvx:  (Note: the errors below were
unchanged before I switched namespaces to mvx)

Running rake mv:parse results in :
 ERROR -- : Failure to parse template. Exception=undefined method
`attribute_qname' for MasterView::Directives::Text_field_tag:Class
It also seems to be missing class method : namespace_name

Now, some other directives complain about this:
ERROR -- : Failure to parse template. Exception=undefined method
`harden_metadata' for
MasterView::Directives::Link_to_remote_no_quote:Class

These exist only in 0.3.0. So it seems that while it seems to be
seeing my existing directives in the new namespace or using the new
directive_base.rb instead of the old deprecated one.

Have I missed a step?

Ed



-- 
Ed Howland
http://greenprogrammer.blogspot.com

From ed.howland at gmail.com  Fri Nov 10 13:51:07 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Fri, 10 Nov 2006 12:51:07 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
References: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
Message-ID: <3df642dd0611101051i56f918cdl6f10a71b4ced82dd@mail.gmail.com>

I wrote once upon a time:
> These exist only in 0.3.0. So it seems that while it seems to be
> seeing my existing directives in the new namespace or using the new
> directive_base.rb instead of the old deprecated one.
>
> Have I missed a step?
>

I remember a previous upgrade had reset my settings.rb file, so I
restored the settings there. Basically it was just adding
config.directive_paths << 'app/masterview/directives'

Since that had no effect, and nothing else did, I still think MV is
not finding my directives, since I can not effect the output of rake
mv:parse no matter what I try. This leads me to believe these are
really error messages that mean 'Failed to find a directive matching
mvx:your_directive_name'

Ed

-- 
Ed Howland
http://greenprogrammer.blogspot.com

From jeff.barczewski at gmail.com  Fri Nov 10 14:17:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 10 Nov 2006 13:17:23 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
References: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
Message-ID: <19cda190611101117o4fcd2db2s58d03826291e65b0@mail.gmail.com>

On 11/10/06, Ed Howland <ed.howland at gmail.com> wrote:
>
> Jeff and Deb,
>
> Turns out I had a project with many user defined directives. I
> installed 0.3.0 and followed the instructions in your email.
>
> What I did was this (in a typical directive in
> <rails_app>/app/masterview/directives/text_field_tag.rb:)
>
> require 'masterview/deprecated/directive_base'
> module MasterView
>   module Directives
>     class Text_field_tag < MasterView::DirectiveBaseOld
> ...
> # for testing this just redefines empty stag/etag methods
>
> Then I went into all .html files that had custom directives and
> changed the namespace from mv: to mvx:  (Note: the errors below were
> unchanged before I switched namespaces to mvx)
>
> Running rake mv:parse results in :
> ERROR -- : Failure to parse template. Exception=undefined method
> `attribute_qname' for MasterView::Directives::Text_field_tag:Class
> It also seems to be missing class method : namespace_name
>
> Now, some other directives complain about this:
> ERROR -- : Failure to parse template. Exception=undefined method
> `harden_metadata' for
> MasterView::Directives::Link_to_remote_no_quote:Class
>
> These exist only in 0.3.0. So it seems that while it seems to be
> seeing my existing directives in the new namespace or using the new
> directive_base.rb instead of the old deprecated one.
>
> Have I missed a step?



Sounds like you did all the right things. Let me take a look and see if I
can figure out how to resolve this.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061110/26e0f006/attachment.html 

From jeff.barczewski at gmail.com  Fri Nov 10 14:53:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 10 Nov 2006 13:53:40 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
References: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
Message-ID: <19cda190611101153i47df4ce0t54f4deb990acc438@mail.gmail.com>

On 11/10/06, Ed Howland <ed.howland at gmail.com> wrote:
>
> Jeff and Deb,
>
> Turns out I had a project with many user defined directives. I
> installed 0.3.0 and followed the instructions in your email.
>
> What I did was this (in a typical directive in
> <rails_app>/app/masterview/directives/text_field_tag.rb:)
>
> require 'masterview/deprecated/directive_base'
> module MasterView
>   module Directives
>     class Text_field_tag < MasterView::DirectiveBaseOld
> ...
> # for testing this just redefines empty stag/etag methods
>
> Then I went into all .html files that had custom directives and
> changed the namespace from mv: to mvx:  (Note: the errors below were
> unchanged before I switched namespaces to mvx)
>
> Running rake mv:parse results in :
> ERROR -- : Failure to parse template. Exception=undefined method
> `attribute_qname' for MasterView::Directives::Text_field_tag:Class
> It also seems to be missing class method : namespace_name
>
> Now, some other directives complain about this:
> ERROR -- : Failure to parse template. Exception=undefined method
> `harden_metadata' for
> MasterView::Directives::Link_to_remote_no_quote:Class
>
> These exist only in 0.3.0. So it seems that while it seems to be
> seeing my existing directives in the new namespace or using the new
> directive_base.rb instead of the old deprecated one.
>
> Have I missed a step?
>
> Ed
>
>
>

Deb,

I am out the door to get on a plane, will be back Wednesday.

Can you take a look at Ed's problem?

It looks like we didn't have good test coverage in this area. I added a test
example_directive_base_old_test.rb into the trunk, so if you have time to
test you can run that.

Also sounds like he might have some other issues with it finding his
directives.

PS. Also we can upgrade his directives to the new API as well, but we should
resolve the problems either way.

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061110/9fffaf71/attachment.html 

From ed.howland at gmail.com  Fri Nov 10 15:30:34 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Fri, 10 Nov 2006 14:30:34 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <19cda190611101153i47df4ce0t54f4deb990acc438@mail.gmail.com>
References: <3df642dd0611101010m27f82af8h8d6ed7c7402365a1@mail.gmail.com>
	<19cda190611101153i47df4ce0t54f4deb990acc438@mail.gmail.com>
Message-ID: <3df642dd0611101230v5faf23dma1211dafc732e9d7@mail.gmail.com>

On 11/10/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
> Deb,
>
> I am out the door to get on a plane, will be back Wednesday.
>
> Can you take a look at Ed's problem?
>
> It looks like we didn't have good test coverage in this area. I added a test
> example_directive_base_old_test.rb into the trunk, so if
> you have time to test you can run that.
>
> Also sounds like he might have some other issues with it finding his
> directives.
>
> PS. Also we can upgrade his directives to the new API as well, but we should
> resolve the problems either way.

I am starting to convert over the existing directives one by one to
the new API. And examining what my internal need is for them is.

So, if Deb can be available to help coach me on that if I need it,
that will help.

Ed

Ed Howland
http://greenprogrammer.blogspot.com

From djlewis at acm.org  Fri Nov 10 15:40:04 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 10 Nov 2006 12:40:04 -0800
Subject: [Masterview-devel] [Masterview-users] Failure to parse
	templates - user defineddirectives w/MV: 0.3.0
In-Reply-To: <3df642dd0611101051i56f918cdl6f10a71b4ced82dd@mail.gmail.com>
Message-ID: <20061110204011.GUHD296.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>

ooh, ick - you did right; we missed something in our backwards compatibility
for old directive implementations.

The new directive architecture includes a mixin class called
DirectiveMetadata that the loading and processing facilities rely on now.
I'll have to take a look and see if we can hook this directly into the old
directive base class or whether we need to patch the necessary protocol back
onto the old guy in a different fashion.

>> went into all .html files that had custom directives and changed the
namespace from mv: to mvx:  

Alt. approach that would simplify upgrade would be to change the default
value of the config setting namespace_prefix_extensions from mvx: to specify
using old-style mv: prefix, or add .metadata file in your directives
directory containing such a spec.  The tactical options probably weren't
described well enough (we focused more on documenting the new architecture
than on upgrade details, partly because we aren't sure of the magnitude of
the problem, i.e., how many directive impl's are really out there in the
field )

Preferred approach is [of course?!] to get old directive impl's upgraded to
the new framework as soon as possible (it's WAY cleaner and easier to work
with).  We'll be glad to work with you to help you with conversion if that's
useful; just seeing a few of your own classes in the new framework might
help seeing what needs to be done.

~ Deb 

-----Original Message-----
From: masterview-users-bounces at rubyforge.org
[mailto:masterview-users-bounces at rubyforge.org] On Behalf Of Ed Howland
Sent: Friday, November 10, 2006 10:51 AM
To: masterview-users at rubyforge.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-users] Failure to parse templates - user
defineddirectives w/MV: 0.3.0

I wrote once upon a time:
> These exist only in 0.3.0. So it seems that while it seems to be 
> seeing my existing directives in the new namespace or using the new 
> directive_base.rb instead of the old deprecated one.
>
> Have I missed a step?
>



From djlewis at acm.org  Fri Nov 10 15:45:18 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 10 Nov 2006 12:45:18 -0800
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <19cda190611101153i47df4ce0t54f4deb990acc438@mail.gmail.com>
Message-ID: <20061110204520.GZBA296.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>

Jeff - yes, I'll pursue.
 
Ed - if it'd help to see a couple conversion examples, send me some.all of
your impls and I'll do an upgrade pass; once you get the hang of the changes
it's fairly straightforward, you get to dump a lot of clutter. 
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061110/170b3c5b/attachment.html 

From ed.howland at gmail.com  Fri Nov 10 15:54:52 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Fri, 10 Nov 2006 14:54:52 -0600
Subject: [Masterview-devel] Failure to parse templates - user defined
	directives w/MV: 0.3.0
In-Reply-To: <20061110204520.GZBA296.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>
References: <19cda190611101153i47df4ce0t54f4deb990acc438@mail.gmail.com>
	<20061110204520.GZBA296.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>
Message-ID: <3df642dd0611101254n330ffa9cr11060674f4a9edf9@mail.gmail.com>

On 11/10/06, Deb Lewis <djlewis at acm.org> wrote:
>
>
> Jeff - yes, I'll pursue.
>
> Ed - if it'd help to see a couple conversion examples, send me some.all of
> your impls and I'll do an upgrade pass; once you get the hang of the changes
> it's fairly straightforward, you get to dump a lot of clutter.
>

Deb,

As I mentioned in the last email to the list and Jeff, I am converting
them one by one to learn how to do it from the instructions on the
page. My trouble is I did it so long ago, I've forgotten what my need
was.

However, I do have some more testing results that might be relevant.
In prep for conversion, I moved all the old directives to
old_directives (not in the path.)
Running rake mv:parse now passes. (I guess it ignores the mvx directives.)
Adding old_directives into the directives_paths in the config, the
same error messages come back.

So, since the complaints seem to be about missing stuff in the 0.3.0
classes, I now think that it has nothing to do with not finding the
directives. It actually might have to do with something like the
require deprecated/directive_base or OldDirectiveBase.

Ed

> ~ Deb


-- 
Ed Howland
http://greenprogrammer.blogspot.com

From djlewis at acm.org  Fri Nov 10 19:43:40 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 10 Nov 2006 16:43:40 -0800
Subject: [Masterview-devel] [Masterview-users] Failure to parse
	templates - user defined directives w/MV: 0.3.0
In-Reply-To: <3df642dd0611101051i56f918cdl6f10a71b4ced82dd@mail.gmail.com>
Message-ID: <20061111004343.QEKS21630.fed1rmmtao12.cox.net@fed1rmimpo02.cox.net>

Ed wrote:
>> I remember a previous upgrade had reset my settings.rb file, 
>> so I restored the settings there. Basically it was just adding 
>> config.directive_paths << 'app/masterview/directives' 

Ed - some notes on directives and namespaces [separate from the
compatibility problem you encountered, which is something we missed and need
to correct]

That actually should get picked up by default now, so you shouldn't have to
add to the load path unless you want to load directives from somewhere else.
The standard startup processing configures the directives load path with
masterview's built-in directives and then checks to see if the rails app has
an app/masterview/directives directory - if found, that automatically gets
loaded as well.

Namespace management tips:

Although the namespace prefix for directives can be specified individually,
the usual pattern is that a developer wants all directives loaded out of a
directory to use a common namespace.  This is specified by creating a text
file in the directives directory named '.metadata' and providing the
metadata defaults in yaml-notation.  E.g.:

# MasterView directive metadata specifications
# Rails application directives

# default metadata values for directives loaded from this directory
default:
  namespace: mvx
  description: Rails app MasterView directives

Individual directives can override their directory default [should be rare,
tho].  The application developer can also override in their app config to
handle the case when you're including directives from someone else and want
a diff namespace prefix used in your app templates than what the supplier
originally specified.  This is done by including hash with app-specific
metadata defaults when appending a directive path entry.

~ Deb



From djlewis at acm.org  Sun Nov 12 14:34:08 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 12 Nov 2006 11:34:08 -0800
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
Message-ID: <20061112193413.YBDU7157.fed1rmmtao06.cox.net@fed1rmimpo01.cox.net>

Ed - would appreciate if you can confirm this fix solves your load problem.

I put in some additional unit tests to improve coverage in this area and
also did a quicky test in a rails app to load a directory with an old-impl
directive class to verify that it gets loaded and handled properly.  

(The new Directive Info page in the masterview Admin pages shows all the
loaded directives and namespaces, while Jeff's handy Interactive Render page
lets you test-drive directive markup)

And any feedback you have on this release would be much appreciated: did we
provide enough info in the release notes etc about what you as a directive
implementor had to do to hook into the backwards-compat framework?  And does
the new Developer docs we added in this release provide enough info for
someone to get started developing their own directive implementations or
does that need more work?

http://masterview.org/developer.html

Thanks!

~ Deb



From jeff.barczewski at gmail.com  Sun Nov 12 22:36:15 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 12 Nov 2006 22:36:15 -0500
Subject: [Masterview-devel] [Rails] Script/generate masterview fails
In-Reply-To: <1163340307.464136.113290@e3g2000cwe.googlegroups.com>
References: <1163340307.464136.113290@e3g2000cwe.googlegroups.com>
Message-ID: <19cda190611121936q1bf03e9cqb8dc0c877c0dd94b@mail.gmail.com>

On 11/12/06, zvavox at gmail.com <zvavox at gmail.com> wrote:
>
>
> I have been trying to make MasterView works on my Rails
> project. However, every time I issue a script/generate masterview
> Product Store command, I always get the following:
>
> ---
> D:\aaa>ruby script/generate masterview Product Store
> Initializing MasterView configuration (2006-11-12 21:10)
> Program name = script/generate
> dependency  model
>      exists    app/models/
>      exists    test/unit/
>      exists    test/fixtures/
>   identical    app/models/product.rb
>   identical    test/unit/product_test.rb
>   identical    test/fixtures/products.yml
>      exists  app/controllers/
>      exists  app/helpers/
>      create  app/views/store
>      exists  public/stylesheets/masterview
>      exists  app/masterview
>      exists  app/masterview/extra
>      exists  test/functional/
>      create  app/controllers/store_controller.rb
>      create  test/functional/store_controller_test.rb
>      create  app/helpers/store_helper.rb
>      create  store/destroy.html
> wrong number of arguments (1 for 2)
> -----
>
> Note that scaffolding works.
> D:\aaa>ruby script/generate scaffold Product Store
>
> I have the following masterview and rails version
>
> D:\aaa>gem list masterview
>
> *** LOCAL GEMS ***
>
> masterview (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials.
>
> masterview_gem_pack (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. This gem package includes the other
>    masterview gems for easy installation
>
> masterview_generator (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. MasterView Generator for creating templates
>    and scaffolding.
>
> masterview_plugin_generator (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. MasterView Plugin Generator for GEM
>
> D:\aaa>rails -v
> Rails 1.1.6
>
> D:\aaa>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
>
>          Am I using the wrong version of Rails, Ruby, or Masterview?
> Or a wrong configuration? Please note that I did not make any changes
> to the MasterView configuration file.
>          Thanks.
>
> Zandro




 Zandro,

It sounds like you are doing everything correctly. It is not obvious to me
from the output what could be causing the problem. It must be something
different in your environment but I don't know what yet.

Sounds like we need to get the stack trace for the error in the generate to
be able to figure out what is causing the problem (by default generator must
be catching the exception and hiding the output). I'll need to take a look
at the rails generator code and see how we can get at the stack trace.

I'm out of town with limited net access, but I am forwarding this on to the
MasterView developer list as well so that it will be logged. We need to find
out exactly what is failing in your environment and then it will probably
pretty easy to resolve. I'll take a look at the rails generator code here on
my laptop and if I can come up with an easy way to get a stack trace I'll
respond back. If I can figure something out from here, I will respond back,
otherwise worse case I'll be back home Tuesday evening.

Sorry for your troubles. We should be able to resolve quickly once we can
get to the root of the problem. Thanks for emailing.

We'll continue this discussion and resolution off of the main rails list to
save bandwidth, we can use the masterview-users at rubyforge.org list. If the
fix requires an update we will release one as soon as we can get to the
bottom of it.

Thanks for bringing this to our attention. We will stay on it until it is
resolved.

Blessings,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061112/03574acc/attachment.html 

From jeff.barczewski at gmail.com  Mon Nov 13 11:55:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 13 Nov 2006 11:55:34 -0500
Subject: [Masterview-devel] [Rails] Script/generate masterview fails
In-Reply-To: <1163340307.464136.113290@e3g2000cwe.googlegroups.com>
References: <1163340307.464136.113290@e3g2000cwe.googlegroups.com>
Message-ID: <19cda190611130855i5eb1bdcfof0f5421abd0ef400@mail.gmail.com>

On 11/12/06, zvavox at gmail.com <zvavox at gmail.com> wrote:

>
> I have been trying to make MasterView works on my Rails
> project. However, every time I issue a script/generate masterview
> Product Store command, I always get the following:
>
> ---
> D:\aaa>ruby script/generate masterview Product Store
> Initializing MasterView configuration (2006-11-12 21:10)
> Program name = script/generate
> dependency  model
>      exists    app/models/
>      exists    test/unit/
>      exists    test/fixtures/
>   identical    app/models/product.rb
>   identical    test/unit/product_test.rb
>   identical    test/fixtures/products.yml
>      exists  app/controllers/
>      exists  app/helpers/
>      create  app/views/store
>      exists  public/stylesheets/masterview
>      exists  app/masterview
>      exists  app/masterview/extra
>      exists  test/functional/
>      create  app/controllers/store_controller.rb
>      create  test/functional/store_controller_test.rb
>      create  app/helpers/store_helper.rb
>      create  store/destroy.html
> wrong number of arguments (1 for 2)
> -----
>
> Note that scaffolding works.
> D:\aaa>ruby script/generate scaffold Product Store
>
> I have the following masterview and rails version
>
> D:\aaa>gem list masterview
>
> *** LOCAL GEMS ***
>
> masterview (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials.
>
> masterview_gem_pack (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. This gem package includes the other
>    masterview gems for easy installation
>
> masterview_generator (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. MasterView Generator for creating templates
>    and scaffolding.
>
> masterview_plugin_generator (0.3.0)
>    A (x)html friendly template engine for rails with the power of
>    layouts, and partials. MasterView Plugin Generator for GEM
>
> D:\aaa>rails -v
> Rails 1.1.6
>
> D:\aaa>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
>
>          Am I using the wrong version of Rails, Ruby, or Masterview?
> Or a wrong configuration? Please note that I did not make any changes
> to the MasterView configuration file.
>          Thanks.





Zvavox,

Could you do the following to give us more information to debug this issue?

ruby script\generate Product Store --backtrace
(this should give us the stack trace to be able to zero in on the issue)

Also could you show us your schema for this Product table, on mysql you
would do

desc Products

Finally, could you give us a complete gem list of all gems on your system,
just in case something else is causing a problem. Just for completeness

gem list

Thanks for your help,

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

From ed.howland at gmail.com  Mon Nov 13 17:08:23 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Mon, 13 Nov 2006 16:08:23 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <20061112193413.YBDU7157.fed1rmmtao06.cox.net@fed1rmimpo01.cox.net>
References: <20061112193413.YBDU7157.fed1rmmtao06.cox.net@fed1rmimpo01.cox.net>
Message-ID: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>

On 11/12/06, Deb Lewis <djlewis at acm.org> wrote:

I found a couple of more problems. First the easy one. The docs say
that the image tag directive will take the wdith and height arguments,
if both are present and create a size="wxh" parameter. This doesn't
happen. You can try it in the interactive render page. It keeps both
widht and height.

The second one is tricky and I can't figure it out. I have a <a> tag
with an embedded img tag. I leave off the erb_content on the latter
and use content_string on the fomer. This will generate this
construct:

Original
<a href="#" wdt:link_to_remote_image=":url => {:action =>
'hide_new'}"><img wdt:image_tag_link=""
src="../../../public/images/box_minimize.gif" /></a>
Output
<%= link_to_remote( image_tag( 'box_minimize.gif' ), :url => {:action
=> 'hide_new'} ) %>
Which is what I want. But if I put any other attribute on the img tag,
it caues the combined
output to put the inner tag inside burly braces {}.

<a href="#" wdt:link_to_remote_image=":url => {:action =>
'hide_new'}"><img wdt:image_tag_link=""
src="../../../public/images/box_minimize.gif" border="0"  /></a>
Results in:
<%= link_to_remote( { image_tag( 'box_minimize.gif', :border => "0" )
}, :url => {:action => 'hide_new'} ) %>
Which causes the ActionController parse error to occur.
Now, the problem doesn't seem to be in image_tag_link, because just by
itself, it looks ok:
<img wdt:image_tag_link=""
src="../../../public/images/box_minimize.gif" border="0"  />
Results in
image_tag( 'box_minimize.gif', :border => "0" )

which is what I want.

This makes me suspect the call to method content_string in the
link_to_remote_image. If the content is a little complicated, does it
wrap the content in {}?

Ed
-- 
Ed Howland
http://greenprogrammer.blogspot.com

From djlewis at acm.org  Tue Nov 14 00:32:15 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 13 Nov 2006 21:32:15 -0800
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>
Message-ID: <20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>

RE: mv:image_tag documented as mapping width/height attrs to :size parm for
rails helper

yep, looks like we lost that logic when the implementation was reworked; an
earlier version of the the directive did indeed pick up the dims attributes
and pass them on suitably to the rails helper.  Noted, will fix (?tomorrow?)

Your embedded directives case is trickier, I don't have a quick answer on
that one tonight, need to go back into the code and twist my brain back into
that scenario.  But certainly it ought to be the case that you get the same
result for the directive regardless of whether it's embedded in a containing
element which itself has a directive, so if that's not happening there's a
bug somewhere.

~ Deb 

[soapbox rant: controlling border prop should be done in a stylesheet rule,
not by explicit presentational markup w/in doc content! but then your case
becomes needing to set, say, class attr on the <img> rather than border
prop, so your original problem report still needs to be addressed]



From ed.howland at gmail.com  Tue Nov 14 10:29:49 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Tue, 14 Nov 2006 09:29:49 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
References: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>
	<20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
Message-ID: <3df642dd0611140729h322d8f4ctdea4f33c146d8494@mail.gmail.com>

On 11/13/06, Deb Lewis <djlewis at acm.org> wrote:
> Your embedded directives case is trickier, I don't have a quick answer on
> that one tonight, need to go back into the code and twist my brain back into
> that scenario.  But certainly it ought to be the case that you get the same
> result for the directive regardless of whether it's embedded in a containing
> element which itself has a directive, so if that's not happening there's a
> bug somewhere.

Deb, I was able ro fix it by manipuating the various components of the
enclosing directive. I took the helper name I wanted (link_to_remote)
and added content_array[0].to_s and then appended any arguments (url,
etc.).

I am not certain, but the problem might be in prepare_output.

Ed

-- 
Ed Howland
http://greenprogrammer.blogspot.com

From djlewis at acm.org  Tue Nov 14 10:34:15 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 14 Nov 2006 07:34:15 -0800
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <3df642dd0611140729h322d8f4ctdea4f33c146d8494@mail.gmail.com>
Message-ID: <20061114153418.WBIY21630.fed1rmmtao12.cox.net@fed1rmimpo02.cox.net>

good, I'll follow up and look into the content_string and prepare_output
methods.

~ Deb 

-----Original Message-----
From: Ed Howland [mailto:ed.howland at gmail.com] 
Sent: Tuesday, November 14, 2006 7:30 AM
To: djlewis at acm.org
Cc: masterview-devel at rubyforge.org
Subject: Re: Fix for old directive impl compat framework in MV 0.3.0

On 11/13/06, Deb Lewis <djlewis at acm.org> wrote:
> Your embedded directives case is trickier, I don't have a quick answer 
> on that one tonight, need to go back into the code and twist my brain 
> back into that scenario.  But certainly it ought to be the case that 
> you get the same result for the directive regardless of whether it's 
> embedded in a containing element which itself has a directive, so if 
> that's not happening there's a bug somewhere.

Deb, I was able ro fix it by manipuating the various components of the
enclosing directive. I took the helper name I wanted (link_to_remote) and
added content_array[0].to_s and then appended any arguments (url, etc.).

I am not certain, but the problem might be in prepare_output.

Ed

--
Ed Howland
http://greenprogrammer.blogspot.com



From jeff.barczewski at gmail.com  Wed Nov 15 10:39:14 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 15 Nov 2006 09:39:14 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
References: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>
	<20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190611150739gb75705ay57652f0c5c7731a1@mail.gmail.com>

On 11/13/06, Deb Lewis <djlewis at acm.org> wrote:
>
> RE: mv:image_tag documented as mapping width/height attrs to :size parm
> for
> rails helper
>
> yep, looks like we lost that logic when the implementation was reworked;
> an
> earlier version of the the directive did indeed pick up the dims
> attributes
> and pass them on suitably to the rails helper.  Noted, will fix
> (?tomorrow?)



Yes, the image_tag changed in this release. After looking at the code, I
realized that the image_tag you could either use :height and :width or the
:size attributes, so I went with the :width and :height instead of :size
since it seemed cleaner to me. I don't really see why they even put the size
option in there since it is unnecessary and height and width do what we
want.

Is there a reason you don't want to use :width and :height? Last time I
looked at the code this should work identically to what :size was doing.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061115/49077caa/attachment.html 

From ed.howland at gmail.com  Wed Nov 15 10:48:58 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Wed, 15 Nov 2006 09:48:58 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <19cda190611150739gb75705ay57652f0c5c7731a1@mail.gmail.com>
References: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>
	<20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
	<19cda190611150739gb75705ay57652f0c5c7731a1@mail.gmail.com>
Message-ID: <3df642dd0611150748x7f42168bmdd2cb97f4b29e6a0@mail.gmail.com>

On 11/15/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
> Yes, the image_tag changed in this release. After looking at the code, I
> realized that the image_tag you could either use :height and :width or the
> :size attributes, so I went with the :width and :height instead of :size
> since it seemed cleaner to me. I don't really see why they even put the size
> option in there since it is unnecessary and height and width do what we
> want.
>
> Is there a reason you don't want to use :width and :height? Last time I
> looked at the code this should work identically to what :size was doing.
>  Jeff

Jeff, yes, I guess you are right there. I thought the image_tag
required the :size parameter. But I guess that every (rails-)undefined
option in the hash gets translated into additional tag attributes.  I
didn't realize that :size => 'XXxYY' wasjust a convenience parameter.

ed


-- 
Ed Howland
http://greenprogrammer.blogspot.com

From jeff.barczewski at gmail.com  Wed Nov 15 10:54:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 15 Nov 2006 09:54:40 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <3df642dd0611150748x7f42168bmdd2cb97f4b29e6a0@mail.gmail.com>
References: <3df642dd0611131408m360b7ad1vace96885a7ff1994@mail.gmail.com>
	<20061114053220.OBXT27894.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
	<19cda190611150739gb75705ay57652f0c5c7731a1@mail.gmail.com>
	<3df642dd0611150748x7f42168bmdd2cb97f4b29e6a0@mail.gmail.com>
Message-ID: <19cda190611150754o10855cefo58d3312b8b1ec280@mail.gmail.com>

On 11/15/06, Ed Howland <ed.howland at gmail.com> wrote:
>
>
> Jeff, yes, I guess you are right there. I thought the image_tag
> required the :size parameter. But I guess that every (rails-)undefined
> option in the hash gets translated into additional tag attributes.  I
> didn't realize that :size => 'XXxYY' wasjust a convenience parameter.
>
>


Also by using width and height separately you can choose to only set one or
the other (if you want, though I think this is a rare use case).

I apologize for not getting the docs updated regarding this tag, that was my
oversight.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061115/4bd9f67f/attachment.html 

From jeff.barczewski at gmail.com  Wed Nov 15 11:25:37 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 15 Nov 2006 10:25:37 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <3df642dd0611131346x2d241a28kf4ab977f1a86fd4@mail.gmail.com>
References: <3df642dd0611130945x49a6a686u641337282b5084a0@mail.gmail.com>
	<20061113194133.RDPW20330.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
	<3df642dd0611131346x2d241a28kf4ab977f1a86fd4@mail.gmail.com>
Message-ID: <19cda190611150825s50c8f64ej7e6dbcc4fda7c0cf@mail.gmail.com>

On 11/13/06, Ed Howland <ed.howland at gmail.com> wrote:
>
>
> Deb, these are pretty straightforward. But what does the the block
> arguments get translated into?
> Here are some examples from the developer doc page:
>     * attr_arg :argname {|value| ... } - pass arg value into block to
> allow additional manipulation of the value
>     * attr_arg :argname {|value args| ... } - pass value and remaining
> args array to the block
>     * attr_arg :argname {|value args directive| ... } - pass value,
> remaining args array, and the directive instance for which the
> argument value is being obtained to the block



The block arguments allow you a way to do some additional logic before the
value is applied to the variable. Just makes it easy to tweak things or do
some advanced things like pushing arguments back on the arg stack.

The various block types are typically used for the following.

|value| simply allows you to manipulate the value before it is set to the
instance variable, the return value is what is set to the instance variable.

|value, args| gives you access to both the value and the remaining args, you
can manipulate the remaining args (shifting something back on the arg stack,
taking params off, etc. The return value is what is used to set the instance
variable to.

|value, args, instance| like the above but also gives you easy access to
anything in this directive instance as well as the arg stack.


IOW, since the attr_arg methods are positional, do the subsequent
> attr_arg {|value, args| ...} eat one off the top of the list of
> remaining args each time? Or, for each next attr_arg does the top of
> the previous list become the value of this arg, while the remianing
> args are collected. Similar to how car and cdr work in Lisp?



The args is the remaining arguments that have not been pulled off the stack
yet. You can manipulate the args stack as well if you want to pull
additional ones off or shift something back on.


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

From jeff.barczewski at gmail.com  Wed Nov 15 11:44:46 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 15 Nov 2006 10:44:46 -0600
Subject: [Masterview-devel] [Rails] Script/generate masterview fails
In-Reply-To: <19cda190611130855i5eb1bdcfof0f5421abd0ef400@mail.gmail.com>
References: <1163340307.464136.113290@e3g2000cwe.googlegroups.com>
	<19cda190611130855i5eb1bdcfof0f5421abd0ef400@mail.gmail.com>
Message-ID: <19cda190611150844h3e37dd18hbad575262322ca2d@mail.gmail.com>

Zandro,

When you get a chance, could you run the following for us to help us fix the
MasterView problem you were encountering. See the email at the bottom for
the full details, but basically we would like to get the output from these
three commands.

ruby script\generate Product Store --backtracedesc Products
gem list

Thanks,

Jeff


On 11/13/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
>
>
>
> On 11/12/06, zvavox at gmail.com <zvavox at gmail.com> wrote:
>
> >
> > I have been trying to make MasterView works on my Rails
> > project. However, every time I issue a script/generate masterview
> > Product Store command, I always get the following:
> >
> > ---
> > D:\aaa>ruby script/generate masterview Product Store
> > Initializing MasterView configuration (2006-11-12 21:10)
> > Program name = script/generate
> > dependency  model
> >      exists    app/models/
> >      exists    test/unit/
> >      exists    test/fixtures/
> >   identical    app/models/product.rb
> >   identical    test/unit/product_test.rb
> >   identical    test/fixtures/products.yml
> >      exists  app/controllers/
> >      exists  app/helpers/
> >      create  app/views/store
> >      exists  public/stylesheets/masterview
> >      exists  app/masterview
> >      exists  app/masterview/extra
> >      exists  test/functional/
> >      create  app/controllers/store_controller.rb
> >      create  test/functional/store_controller_test.rb
> >      create  app/helpers/store_helper.rb
> >      create  store/destroy.html
> > wrong number of arguments (1 for 2)
> > -----
> >
> > Note that scaffolding works.
> > D:\aaa>ruby script/generate scaffold Product Store
> >
> > I have the following masterview and rails version
> >
> > D:\aaa>gem list masterview
> >
> > *** LOCAL GEMS ***
> >
> > masterview (0.3.0)
> >    A (x)html friendly template engine for rails with the power of
> >    layouts, and partials.
> >
> > masterview_gem_pack (0.3.0)
> >    A (x)html friendly template engine for rails with the power of
> >    layouts, and partials. This gem package includes the other
> >    masterview gems for easy installation
> >
> > masterview_generator (0.3.0)
> >    A (x)html friendly template engine for rails with the power of
> >    layouts, and partials. MasterView Generator for creating templates
> >    and scaffolding.
> >
> > masterview_plugin_generator (0.3.0)
> >    A (x)html friendly template engine for rails with the power of
> >    layouts, and partials. MasterView Plugin Generator for GEM
> >
> > D:\aaa>rails -v
> > Rails 1.1.6
> >
> > D:\aaa>ruby -v
> > ruby 1.8.5 (2006-08-25) [i386-mswin32]
> >
> >          Am I using the wrong version of Rails, Ruby, or Masterview?
> > Or a wrong configuration? Please note that I did not make any changes
> > to the MasterView configuration file.
> >          Thanks.
>
>
>
>
>
> Zvavox,
>
> Could you do the following to give us more information to debug this
> issue?
>
> ruby script\generate Product Store --backtrace
> (this should give us the stack trace to be able to zero in on the issue)
>
> Also could you show us your schema for this Product table, on mysql you
> would do
>
> desc Products
>
> Finally, could you give us a complete gem list of all gems on your system,
> just in case something else is causing a problem. Just for completeness
>
> gem list
>
> Thanks for your help,
>
> Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061115/2d52d5b4/attachment-0001.html 

From ed.howland at gmail.com  Wed Nov 15 13:44:07 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Wed, 15 Nov 2006 12:44:07 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <19cda190611150825s50c8f64ej7e6dbcc4fda7c0cf@mail.gmail.com>
References: <3df642dd0611130945x49a6a686u641337282b5084a0@mail.gmail.com>
	<20061113194133.RDPW20330.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
	<3df642dd0611131346x2d241a28kf4ab977f1a86fd4@mail.gmail.com>
	<19cda190611150825s50c8f64ej7e6dbcc4fda7c0cf@mail.gmail.com>
Message-ID: <3df642dd0611151044u791e52e9haa08f9b96269710d@mail.gmail.com>

On 11/15/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
> The block arguments allow you a way to do some additional logic before the
> value is applied to the variable. Just makes it easy to tweak things or do
> some advanced things like pushing arguments back on the arg stack.
>
> The various block types are typically used for the following.
>
> |value| simply allows you to manipulate the value before it is set to the
> instance variable, the return value is what is set to the instance variable.
>
> |value, args| gives you access to both the value and the remaining args, you
> can manipulate the remaining args (shifting something back on the arg stack,
> taking params off, etc. The return value is what is used to set the instance
> variable to.
>
> |value, args, instance| like the above but also gives you easy access to
> anything in this directive instance as well as the arg stack.
>
...
>
>
> The args is the remaining arguments that have not been pulled off the stack
> yet. You can manipulate the args stack as well if you want to pull
> additional ones off or shift something back on.
>

This is brilliant! Clear and erudite. If the above text were on the
web page, I would have joy in my life.

In the end, I was able to get around the problems with links and
embedded images by constructing the render string from parts. As I
mentioned to Deb, it would be helpful if the helper methods and
instance variables available to custom directives were more fully
documented. Maybe, you should provide a link to the HTML RDoc for the
entire API.

Also, you should document more clearly what the namespace should be
and also what the module naming convention should be. For instance, I
forgot to take out my old:
module MasterView
  module Directives
and replace them with
 module MyDirectives

Perhaps if you provided several examples of complete working custom
directives on the web page.

Another question:  Some things in the comments in DirectiveBase say
they are not available until the etag event has occured. Am I right
this also applies to the element event as well. IOW does this event
order hold true?

stag
etag
element

Thanks
Ed


-- 
Ed Howland
http://greenprogrammer.blogspot.com

From jeff.barczewski at gmail.com  Wed Nov 15 14:35:45 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 15 Nov 2006 13:35:45 -0600
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <3df642dd0611151044u791e52e9haa08f9b96269710d@mail.gmail.com>
References: <3df642dd0611130945x49a6a686u641337282b5084a0@mail.gmail.com>
	<20061113194133.RDPW20330.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
	<3df642dd0611131346x2d241a28kf4ab977f1a86fd4@mail.gmail.com>
	<19cda190611150825s50c8f64ej7e6dbcc4fda7c0cf@mail.gmail.com>
	<3df642dd0611151044u791e52e9haa08f9b96269710d@mail.gmail.com>
Message-ID: <19cda190611151135w12aa1e22iec8debca87dbca4c@mail.gmail.com>

On 11/15/06, Ed Howland <ed.howland at gmail.com> wrote:
>
> >
> > The args is the remaining arguments that have not been pulled off the
> stack
> > yet. You can manipulate the args stack as well if you want to pull
> > additional ones off or shift something back on.
> >
>
> This is brilliant! Clear and erudite. If the above text were on the
> web page, I would have joy in my life.



Well, we'll include it in the future to bring joy to those that follow :-)



In the end, I was able to get around the problems with links and
> embedded images by constructing the render string from parts. As I
> mentioned to Deb, it would be helpful if the helper methods and
> instance variables available to custom directives were more fully
> documented. Maybe, you should provide a link to the HTML RDoc for the
> entire API.



Agreed.

Also, you should document more clearly what the namespace should be
> and also what the module naming convention should be. For instance, I
> forgot to take out my old:
> module MasterView
>   module Directives
> and replace them with
> module MyDirectives
>
> Perhaps if you provided several examples of complete working custom
> directives on the web page.



Right.


Another question:  Some things in the comments in DirectiveBase say
> they are not available until the etag event has occured. Am I right
> this also applies to the element event as well. IOW does this event
> order hold true?
>
> stag
> etag
> element



Yes, this is correct.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061115/6dcf1621/attachment.html 

From djlewis at acm.org  Wed Nov 15 16:41:37 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 15 Nov 2006 13:41:37 -0800
Subject: [Masterview-devel] Fix for old directive impl compat framework
	in MV 0.3.0
In-Reply-To: <19cda190611151135w12aa1e22iec8debca87dbca4c@mail.gmail.com>
Message-ID: <20061115214140.DGL9173.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>

hey jeff, welcome back!  thanks for picking up on these, I hadn't had time
to pursue it further
 
[well, ok, actually i was kind of procrastinating a bit about going back
into the rendering guts to figure out to better explain it]
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, November 15, 2006 11:36 AM
To: Ed Howland
Cc: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Re: Fix for old directive impl compat framework in MV 0.3.0


On 11/15/06, Ed Howland <ed.howland at gmail.com> wrote: 

>
> The args is the remaining arguments that have not been pulled off the
stack
> yet. You can manipulate the args stack as well if you want to pull
> additional ones off or shift something back on.
>

This is brilliant! Clear and erudite. If the above text were on the
web page, I would have joy in my life.



Well, we'll include it in the future to bring joy to those that follow :-) 

 


In the end, I was able to get around the problems with links and
embedded images by constructing the render string from parts. As I 
mentioned to Deb, it would be helpful if the helper methods and
instance variables available to custom directives were more fully
documented. Maybe, you should provide a link to the HTML RDoc for the
entire API. 



Agreed. 



Also, you should document more clearly what the namespace should be 
and also what the module naming convention should be. For instance, I
forgot to take out my old:
module MasterView
  module Directives
and replace them with
module MyDirectives

Perhaps if you provided several examples of complete working custom 
directives on the web page.



Right.
 



Another question:  Some things in the comments in DirectiveBase say 
they are not available until the etag event has occured. Am I right
this also applies to the element event as well. IOW does this event
order hold true?

stag
etag
element



Yes, this is correct. 

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061115/f1e88d63/attachment.html 

From djlewis at acm.org  Thu Nov 16 19:18:00 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 16 Nov 2006 16:18:00 -0800
Subject: [Masterview-devel] [Rails] Script/generate masterview fails
In-Reply-To: <19cda190611161117h2ca0e4e7h326628fe35ee9606@mail.gmail.com>
Message-ID: <20061117001801.QTBR20330.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

RE: Zandro's getting:
>> The applicaton failed to start because mswin32-ruby16.dll was not found.
>>  The applicaton failed to start because LibMySQL.dll was not found.
... but his windows path is reporting Rails 1.1.6 and ruby 1.8.5
 
Zandro - you've got some sort of problem with your system path or your rails
configuration settings.
 
mswin32-ruby16.dll implies maybe something you're running is trying to use
an old Ruby 1.6 dll.  Doublecheck your MySQL installation and your rails db
settings.
 
Can you run a rails app and get to your database independent of masterview?
Try something simple to verify that your basic setup works.  Maybe also run
the stock rails generate script on some table and verify whether that can
get connected; seems likely that the masterview generator is tripping over a
more fundamental config problem.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061116/52db2e62/attachment.html 

From jeff.barczewski at gmail.com  Sun Nov 19 16:52:11 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 19 Nov 2006 15:52:11 -0600
Subject: [Masterview-devel] [Rails] Script/generate masterview fails -
	ruby 1.8.5 conflict, resolved in trunk, release 0.3.1 soon
Message-ID: <19cda190611191352t7662de70m6fa14f7e0b388c6d@mail.gmail.com>

On 11/12/06, zvavox at gmail.com <zvavox at gmail.com> wrote:
>
>
> I have been trying to make MasterView works on my Rails
> project. However, every time I issue a script/generate masterview
> Product Store command, I always get the following:
>
> ---
> D:\aaa>ruby script/generate masterview Product Store
> Initializing MasterView configuration (2006-11-12 21:10)
> Program name = script/generate
>   dependency  model
>       exists    app/models/
>       exists    test/unit/
>       exists    test/fixtures/
>    identical    app/models/product.rb
>    identical    test/unit/product_test.rb
>    identical    test/fixtures/products.yml
>       exists  app/controllers/
>       exists  app/helpers/
>       create  app/views/store
>       exists  public/stylesheets/masterview
>       exists  app/masterview
>       exists  app/masterview/extra
>       exists  test/functional/
>       create  app/controllers/store_controller.rb
>       create  test/functional/store_controller_test.rb
>       create  app/helpers/store_helper.rb
>       create  store/destroy.html
> wrong number of arguments (1 for 2)
>
> D:\aaa>rails -v
> Rails 1.1.6
>
> D:\aaa>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
>
>

Zandro,

I believe I found the problem you were having. I upgraded my ruby version to
1.8.5 and received a similar error [wrong number of arguments (1 for 2)]. It
appears that in 1.8.5 they updated the implemenation of
Pathname.dirnamewhich was causing an issue.

I was able to make a change that should safely resolve the problem. The
changes are in the trunk now and we will be pushing out a new release gem
and plugin very soon.

Thanks again for brining this to our attention.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061119/31bb4db8/attachment-0001.html 

From jeff.barczewski at gmail.com  Mon Nov 20 11:48:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 20 Nov 2006 10:48:35 -0600
Subject: [Masterview-devel] [ANN] MasterView rails-optimized (x)html
	friendly template engine - Release 0.3.1
Message-ID: <19cda190611200848y4c7be3cfg156ccfdd17ba761d@mail.gmail.com>

MasterView is a rails-optimized (x)html friendly template engine plugin that
provides another option to the existing rails view templates (rhtml and
rxml). The main idea is to provide a template engine that would provide all
the power of layouts, partials, and rails helpers but still be
editable/styleable in a WYSIWYG editor. It was also a major goal that the
syntax of these attribute directives be very similar to rails helpers so
that one could intuitively start using MasterView with little learning curve
other than knowing rails. MasterView was inspired by Amrita, Kwartz,
Tapestry, Zope/PHP TAL, Liquid, and Web Objects but designed with a fresh
approach and specifically targetted for rails users.

Release 0.3.1 was a maintenance release addressing an issue with ruby
1.8.5(wrong number of arguments 1 for 2 during scaffold generation),
fixing a
problem with the deprecated/directive_base used for custom directives,
updating a few out of date docs, and accomodating a change to the API of the
Rails 1.2 generator.

Release 0.3.0 was a major release for MasterView with an emphasis on
refactoring and simplifying the API for building directives. A DSL syntax
was chosen to greatly simplify the creation of directives to both help the
core team with directive development as to also enable developers to create
their own custom directives easily. MasterView has been constructed to allow
directives to be shared amongst the community and this refactoring will
enable custom development. To further enhance sharing and prevent
collisions, this release introduces custom namespaces to the directives
allowing users to create their own namespaces to prevent conflict.
Namespaces as well as many other metadata about directives can now be
configured at both the app-level and installation-level providing
flexibility.

**UPGRADE CONSIDERATIONS: (for MasterView deployments that have created
custom directives)
  default namespace of extensions directives changed from mv: to mvx:
(custom directive default namespace)
  upgrade any user created custom directives to use new directive API (see
release notes)


Video
A short video which demos the basic operation is available at
http://masterview.org/videos/demo_short.html<http://masterview.org/videos/masterview_quick_start.html>

Screenshots and illustrations
http://masterview.org/media_list.html

MasterView is released under MIT open source licensing.

Main site: http://masterview.org/
Rubyforge Project site: http://rubyforge.org/projects/masterview


Goals

   - 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 (rhtml)
   - 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 (rhtml). Scaffold generate initial
   templates or work from existing html prototype. Make scaffolds nicely styled
   and easily useable for production with minor changes.
   - Reduce the numbers of files, simplifying editing. Define partials
   and layouts naturallyl right in the template, no need to go to another file.

   - 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 (rhtml)


Release Notes:

== Recent changes (Release 0.3.1 - Maintenance release
This release addresses an issue with ruby 1.8.5, fixes a problem with the
deprecated/directive_base used for custom directives, updates a few out of
date docs, and accomodates a change to the API of the Rails 1.2 generator


== Recent changes (Release 0.3.0 - Major update - refactoring of directive
API (for developing directives)
The directive API for creating directives has been refactored and
simplified. This will enable directives to be developed more easily by both
core developers and MasterView users. The end goal is to make it extremely
simple for anyone to create their own custom directives and to share those
with the community, and thus the project can live and grow into many
specialty areas. The directive API refactoring is one more step towards
those goals.

The old directive_base.rb which provided the API for directives has been
deprecated and moved to deprecated/directive_base.rb, MasterViewdevelopers
which have developed custom directives should upgrade those directives to
the new API as soon as possible. During the transition period one can use
the original API by requiring the deprecated/directive_base.rb file and
changing their directive to inherit from DirectiveBaseOld rather than
DirectiveBase.


== Recent changes (Release 0.2.5)
Fix AdminPage compatibility with Rails 1.1.5+ which uses safe_load_paths to
find controllers
Fix rake mv:view_rhtml RHTML=foo/_bar.rhtml was not able to find partials



Visit the online documentation page at http://masterview.org/ for
screenshots, illustrations, complete installation and usage information.

We would love to hear your feedback and ideas around this project! Visit the
rubyforge project <http://rubyforge.org/projects/masterview> to join the
users mailing list or to add yourself to the announce list to receive future
announcements. Check out the
video<http://masterview.org/videos/demo_short.html>to see MasterView
in action!

Thanks for your time!!


MasterView Development Team
Jeff Barczewski and Deb Lewis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061120/8607993e/attachment.html