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
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
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
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
> 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