From djlewis at acm.org  Thu Sep  7 18:51:01 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 7 Sep 2006 15:51:01 -0700
Subject: [Masterview-devel] Code review question/comment - MV module
	constant to access the config settings
Message-ID: <20060907225103.IWMF21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>

Jeff - hey!  I'm alive again!  Finally crawling out of the swamp of
patching-bad-code I've been in for the past two months.  Back to ruby and
masterview at last!!

Synched all your changes from the past month, the new directives stuff looks
*much* better.  I'll poke around a bit and maybe have some additional
impressions after a bit more experimenting and getting back to my effort to
document creating directives, but overall this is very nice.  Good job.

Minor question/comment: in the initialization logic, you added creation of a
new constant MasterView::LoadedConfiguration.  But... we already have that,
so either this is unnecessary duplication or there's something going on in
startup ordering that I missed and should revisit to fix correctly.

The initializer basically goes through 3 phases:

(1) initialize_configuration - load the config, picking up user settings,
run some validation checks to ensure goodness, normalize representations
(ensure file system root paths are abs refs), and record values so config is
available to the runtime system

(2) load_plugin - load masterview itself (require all the core code)

(3) complete_plugin_installation - session startup: init logger and MIO,
load directives, do all our init for parsing, change detection, the admin
pages, etc

The last thing done in initialize_configuration is:

    MasterView.const_set('ConfigSettings', configuration)

with the intent that MasterView::ConfigSettings be available during
operation for code which needed to access config-dependent values.

So I think your addition of LoadedConfiguration is unnecessary, unless
there's something subtle about start order that I've missed in the places
where you're referencing that new guy. 

~ Deb



From jeff.barczewski at gmail.com  Fri Sep  8 00:18:53 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 7 Sep 2006 23:18:53 -0500
Subject: [Masterview-devel] Code review question/comment - MV module
	constant to access the config settings
In-Reply-To: <20060907225103.IWMF21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
References: <20060907225103.IWMF21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609072118y3037f698n96d30b69ef2a4253@mail.gmail.com>

On 9/7/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - hey!  I'm alive again!  Finally crawling out of the swamp of
> patching-bad-code I've been in for the past two months.  Back to ruby and
> masterview at last!!

Wonderful! I've missed you :-)

>
>
> Minor question/comment: in the initialization logic, you added creation of a
> new constant MasterView::LoadedConfiguration.  But... we already have that,
> so either this is unnecessary duplication or there's something going on in
> startup ordering that I missed and should revisit to fix correctly.
>
> The initializer basically goes through 3 phases:
>
> (1) initialize_configuration - load the config, picking up user settings,
> run some validation checks to ensure goodness, normalize representations
> (ensure file system root paths are abs refs), and record values so config is
> available to the runtime system
>
> (2) load_plugin - load masterview itself (require all the core code)
>
> (3) complete_plugin_installation - session startup: init logger and MIO,
> load directives, do all our init for parsing, change detection, the admin
> pages, etc
>
> The last thing done in initialize_configuration is:
>
>     MasterView.const_set('ConfigSettings', configuration)
>
> with the intent that MasterView::ConfigSettings be available during

Yeah, maybe I missed the fact that the configuration was being set in
that constant and created some duplication. I can't quite remember off
the top of my head (been in a lot of code recently :-). The only other
thing I might have been doing was trying to get the configuration that
ended up being used (which is the merge of default plus user
settings), not sure if that might have been what I was going after (if
ConfigSettings is only what the user had specified). I'll take a look
tomorrow and see if anything rings a bell or whether I simply missed
the other constant.

Thanks for clarifying the load phases though, I didn't quite have my
hands around how all that worked yet.

Jeff

From djlewis at acm.org  Fri Sep  8 12:14:28 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 8 Sep 2006 09:14:28 -0700
Subject: [Masterview-devel] Code review question/comment - MV module
	constant to access the config settings
In-Reply-To: <19cda190609072118y3037f698n96d30b69ef2a4253@mail.gmail.com>
Message-ID: <20060908161428.QRNA12581.fed1rmmtao02.cox.net@fed1rmimpo02.cox.net>

>> ... trying to get the configuration that ended up being used 
>> (which is the merge of default plus user settings), not sure if 
>> that might have been what I was going after (if ConfigSettings 
>> is only what the user had specified). I'll take a look tomorrow 
>> and see if anything rings a bell or whether I simply missed the 
>> other constant.

MasterView::ConfigSetting is "the true story" - that's the initial defaults
+ the user's settings (possibly environment-dependent) + any final
cleanup/normalizing we do.  So it's definition is "the actual, final
configuration settings for this application execution session".

I decided to be a bit aggressive and actually freeze this configuration
instance at the time we install it in the module constant so there's no
possible question about what config we were supposed to be using.  Maybe
overzealous, but then it's also a clear distinction between a config setting
which initializes some variable which can change over the life of the
application and something which is truly intended to be a constant once it's
value has been determined.

We could also go back at this point and drop out some of the original
constants you'd used in various internal classes to capture this sort of
stuff, at least some of them are probably redundant now.  Places where we
stuff a config value into an internal implementation class's constant could
be dropped out s.t. the class gets its value directly from a
MasterView::ConfigSettings.foobar value.  I didn't want to do that
originally because I was nervous about making too many changes during the
transition to the new config scheme.

I decided *not* to document the existence of MasterView::ConfigSettings in
the Configuration documentation - I wanted that to be user-focused and about
the specification mechanism ("here's how you specify your config options"),
whereas the config instance recording the settings is primarily an internal
artifact of the MV implementation and intended for use by the engine itself
moreso that client apps.

Would be more appropriate to document this guy in a docs section on the MV
internals, I think.  I'll see if it fits in with the docs I've started to
describe the directive implementation technique, if that works as a general
home for "Extending MasterView" material.

~ Deb



From jeff.barczewski at gmail.com  Fri Sep  8 12:19:01 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 8 Sep 2006 11:19:01 -0500
Subject: [Masterview-devel] Code review question/comment - MV module
	constant to access the config settings
In-Reply-To: <19cda190609072118y3037f698n96d30b69ef2a4253@mail.gmail.com>
References: <20060907225103.IWMF21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
	<19cda190609072118y3037f698n96d30b69ef2a4253@mail.gmail.com>
Message-ID: <19cda190609080919n2804dde9x6bf007a7071af394@mail.gmail.com>

> On 9/7/06, Deb Lewis <djlewis at acm.org> wrote:
>
> > Minor question/comment: in the initialization logic, you added creation of a
> > new constant MasterView::LoadedConfiguration.  But... we already have that,
> > so either this is unnecessary duplication or there's something going on in
> > startup ordering that I missed and should revisit to fix correctly.
> >
> >
> > The last thing done in initialize_configuration is:
> >
> >     MasterView.const_set('ConfigSettings', configuration)
> >
> > with the intent that MasterView::ConfigSettings be available during
>

Yes, it appears that I simply needed access to the configuration from
the masterview_controller and for the enable_mv_admin_page
functionality. So it does appear to be a duplication. I will change
the references of LoadedConfiguration to ConfigSettings and make sure
that everything still works properly, then we can delete the
duplicate.

Nice catch!

Jeff

From jeff.barczewski at gmail.com  Fri Sep  8 12:22:11 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 8 Sep 2006 11:22:11 -0500
Subject: [Masterview-devel] Code review question/comment - MV module
	constant to access the config settings
In-Reply-To: <20060908161428.QRNA12581.fed1rmmtao02.cox.net@fed1rmimpo02.cox.net>
References: <19cda190609072118y3037f698n96d30b69ef2a4253@mail.gmail.com>
	<20060908161428.QRNA12581.fed1rmmtao02.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609080922x48bfcae0sa1302564ff12da50@mail.gmail.com>

On 9/8/06, Deb Lewis <djlewis at acm.org> wrote:
>
> MasterView::ConfigSetting is "the true story" - that's the initial defaults
> + the user's settings (possibly environment-dependent) + any final
> cleanup/normalizing we do.  So it's definition is "the actual, final
> configuration settings for this application execution session".

Great, that the guy I would use most often.

>
> Would be more appropriate to document this guy in a docs section on the MV
> internals, I think.  I'll see if it fits in with the docs I've started to
> describe the directive implementation technique, if that works as a general
> home for "Extending MasterView" material.
>

I think that would be a good place to document it, keeping the other
stuff more user oriented like you said.

From djlewis at acm.org  Tue Sep 12 14:37:34 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 12 Sep 2006 11:37:34 -0700
Subject: [Masterview-devel] [Masterview-commits] [244]
	trunk/masterview/doc: Docs reorg and navtinkering: break out
	About page to tighten up home page; add (incomplete) Dev Guide;
	w3c val icon
In-Reply-To: <20060912182451.C0D8F5241686@rubyforge.org>
Message-ID: <20060912183738.IUUP6077.fed1rmmtao01.cox.net@fed1rmimpo01.cox.net>

Didn't actually get very far on the directive-developer guide, which was
what I started out on this morning; got sidetracked tinkering with nav
header/footer, breaking an About page out of the home page to try to tighten
up the focus of what we put in front of a new visitor, formatting tinkering,
added W3C validator logo on the footer link...
 
Take a look when you get around to it and let me know if you like this.  The
std w3c validator logo is pretty heavyweight, not real excited about the
look.  There is a smaller, less-intrusive img I found in plone that we could
probably use.
 
I was thinking that a w3c-validator badge directive would be good to provide
as a custom directive sample - very simple, but realistic.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060912/1bfa3bc5/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colophon_xhtml.png
Type: image/png
Size: 413 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/masterview-devel/attachments/20060912/1bfa3bc5/attachment-0001.png 

From djlewis at acm.org  Tue Sep 12 15:23:02 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 12 Sep 2006 12:23:02 -0700
Subject: [Masterview-devel] [Masterview-commits]
	[244]trunk/masterview/doc: Docs reorg and navtinkering: break
	outAbout page to tighten up home page;
	add (incomplete) Dev Guide; w3c val icon
In-Reply-To: <20060912183738.IUUP6077.fed1rmmtao01.cox.net@fed1rmimpo01.cox.net>
Message-ID: <20060912192306.KLDO6077.fed1rmmtao01.cox.net@fed1rmimpo01.cox.net>

p.s. ran tidy on all our docs and patched up some bogus alt attributes for
the screenshot refs - these go on thumbnail <img> elements, not the
containing <a> link wrapping the image.  Just curious, assume you did that
in Nvu - is it encouraging/allowing that mis-placed attribute usage?
 
And fyi: to get popup tip working for both IE and Firefox you have to
"double-up" your tip text by putting it in both title and alt attributes.  
 
That latter might be a nice tweak in our image_tag directive: if only one or
the other of the alt/title attributes was defined on the original element,
fix it up by adding it's twin.  Need to do a bit more investigation to
ensure there's no downside to such cleverness, however.  Or maybe that would
be a specific "tip" option value to our directive that we'd map to the
title/alt attr pair in the emitted image_tag helper.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060912/9804480e/attachment.html 

From djlewis at acm.org  Mon Sep 18 12:48:53 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 09:48:53 -0700
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
Message-ID: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>

Jeff - see below for some thoughts on our DSL notation and directive
implementation framework, now that I've been muddling about in the code and
trying to write documentation to explain the attr_arg DSL notation.

~ Deb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

:optional_default keyword seems unnecesssarily verbose; why not just
:default => value

   attr_arg :foo, :default => nil

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

:array => :remaining_args notation is reasonably clear, but not "obvious"
(easy to remember) - doesn't quite fit with the terminology ordinarily used
for this when talking about method signatures.  

I think the old C terminology "varargs" is commonly used to talk about this
kind of thing (e.g., Java 5 picked this up: "...variable arity parameters,
known less formally as varargs").  So maybe :varargs => true

  attr_arg :optional_values_list, :varargs => true

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

I've concluded that :merge is a very confusing option name, in two respects.
First, everything else in the attr_arg domain is about parsing and
manipulating the directive's attribute value string.  This option is
different - it's expressing a request to go *outside* the scope of the
directive attribute itself to collect information from its context (other
attributes on the element to which the directive is attached).  

Second confusing aspect is typing of the value - it's not initially obvious
that the arg value is always a string literal encoding of a hash, vs.
actually *being* a hash.

Related the latter aspect, as I think about keyword args and options args
which are some combo of keyword-value pairs from the attribute string and/or
sibling attributes from the element itself, I think I'd like an option to
specify whether I want the hash literal string (default) or an actual hash.
Maybe :hash => true or :eval => :hash or some notation along those lines.

That would let us pull the parsing/evaluation impl out of the Attr directive
into a general directive-helper service and let mv:attr's impl use an
attr_arg decl indicating that it wants its arg eval'd into a real hash.

Possibly even something more general, e.g., :eval => true or :type => :hash
(or :array or :int, depending on how far we want to go with this)

We do need to make sure we have good exception-handling code so that typos
and mistakes in template markup fail politely!  (haven't pushed on that area
much, but the one time I tripped over this it was quite confusing)

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Accessor names in DirectiveBase: would like some of these names to be
clearer in distinguishing operations on the directive itself (its args,
processing state, rendering state) vs. operations on the element or the
overall template processing.

Specifically: attrs and tag_name would be much clearer if named, say,
element_attrs and element_tag

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --



From djlewis at acm.org  Mon Sep 18 13:21:32 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 10:21:32 -0700
Subject: [Masterview-devel] Comments on directive framework implementation
Message-ID: <20060918172131.UOUD12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>

I don't necessarily want to clean this up quite yet, but let's be aware that
the structuring and dependencies between DirectiveBase, DirectiveDSL, and
DirectiveHelpers is a bit muddled up at the moment as code has been pushed
around into different arrangements.

DirectiveDSL is used as base class for DirectiveBase itself, yet relies on
services that come from DirectiveBase (notably attr_value, attrs).  To be
proper, DirectiveDSL ought to be a mixin with a clear statement of
dependencies that it needs to have satisfied ("mix this into your directive
impl/base class and provide the following services...) or it should be
constructed as an abstract class with unimplemented placeholder methods
which are required to be implemented by concrete subclass.

And let me float this for your reaction: I'd *really* like to add some
namespace structure to partition the internal implementation components of
the DirectiveDSL mechanism from the main class.  Ditto the Parser area (and
perhaps even MIO and Analyzer).  When I read rdoc or work with the code,
it's getting confusing to have the top-level MasterView name space
containing such a mix of major mechanisms along with all their internal
pieces.

[tools note: the ruby plugin I use in eclipse has a very useful Outline view
of code files - similar to how java code is presented, the Outline view
alongside a ruby code file shows you the nesting structure of modules and
classes as a tree, down to the method level, so the implementation and name
space structuring of our code is very "tangible" in the representations that
I work with alongside the actual code files]

I did a prototype of this in my own working copy, introducting
MasterView::DirectiveDefinition into directive_dsl.rb to partition
AttrArgDef, EventDef, DirectiveClassDef, and DirectiveDSLClassMethods into
an internal namespace that's essentially "the stuff that's the internals of
DirectiveDSL".

Similarly for parser.rb, though this one was a bit less clear what to call
and where to split: I put in MasterView::TemplateProcessing to collect the
internals RenderLevel, RenderMode, DirectiveSet, DirectiveCallStack, Tag,
the sax listener...

I'm finding this makes it a lot easier to work with the code, I don't have
to think quite so hard about whether a specific class is a major-feature guy
or an internals-element implementation.

I put a snapshot of these out in branches/djl-namespace-additions-sketch so
you can look at a concrete sample.  There's some ripple into other code; a
lot of it is into the unit tests for directives, which are now crying out to
me for some helper services to abstract all the clutter in there about tags
and directive call stacks and such.

~ Deb



From djlewis at acm.org  Mon Sep 18 13:37:28 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 10:37:28 -0700
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
Message-ID: <20060918173727.EISF18985.fed1rmmtao10.cox.net@fed1rmimpo01.cox.net>

RE: :merge option name is confusing

ah, right, just found my note-to-self with an idea for alt names for this.
Maybe call this option :element_attrs, that's more explicit and conveys some
sense of what's being added.  Option value is one or more element names,
including reserved name :common_html; maybe also an :all value?

Side comment: the current impl of :common_html is kind of funky IMO -
muddles standard attributes with random subsets from images, tables,....
Would rather be a bit more explicit and tie attribute-set names to the
standards.  Universal attributes (?:standard_html?) are id, name, class,
style.  Then maybe we define explicit sets for elements of interest: images,
links, stylesheets, tables, e.g., :image_attrs are alt, title, and the
old-compat attrs width/height.  

Not sure how far to go with this, at some point you end up building a tag =>
attr_names map from the xhtml spec so you can say "gimme all the relevant
attributes for a Foo element", and that seems like overkill.  So this could
be one of those ideas that deserves to be killed off promptly.

~ Deb



From djlewis at acm.org  Mon Sep 18 13:59:24 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 10:59:24 -0700
Subject: [Masterview-devel] Directive names: mv:eval, mv:block
Message-ID: <20060918175923.VQCN6235.fed1rmmtao06.cox.net@fed1rmimpo01.cox.net>

The new mv:eval directive caused me to revisit our original mv:block
directive, whose name never quite resonated properly in my brain.

"block" is pretty vague, doesn't trigger any clear reaction about what that
does when I encounter it.

Possibly mv:eval_block is more expressive?

I also considered erb_ prefix on this pair, but decided I don't like that on
the grounds that "erb" expresses "how" rather than "what" and our
declarative markup should have the goal of conveying "what"

~ Deb



From djlewis at acm.org  Mon Sep 18 13:59:24 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 10:59:24 -0700
Subject: [Masterview-devel] Add doc entries for new 0.2.5 directives:
	eval, form_remote, link_to_function
In-Reply-To: <20060918155217.15DB25240F7B@rubyforge.org>
Message-ID: <20060918175923.WIBC12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>

Added doc entries are sketchy and need work, but wanted to at least keep the
main reference complete.
 
Need to figure out as part of the directive metadata mechanism how to get
summary description and details/examples for each directive out of normal
rdoc text in the directive's .rb file, I think, then maybe a rake task to
build our reference page automatically (fill in skeleton with the two
indexes, by category and alpha, along with the actual reference entries).
Latter could also be used to drive admin page and building doc views onto
addon directive sets.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20060918/2ab01461/attachment-0001.html 

From jeff.barczewski at gmail.com  Mon Sep 18 15:00:58 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 18 Sep 2006 14:00:58 -0500
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
In-Reply-To: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
References: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609181200r4995411eu2363c2aa8e372f74@mail.gmail.com>

On 9/18/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - see below for some thoughts on our DSL notation and directive
> implementation framework, now that I've been muddling about in the code and
> trying to write documentation to explain the attr_arg DSL notation.
>
> :optional_default keyword seems unnecesssarily verbose; why not just
> :default => value
>
>    attr_arg :foo, :default => nil

Yeah, that seems like a sensible change. I named it as I did since it
was only getting invoked if it was needed, meaning that it wasn't
getting called unless something later in the parameter stack changed
to trigger it. (an optional param, that if needed would default to x).
  So for instance lets say you didn't have any html options in your
form helper but because MasterView merges in your class style or
something into it, now you need a default for the options arg, thus
the optional_default.

Shortening to :default is probably fine unless that implies that it
will always result in something happening (default being set
regardless). I was just trying to keep the generated form helpers as
clean as what we would do by hand, not setting a bunch of extra values
if they aren't needed. (actually we might even be able to simply
further when you get down to reading response to :type suggestion).

>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> :array => :remaining_args notation is reasonably clear, but not "obvious"
> (easy to remember) - doesn't quite fit with the terminology ordinarily used
> for this when talking about method signatures.
>
> I think the old C terminology "varargs" is commonly used to talk about this
> kind of thing (e.g., Java 5 picked this up: "...variable arity parameters,
> known less formally as varargs").  So maybe :varargs => true
>
>   attr_arg :optional_values_list, :varargs => true

I agree :varargs => true is probably clearer than the :array,
:remaining_args terminology. I was thinking about the notation
allowing other types of arrays to be created, but I don't think that
we had any business case for any of these yet so I think :varargs
would be simpler and clearer.

>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> I've concluded that :merge is a very confusing option name, in two respects.
> First, everything else in the attr_arg domain is about parsing and
> manipulating the directive's attribute value string.  This option is
> different - it's expressing a request to go *outside* the scope of the
> directive attribute itself to collect information from its context (other
> attributes on the element to which the directive is attached).
>

Right, that is a different aspect of this. A commonly used aspect in
the MasterView world but something that might not be as clear. I was
basing it off hte Hash.merge method in Ruby, but if you can propose a
better key word then that's fine.

> Second confusing aspect is typing of the value - it's not initially obvious
> that the arg value is always a string literal encoding of a hash, vs.
> actually *being* a hash.

Right, that is a tricky area since it is a string representation of a
hash which allows the shorthand method argument style declaration
(omitting the brackets).

>
> Related the latter aspect, as I think about keyword args and options args
> which are some combo of keyword-value pairs from the attribute string and/or
> sibling attributes from the element itself, I think I'd like an option to
> specify whether I want the hash literal string (default) or an actual hash.
> Maybe :hash => true or :eval => :hash or some notation along those lines.

I haven't come across the need for an actual hash yet, though it had
crossed my mind. I originally started out using evals to create
hashes, but found that confusing and tricky for users, such that I
abandoned the idea (or at least my implementation). If you see this
being a need then we can probably fit it in to the definition.

>
> That would let us pull the parsing/evaluation impl out of the Attr directive
> into a general directive-helper service and let mv:attr's impl use an
> attr_arg decl indicating that it wants its arg eval'd into a real hash.
>
> Possibly even something more general, e.g., :eval => true or :type => :hash
> (or :array or :int, depending on how far we want to go with this)

If we indicate that it is hash literal string, then we can infer what
it's default value would be {} getting rid of the :optional_default.
Same for an array we could infer that it is []. I don't remember if we
needed :optional_default for any other types of defaults (boolean,
int, string) but there are reasonable defaults for those too (false,
0, '' or nil).

I had originally wanted to define types of params but then kind of
went away from that for simplicity. Also it didn't add anything to
parsing since I couldn't really use the fact tht something was a
number anyway (since it might be a method that returns a number), ...
Maybe it is clearer to define the type especially if you want some
default capability. So rather than defining the optional_default, you
define the type and the default will occur automatically.

Maybe something like this?? If you want to define the type :type =>
:hash  or :type => :array then the system will automatically create a
default of {} or [] if one is needed when passing in parameters to a
method call. Otherwise specifying the type is optional. If nothing is
specified and param is needed it will default to nil.

So maybe to summarize the above points we can do something like

attr_arg :foo, :type => :hash # hash literal string with default of {}
if needed for param
attr_arg :foo, :type => :array # array literal string with default of
[] if needed for param
attr_arg :foo, :varargs => true # array or remaining args
attr_arg :foo, :type => :hash, :merge => [:bar, :baz]

Is this clearer?? We can certainly add the eval => true or something
if needed or if you can show me how this might be used so we can write
some tests around it. Visualizing all of this is half the problem. :-)


>
> We do need to make sure we have good exception-handling code so that typos
> and mistakes in template markup fail politely!  (haven't pushed on that area
> much, but the one time I tripped over this it was quite confusing)

Yeah that is an art in itself. I think we can do better in this area
as well. I only have started to touch on this.

>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> Accessor names in DirectiveBase: would like some of these names to be
> clearer in distinguishing operations on the directive itself (its args,
> processing state, rendering state) vs. operations on the element or the
> overall template processing.
>
> Specifically: attrs and tag_name would be much clearer if named, say,
> element_attrs and element_tag
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

I see your point. element_attrs and element_tag is fine with me if you
think it is clearer. Feel free to suggest any other specific changes
that you think make more sense. I was going for shorter, however
sometimes that is not always the best, especially if easily confused
with something else.

Thanks for your input. Let me know what you think about my comments
and I can make the changes. I am talking about DSL's and this next
Tuesday so I would like to make any clarifying changes this week (as
long as they are mostly syntactical and not too much in forms of
changing functionality), so that it will be clearer to my audience as
well.

I appreciate your input! I got my new server configured and setup with
some decent security measures, so I can get back into looking at the
new documents you mentioned last week.

Jeff

From jeff.barczewski at gmail.com  Mon Sep 18 15:58:10 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 18 Sep 2006 14:58:10 -0500
Subject: [Masterview-devel] Comments on directive framework
	implementation
In-Reply-To: <20060918172131.UOUD12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>
References: <20060918172131.UOUD12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609181258g22d4fbal6065634668faa760@mail.gmail.com>

On 9/18/06, Deb Lewis <djlewis at acm.org> wrote:
> I don't necessarily want to clean this up quite yet, but let's be aware that
> the structuring and dependencies between DirectiveBase, DirectiveDSL, and
> DirectiveHelpers is a bit muddled up at the moment as code has been pushed
> around into different arrangements.
>
> DirectiveDSL is used as base class for DirectiveBase itself, yet relies on
> services that come from DirectiveBase (notably attr_value, attrs).  To be
> proper, DirectiveDSL ought to be a mixin with a clear statement of
> dependencies that it needs to have satisfied ("mix this into your directive
> impl/base class and provide the following services...) or it should be
> constructed as an abstract class with unimplemented placeholder methods
> which are required to be implemented by concrete subclass.
>
> And let me float this for your reaction: I'd *really* like to add some
> namespace structure to partition the internal implementation components of
> the DirectiveDSL mechanism from the main class.  Ditto the Parser area (and
> perhaps even MIO and Analyzer).  When I read rdoc or work with the code,
> it's getting confusing to have the top-level MasterView name space
> containing such a mix of major mechanisms along with all their internal
> pieces.
>
> [tools note: the ruby plugin I use in eclipse has a very useful Outline view
> of code files - similar to how java code is presented, the Outline view
> alongside a ruby code file shows you the nesting structure of modules and
> classes as a tree, down to the method level, so the implementation and name
> space structuring of our code is very "tangible" in the representations that
> I work with alongside the actual code files]
>
> I did a prototype of this in my own working copy, introducting
> MasterView::DirectiveDefinition into directive_dsl.rb to partition
> AttrArgDef, EventDef, DirectiveClassDef, and DirectiveDSLClassMethods into
> an internal namespace that's essentially "the stuff that's the internals of
> DirectiveDSL".
>
> Similarly for parser.rb, though this one was a bit less clear what to call
> and where to split: I put in MasterView::TemplateProcessing to collect the
> internals RenderLevel, RenderMode, DirectiveSet, DirectiveCallStack, Tag,
> the sax listener...
>
> I'm finding this makes it a lot easier to work with the code, I don't have
> to think quite so hard about whether a specific class is a major-feature guy
> or an internals-element implementation.
>
> I put a snapshot of these out in branches/djl-namespace-additions-sketch so
> you can look at a concrete sample.  There's some ripple into other code; a
> lot of it is into the unit tests for directives, which are now crying out to
> me for some helper services to abstract all the clutter in there about tags
> and directive call stacks and such.
>

Yeah, I agree namespaces would help clean up things as would helpers
in the unit/functional tests. Part of the reason that I broke
DirectiveDSL out was so that users woulnd't be looking at that and
getting confused since it is more supportive functionality rather than
direct accessors and things.

I think namespaces and helpers would help (no pun intended :-)

From jeff.barczewski at gmail.com  Mon Sep 18 16:12:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 18 Sep 2006 15:12:28 -0500
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
In-Reply-To: <20060918173727.EISF18985.fed1rmmtao10.cox.net@fed1rmimpo01.cox.net>
References: <20060918173727.EISF18985.fed1rmmtao10.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609181312q39bd6860j5a4172d468d57e18@mail.gmail.com>

On 9/18/06, Deb Lewis <djlewis at acm.org> wrote:
> RE: :merge option name is confusing
>
> ah, right, just found my note-to-self with an idea for alt names for this.
> Maybe call this option :element_attrs, that's more explicit and conveys some
> sense of what's being added.  Option value is one or more element names,
> including reserved name :common_html; maybe also an :all value?

Sure, if :element_attrs seems clearer than :merge then we can do that.
I am fine with having a :common_html and maybe an :all. Maybe :all
does everything  and :common_html does only things that are truly
common across html?

I started out with common only being fairly common things, but then
started wondering what the harm of including the others would be. They
probably wouldn't exist unless they were applicable.

We could use :all for this and back :common_html down to smaller subset.

I was just trying to make things easier and simpler. Unless I ran into
an area where one of the attributes was going to cause a problem then
I would probably use the all method for simplicity.

Or should :all actually do all attribues not just ones define in
xhtml? Should we have :all_xhtml_11 ?

>
> Side comment: the current impl of :common_html is kind of funky IMO -
> muddles standard attributes with random subsets from images, tables,....
> Would rather be a bit more explicit and tie attribute-set names to the
> standards.  Universal attributes (?:standard_html?) are id, name, class,
> style.  Then maybe we define explicit sets for elements of interest: images,
> links, stylesheets, tables, e.g., :image_attrs are alt, title, and the
> old-compat attrs width/height.
>
> Not sure how far to go with this, at some point you end up building a tag =>
> attr_names map from the xhtml spec so you can say "gimme all the relevant
> attributes for a Foo element", and that seems like overkill.  So this could
> be one of those ideas that deserves to be killed off promptly.
>

Yeah, I think we can build it if we need it. YNGNI (as you were telling me).

From djlewis at acm.org  Mon Sep 18 19:38:07 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 18 Sep 2006 16:38:07 -0700
Subject: [Masterview-devel] Directive rework [p.s.]
In-Reply-To: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
Message-ID: <20060918233805.ZWBG26416.fed1rmmtao12.cox.net@fed1rmimpo01.cox.net>

p.s. Aside from essentially minor quibbling about some names and such, I
really really like everything you did with this rework.  The declarative
notation to express a directive signature and its parsing attributes into
argument values, along with the event handler mechanism to configure the
processing logic are way cool.

~ Deb



From djlewis at acm.org  Tue Sep 19 03:49:16 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 19 Sep 2006 00:49:16 -0700
Subject: [Masterview-devel] Redoing DirectiveDSL as a mixin rather than base
	class for DirectiveBase
Message-ID: <20060919074916.PIFN22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>

... turns out to be pretty simple adjustment to what you'd already done.

Preview stored in branches/djl-namespace-additions-sketch/directive_dsl.rb
(includes namespace experiment, which you may or may not yet want in the
trunk)

Mods are:

(1) DirectiveDSL is now a module, rather than a class.

Replace:
    class << self
      include DirectiveDSLClassMethods # create class methods
    end

with notification handler which is called when mixin include happens:

    # add class methods for DSL declarations to class which is mixing in
DirectiveDSL
    def self.included(mixing_class)  #:nodoc:
      mixing_class.extend(DirectiveDSLClassMethods)
    end

(2) change DirectiveBase decl from:

  class  DirectiveBase < DirectiveDSL

to:

  class  DirectiveBase
	include DirectiveDSL

And that seems to do it.  Unit tests all run, ditto quick check of a test
app.

~ Deb



From djlewis at acm.org  Wed Sep 20 01:00:20 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 19 Sep 2006 22:00:20 -0700
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
In-Reply-To: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
Message-ID: <20060920050017.YJTQ12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

ok, time for another round after contemplating your responses and some of
the factors you've already considered.

Let's stay with your current concept that attr_arg simply produces string
values and not introduce typing.  As you say, it's not yet clear it's needed
and better to not introduce if it only complicates things.

So attr_arg has a clear point of view: it operates on a string (the
attribute_value string) and produces strings.  The only time you get
something other than a string from an attr_arg declaration is for the
:remaining_args (:varargs?) case, when you get an array of string values.

[of course you can also provide a block and transform the string before it
gets assigned to the arg inst var, but then that's yer own fault, er,
responsibility]

Provide helper function in DirectiveHelpers which parses a string value
which is a hash literal (with or w/out the {} to handle syntactic sugar
shorthand) - call it parse_string_into_hash or something like that.
(extract from the mv:attr impl)  Then if a directive handler really wants an
actual hash out of its attribute value or an arg, it has a standard way to
easily do so.

?Maybe also a serialize_hash_to_attributes helper?  consider if we have use
case to justify, easy to add

I do think the :merge option needs a better name.  Merge is a collection
operation on hashes and sets, while the subject of an attr_arg is a string
(even though a string which happens in this case to be a hash literal).
Calling it :merge implies it's operating on a hash, which isn't the case.
Also, what :merge actually does is go outside the scope of *this* directive
and its attr_value to collect additional values from the directive's
context, so I'd like a name which somehow expresses "going out and
collecting additional attr name/value pairs to include in whatever we parsed
out of the directive's own attribute value"

:append_element_attrs perhaps?!

RE: :optional_default vs :default - don't want to change the existing
semantics, the shorter name just seemed sufficiently clear to me.

RE: DirectiveBase accessors for element attr's and tag name vs. the
directive's own attr_value

>> element_attrs and element_tag is fine with me if you think it is clearer.


attrs and tag_name on DirectiveBase still feel wrong/confusing to me as I
continue to work with this stuff, so I still like some sort of change in
those accessor names.  Within a directive implementation, my focus is this
directive and its value.  The directive itself *is* an attribute; the
element that it belongs to *has* attrs and a tag name, but that's about the
object that it belongs to and not the directive itself.

Every time I run into an attrs reference in a directive I find I have to
stop and think for a moment and that's usually an indication of a naming
problem.

~ Deb



From jeff.barczewski at gmail.com  Wed Sep 20 08:23:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 07:23:35 -0500
Subject: [Masterview-devel] I updated from svn,
	directive_metadata_test breaks?,
	maybe directive_metadata.rb needs to be included in masterview.rb??
Message-ID: <19cda190609200523l4efcd0e5gb0e124d7f27fdb@mail.gmail.com>

I just updated from svn and ran the test suite.

./test/unit/directive_metadata_test.rb:14: uninitialized constant
MasterView::DirectiveMetadata (NameError)
        from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5
        from /usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5



I'm wondering if maybe directive_metadata.rb needs to be included in
masterview.rb??

PS. I finally got my server situation under control, so I'm back onto
MasterView. I'm going to take a look at all the changes you put in.
Thanks for all your hard work!

Jeff

From jeff.barczewski at gmail.com  Wed Sep 20 10:05:04 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 09:05:04 -0500
Subject: [Masterview-devel] [Masterview-commits] [246]
	trunk/masterview/doc/developer.html: Snapshot incomplete work
	in progress documenting directive implementatino framework.
In-Reply-To: <20060917013502.D97CCA970013@rubyforge.org>
References: <20060917013502.D97CCA970013@rubyforge.org>
Message-ID: <19cda190609200705y347aebd2wae51a4a044186847@mail.gmail.com>

Documentation looks good!

In regards to your question about developer.html

"As noted in the overview, most directive processing is associated
with the <code>:stag</code> event, when the directive can manipulate
the attributes of the element, or with the <code>:content</code> or
<code>:element</code> events when performing transformations on the
element output.
+Processing done on the <code>:etag</code> event is typically
associated with conditional directives that control the presence or
absence of the element in the output document.
+<i>[### is that right??? ###]</i>
+</p>


Yes, the majority of directives implemented to date predominately use
element to replace. stag is used for attribute manipulation, content
when only the content needs to change, and stag + etag when completing
a block that wraps the element.

Great job in expressing all this in words!

Jeff

From djlewis at acm.org  Wed Sep 20 10:32:11 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 07:32:11 -0700
Subject: [Masterview-devel] Dejunking - can we get rid of rdoc-style.css?
Message-ID: <20060920143206.KWAU22977.fed1rmmtao08.cox.net@fed1rmimpo02.cox.net>

The docs now all use their own stylesheet and as far as I could see rdoc for
the api docs brings in its own copy of rdoc stylesheet anyway.  

So - can we drop rdoc-style.css from the root of the project?  Let's get rid
of it if not useful; anything valuable can be mined and migrated into
doc/stylesheets.

~ Deb



From djlewis at acm.org  Wed Sep 20 10:32:11 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 07:32:11 -0700
Subject: [Masterview-devel] I updated from svn,
	directive_metadata_test breaks?,
	maybe directive_metadata.rb needs to be included in masterview.rb??
In-Reply-To: <19cda190609200523l4efcd0e5gb0e124d7f27fdb@mail.gmail.com>
Message-ID: <20060920143207.ECIV13992.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>

ah - yes, right, it does; I hadn't submitted that because I hadn't finished
the hooks in the directive loader/registration that go with this (working on
that this morning)

Probably no downside to adding this to masterview.rb, even tho not yet used,
so I'll submit.  (alt would be to temporarily add the require in the unit
test, but might as well just do it right and be done with it)

~ Deb 

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, September 20, 2006 5:24 AM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: I updated from svn, directive_metadata_test breaks?, maybe
directive_metadata.rb needs to be included in masterview.rb??

I just updated from svn and ran the test suite.

./test/unit/directive_metadata_test.rb:14: uninitialized constant
MasterView::DirectiveMetadata (NameError)
        from
/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5
        from
/usr/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/rake_test_loader.rb:5

I'm wondering if maybe directive_metadata.rb needs to be included in
masterview.rb??

PS. I finally got my server situation under control, so I'm back onto
MasterView. I'm going to take a look at all the changes you put in.
Thanks for all your hard work!

Jeff



From djlewis at acm.org  Wed Sep 20 10:56:46 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 07:56:46 -0700
Subject: [Masterview-devel] [Masterview-commits] [246]
	trunk/masterview/doc/developer.html: Snapshot incomplete work
	in progress documenting directive implementatino framework.
In-Reply-To: <19cda190609200705y347aebd2wae51a4a044186847@mail.gmail.com>
Message-ID: <20060920145642.VRWR6235.fed1rmmtao06.cox.net@fed1rmimpo02.cox.net>

>> stag is used for attribute manipulation, content when only the content 
>> needs to change, and stag + etag when completing a block that wraps the
element.

Got it, rewrote that paragraph a bit to better express when/why etag is
used.

The doc still needs work describing what goes on during the actual rendering
processing (what form things get accumulated, the relation between the
directive rendering accumulator and when things get rolled into overall
element rendering and into the final output) and better discussion of the
render services that a handler would use.

But it's coming along; be good to get some additional feedback after this
settles out a bit more from any of our users who've written directives.

~ Deb



From jeff.barczewski at gmail.com  Wed Sep 20 11:01:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 10:01:40 -0500
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
In-Reply-To: <20060920050017.YJTQ12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
	<20060920050017.YJTQ12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609200801h4fa5830cv25bdb66490a63ce1@mail.gmail.com>

On 9/20/06, Deb Lewis <djlewis at acm.org> wrote:
>
> So attr_arg has a clear point of view: it operates on a string (the
> attribute_value string) and produces strings.  The only time you get
> something other than a string from an attr_arg declaration is for the
> :remaining_args (:varargs?) case, when you get an array of string values.

I think I like your idea of changing :array => :remaining_args
to simply :varargs => true

>
> Provide helper function in DirectiveHelpers which parses a string value
> which is a hash literal (with or w/out the {} to handle syntactic sugar
> shorthand) - call it parse_string_into_hash or something like that.
> (extract from the mv:attr impl)  Then if a directive handler really wants an
> actual hash out of its attribute value or an arg, it has a standard way to
> easily do so.

Lets put this on the todo list, don't need it right now, but would be
good to have for developers so done in consistent way.

>
> ?Maybe also a serialize_hash_to_attributes helper?  consider if we have use
> case to justify, easy to add

If I understand what you are saying here is to have a helper that
takes all the values in a hash and sets the attributes on the element
from them. Similar to how the attr directive works. We can probably
take the code from attr directive and put in a helper and just have
attr call the helper.

>
> I do think the :merge option needs a better name.  Merge is a collection
> ...
> :append_element_attrs perhaps?!

ok, I think for clarity you have a good point

:merge will become :append_element_attrs

>
> RE: :optional_default vs :default - don't want to change the existing
> semantics, the shorter name just seemed sufficiently clear to me.

will go with :default vs :optional_default

>
> RE: DirectiveBase accessors for element attr's and tag name vs. the
> directive's own attr_value
>

attrs will become element_attrs
tag_name will become element_tag

------------------------

So to summarize the changes I will make:

:array => :remaining_args  becomes  :varargs => true
:merge will become :append_element_attrs
:optional_default will become :default
attrs will become element_attrs
tag_name will become element_tag

For todo list

DirectiveHelpers.parse_string_into_hash
DirectiveHelpers.serialize_hash_to_attributes # refactor attr
directive code into here

Let me know if I have forgotten anything. Thanks for the input! The
more refinement we put in now, the less questions and confusion we
will have down the road :-)

Jeff

From jeff.barczewski at gmail.com  Wed Sep 20 11:06:38 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 10:06:38 -0500
Subject: [Masterview-devel] Do we have a way to enable masterview admin
	pages on remote server?
Message-ID: <19cda190609200806n216d8dfetba5684854997993e@mail.gmail.com>

Deb,

Do we have a way to enable masterview admin pages on remote server?

I was wanting to test out on the new server masterview admin pages,
however since I wasn't hitting things locally I couldn't get to them.
And since I was running off the gem, there wasn't a way to edit the
controller.

So I am thinking we need a configuration option to be able to enable
masterview admin pages that are not localhost.

I know you were thinking about the bigger picture of ACL's too, so I
wanted to get your thoughts on how we should approach.

Thanks,

Jeff

From jeff.barczewski at gmail.com  Wed Sep 20 11:13:29 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 10:13:29 -0500
Subject: [Masterview-devel] Improving goals/elevator speech
Message-ID: <19cda190609200813s7efe6be2xf23912b299b6577d@mail.gmail.com>

Since you were into the documentation, I thought I would revisit the
notes you made from your meeting with Stuart Holloway.

One suggestion was to improve the elevator speech and/or goals

into something like

-1- provide ability to create Rails templates w/ full power of Rails and
ERb
     *but* done using valid xhmtml that can be worked on with standard
     HTML and CSS editing tools (by either the developer or a separate
designer)

 -2- improve scaffold template generation to produce (near)
production-ready views


Did you have any more thoughts about this? Do we add a new section for
this on intro page?

Any more refinement we need to do on this?

I don't necessarily want to lose all the other goals but I do see the
value in improving the punchline to the intro, so I am open on how to
do this, while still keeping the other goals visisble somewhere. We
might simply put a new elevator speech section first on the intro
page.

Jeff

From jeff.barczewski at gmail.com  Wed Sep 20 11:36:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 10:36:23 -0500
Subject: [Masterview-devel] Directive rework [p.s.]
In-Reply-To: <20060918233805.ZWBG26416.fed1rmmtao12.cox.net@fed1rmimpo01.cox.net>
References: <20060918164852.UVMR2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
	<20060918233805.ZWBG26416.fed1rmmtao12.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609200836j49da30adx8642e8a69c277d6@mail.gmail.com>

On 9/18/06, Deb Lewis <djlewis at acm.org> wrote:
> p.s. Aside from essentially minor quibbling about some names and such, I
> really really like everything you did with this rework.  The declarative
> notation to express a directive signature and its parsing attributes into
> argument values, along with the event handler mechanism to configure the
> processing logic are way cool.
>

Thanks, I do like how it came out. I'm glad that you do provide your
input on the naming and suggestions for improvement though, naming is
not my strong suit :-) and the better job we do at this now, will save
us tons later (in questions and confusion).

I am looking forward to talking about it all next Tuesday at the St.
Louis Ruby meeting. When is your OC meeting?

Jeff

From djlewis at acm.org  Wed Sep 20 11:43:18 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 08:43:18 -0700
Subject: [Masterview-devel] Thoughts on directives: attr_arg and related
	services
In-Reply-To: <19cda190609200801h4fa5830cv25bdb66490a63ce1@mail.gmail.com>
Message-ID: <20060920154313.NUWV26416.fed1rmmtao12.cox.net@fed1rmimpo02.cox.net>

Jeff - good, I like it.  :append_element_attrs is certainly more verbose,
but clear

Do you want me to commit my changes which made DirectiveDSL into a mixin for
DirectiveBase and added some internal namespacing on its impl mechanisms
before you do this?  I haven't made any other changes, just this structural
stuff, but didn't want to submit unless you concurred with these
adjustments.

~ Deb

------------------------

So to summarize the changes I will make:

:array => :remaining_args  becomes  :varargs => true 

:merge will become :append_element_attrs 

:optional_default will become :default 

attrs will become element_attrs, tag_name will become element_tag

------------------------



From jeff.barczewski at gmail.com  Wed Sep 20 12:38:57 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 20 Sep 2006 11:38:57 -0500
Subject: [Masterview-devel] Dejunking - can we get rid of rdoc-style.css?
In-Reply-To: <20060920143206.KWAU22977.fed1rmmtao08.cox.net@fed1rmimpo02.cox.net>
References: <20060920143206.KWAU22977.fed1rmmtao08.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609200938r2934e96bj828278505fe20fec@mail.gmail.com>

On 9/20/06, Deb Lewis <djlewis at acm.org> wrote:
> The docs now all use their own stylesheet and as far as I could see rdoc for
> the api docs brings in its own copy of rdoc stylesheet anyway.
>
> So - can we drop rdoc-style.css from the root of the project?  Let's get rid
> of it if not useful; anything valuable can be mined and migrated into
> doc/stylesheets.

Yes, lets do it!

From djlewis at acm.org  Wed Sep 20 16:30:49 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 13:30:49 -0700
Subject: [Masterview-devel] Rework of DirectiveDSL as a mixin + internal
	namespace
In-Reply-To: <19cda190609200850m425b7327we6d9c5c4ea66aa63@mail.gmail.com>
Message-ID: <20060920203049.ZDJA22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>

>>  go ahead and commit your code when ready.

done, believe I picked up all the ripples into test cases etc, let me know
if I missed anything

I've also got a modified copy of parser.rb where I was experimenting with
similar addition of namespace substructure to wrap the internal impl
classes.  Used MasterView::TemplateProcessing there (similar to introduction
of Master::DirectiveProcessing in the DSL impl).

Not sure if that's partitioned quite right.  I can commit if you want me to
put it in and then we can both refine it further, otherwise I'll just keep
it for now as my local deviation.

>> mvx sounds like a good default namespace for extensions to keep
distinguished from the built in ones.

Ok, I'll continue to work with that on the first pass.  That'll be an
upgrade issue to document/flag at release time tho - currently addons get
dumped in mv:foo.

RE: namespaces - for the first pass I'm hooking up a mechanism that will
pick up metadata defaults from a config spec file in a directives directory
if available; that'll make it fairly easy to package a set of addons w/out
having to hardwire explicit metadata decl's for the namespace into every
class.  Once that's settled I'd like to add a config-time override mechanism
to tie into masterview config.directive_paths entries.  [and someday: figure
out what it would mean to allow doc-specific namespace aliasing as defined
by xml]

~ Deb



From djlewis at acm.org  Wed Sep 20 16:30:49 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 20 Sep 2006 13:30:49 -0700
Subject: [Masterview-devel] Directive rework [p.s.]
In-Reply-To: <19cda190609200836j49da30adx8642e8a69c277d6@mail.gmail.com>
Message-ID: <20060920203048.JGPZ6711.fed1rmmtao04.cox.net@fed1rmimpo01.cox.net>

>> I am looking forward to talking about it all next Tuesday 
>> at the St. Louis Ruby meeting. When is your OC meeting?

Supposed to be next Thu, tho we've lost our prev. mtg location and are
looking for a new home

~ Deb



From djlewis at acm.org  Thu Sep 21 05:05:39 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 21 Sep 2006 02:05:39 -0700
Subject: [Masterview-devel] Directive metadata and namespaces status
Message-ID: <20060921090538.GEAD21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>

I think I've got something fairly workable, but I want to do some additional
testing tomorrow before committing.

Changes are mainly in the DirectiveRegistry and its loading mechanism;
loading custom directive into a diff namespace basically just worked once
the new metadata mechanisms were hooked in, no template parser changes
needed.

DirectiveMetadata will be added as a mixin to DirectiveBase; when I commit
that, I'm also going to shift the DirectivePriorities declarations out of
DirectiveHelpers into DirectiveMetadata.  Added support for priority as part
of metadata mechanism so that default med priority is configured as
currently done; directives which want a diff priority can simply declare it
in their metadata rather than needed a priority method.

~ Deb



From jeff.barczewski at gmail.com  Thu Sep 21 09:53:34 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 21 Sep 2006 08:53:34 -0500
Subject: [Masterview-devel] Rework of DirectiveDSL as a mixin + internal
	namespace
In-Reply-To: <20060920203049.ZDJA22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>
References: <19cda190609200850m425b7327we6d9c5c4ea66aa63@mail.gmail.com>
	<20060920203049.ZDJA22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609210653j447667cajb4c2b6cff468ef83@mail.gmail.com>

On 9/20/06, Deb Lewis <djlewis at acm.org> wrote:
> >>  go ahead and commit your code when ready.
>
> done, believe I picked up all the ripples into test cases etc, let me know
> if I missed anything
>
> I've also got a modified copy of parser.rb where I was experimenting with
> similar addition of namespace substructure to wrap the internal impl
> classes.  Used MasterView::TemplateProcessing there (similar to introduction
> of Master::DirectiveProcessing in the DSL impl).

That is fine with me.

>
> Not sure if that's partitioned quite right.  I can commit if you want me to
> put it in and then we can both refine it further, otherwise I'll just keep
> it for now as my local deviation.

Which ever seems best to you.

>
> >> mvx sounds like a good default namespace for extensions to keep
> distinguished from the built in ones.
>
> Ok, I'll continue to work with that on the first pass.  That'll be an
> upgrade issue to document/flag at release time tho - currently addons get
> dumped in mv:foo.

Right

>
> RE: namespaces - for the first pass I'm hooking up a mechanism that will
> pick up metadata defaults from a config spec file in a directives directory
> if available; that'll make it fairly easy to package a set of addons w/out
> having to hardwire explicit metadata decl's for the namespace into every
> class.  Once that's settled I'd like to add a config-time override mechanism
> to tie into masterview config.directive_paths entries.  [and someday: figure
> out what it would mean to allow doc-specific namespace aliasing as defined
> by xml]

Sounds like a plan!

From jeff.barczewski at gmail.com  Thu Sep 21 09:57:10 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 21 Sep 2006 08:57:10 -0500
Subject: [Masterview-devel] Directive metadata and namespaces status
In-Reply-To: <20060921090538.GEAD21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
References: <20060921090538.GEAD21457.fed1rmmtao07.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609210657w7f805fb6x86ee03738e7a83c0@mail.gmail.com>

On 9/21/06, Deb Lewis <djlewis at acm.org> wrote:
> I think I've got something fairly workable, but I want to do some additional
> testing tomorrow before committing.
>
> Changes are mainly in the DirectiveRegistry and its loading mechanism;
> loading custom directive into a diff namespace basically just worked once
> the new metadata mechanisms were hooked in, no template parser changes
> needed.
>
> DirectiveMetadata will be added as a mixin to DirectiveBase; when I commit
> that, I'm also going to shift the DirectivePriorities declarations out of
> DirectiveHelpers into DirectiveMetadata.  Added support for priority as part
> of metadata mechanism so that default med priority is configured as
> currently done; directives which want a diff priority can simply declare it
> in their metadata rather than needed a priority method.
>

Sounds wonderful!

From djlewis at acm.org  Fri Sep 22 13:49:06 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 22 Sep 2006 10:49:06 -0700
Subject: [Masterview-devel] New DirectiveMetadata mechanism
Message-ID: <20060922174928.KCEG6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>

Summary of the DirectiveMetadata rework:

New class DirectiveMetadata - mixin for directive implementations.  Standard
protocol for the fundamental directive properties that define the directive
markup (attribute name and namespace) and processing priority that are
required for all directives.  Extensible - any metadata property of use can
be specified.

DirectivePriorities constants are moved from DirectiveHelpers module to
DirectiveMetadata.

Standard metadata properties for all directives specify the directive markup
and processing priority:

   - :attribute_name, :namespace_name, :namespace_prefix, :attribute_qname
   - :priority - directive processing priority (specify constant or its
name; latter preferred)

Intended convention for documentation metadata (not yet rolled out into
directive impls, but Real Soon):

    - :description - the one-liner summary we put in the index
    - :category - one or more categories so we can generate docs automically
with category indexes

The description properties can support a directive info page in the
MasterView admin controller and be used to automatically generate the
doc/directives.html reference.

Directive implementations use metadata DSL notation for declarative
specification of their directive info.

    class Foo < MasterView::DirectiveBase
        metadata :priority => 'High',
            :description => 'My nifty custom directive that does Good Stuff'
        event :element { ... }
    end

Default values for standard properties are installed when directive is
loaded.

Default values for the directive implementations in a directives load path
dir can be specified by placing file named .metadata in the directives
directory with yaml specifications.  Specify defaults: with name/value pairs
for metadata defaults.  In future may have some other options that fit in
here which could control loading or support tools.

Supporting changes: 

- MasterView::Configuration now supports add_directive_path method for
appending a directive_paths entry.  Currently this is just appends the
directive path name string provided as arg to the load path
(config.directive_paths << arg).  Intention is to add support here for
optional parm with metadata defaults, so that the md defaults for directives
loaded from that directory can be controlled by the app config to override
or extend the .metadata file in the directives dir.

###STILL TO DO: need to sort out config setting for specifying default
namespace for directives that distinguishs builtin from addons (mv:, mvx:).
Right now addon directives that don't explicitly declare their namespace or
provide .metadata spec in their directives dir still go to mv: namespace.

~ Deb



From djlewis at acm.org  Fri Sep 22 16:55:45 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 22 Sep 2006 13:55:45 -0700
Subject: [Masterview-devel] What is/was purpose of namespace override option
	in Renderer?
Message-ID: <20060922205542.LZSK12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

Jeff - there's an old hook in the template parsing Renderer to take options
from the client which can include :namespace option to override the default
mv namespace.

I need to understand why that was there and if it's something significant
that we need to support.  Whatever the original purpose was probably doesn't
work with the new metadata and namespaces mechanisms that I just put in.

I'd like to either get rid of that old :namespace option hook in Renderer or
if it's important figure out what needs to be done to provide the desired
functionality given the new metadata facilities.

Discussion/details follow.

~ Deb

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Background: the original implementation of parsing filled in default value
for namespace if not specifically implemented by the directive dynamically,
every time a document template was processed.  There was code which
on-the-fly computed default attr name from directive class name and if no ns
specified filled in the default mv namespace.

The options arg in Renderer would allow mv: namespace to be overridden on a
per-invocation basis (though I don't know if that was ever exploited)

The new stuff I've put in pins down its point of view on directive markup
naming at the time that a directive is loaded.  That effectively fixes our
opinion on the directive's attribute name and namespace for the duration of
the application's execution.

I would at some point in the Glorious Future also like to handle namespace
aliasing w/in a document, per xml markup that lets you declare the namespace
prefix you want to use w/in that particular document, but that's not
something I want to tackle yet.  And when we do it's likely solvable at the
point when we extract the directive set from an alement: if there's
namespace prefix aliases defined in the document we're processing, we'd map
that to the registered namespace at that point so we can identify the
handler.

-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --



From djlewis at acm.org  Fri Sep 22 21:04:16 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 22 Sep 2006 18:04:16 -0700
Subject: [Masterview-devel] Proposed change to default directive attribute
	formula
Message-ID: <20060923010413.RHIP13992.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>

I've got a one-liner change to modify the default directive attribute name
derived from a class name so that std. camel casing can be used on directive
class names.

Ex. rename Image_tag to ImageTag and still get directive mv:image_tag

Existing directive class names with underscore-lowercase names are fine, but
can be changed to follow normal ruby class naming convention as convenient.

Any objection?  I think this is actually more consistent with general Rails
name mapping conventions, e.g., std mapping between class names and file
names.

Only problem would be if someone was actually using a mixed-case directive
attribute (like... say, the TestDirective unit test fixture you had in
example test case that I had to fix!); don't think that's likely if people
were following the lowercase-plus-underscore convention of the builtin
directives.  You can always explictly specify :attribute_name in metadata
decl to override default value.

~ Deb



From djlewis at acm.org  Sat Sep 23 17:16:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 23 Sep 2006 14:16:47 -0700
Subject: [Masterview-devel] Proposed change to default directive
	attributeformula
In-Reply-To: <20060923010413.RHIP13992.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>
Message-ID: <20060923211643.NMA21457.fed1rmmtao07.cox.net@fed1rmimpo02.cox.net>

>>  one-liner change to modify the default directive attribute name 
>> derived from a class name so that std. camel casing can be used on 
>> directive class names.

Had intended to hold off on submitting this until you'd had a chance to
point out any flaws in my justification that this won't introduce any compat
problems, but accidently committed the updated test case along with some
other unrelated changes, so just went ahead and committed this.

Todo: change class names in masterview/directives which used underscores
back to normal ruby CamelCase naming convention.

~ Deb



From djlewis at acm.org  Sat Sep 23 17:16:47 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 23 Sep 2006 14:16:47 -0700
Subject: [Masterview-devel] And while I'm on this
	wrapping-internals-in-namespaces kick
Message-ID: <20060923211643.FGCW2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>

... what about MasterView::IO to wrap the MIO classes?

~ Deb



From djlewis at acm.org  Sun Sep 24 00:09:35 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 23 Sep 2006 21:09:35 -0700
Subject: [Masterview-devel] Do we have a way to enable masterview admin
	pages on remote server?
In-Reply-To: <19cda190609200806n216d8dfetba5684854997993e@mail.gmail.com>
Message-ID: <20060924040930.NXTI2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>

yes, agree that we need to redo the allow_access? predicate in the admin
contoller in a way that's configurable (vs. current hardwired restriction to
local requester).  Authentication and access are back on top of my queue for
my own sites now that our directives rework is settling, so this notion fits
in with stuff I'm looking at anyway.

I'm in working on the admin pages now for hooking up directives info, I'll
see what I can do tomorrow to refactor that logic in a way that allows it to
be configurable.

~ Deb 

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, September 20, 2006 8:07 AM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: Do we have a way to enable masterview admin pages on remote server?

Deb,

Do we have a way to enable masterview admin pages on remote server?

I was wanting to test out on the new server masterview admin pages, however
since I wasn't hitting things locally I couldn't get to them.
And since I was running off the gem, there wasn't a way to edit the
controller.

So I am thinking we need a configuration option to be able to enable
masterview admin pages that are not localhost.

I know you were thinking about the bigger picture of ACL's too, so I wanted
to get your thoughts on how we should approach.

Thanks,

Jeff



From jeff.barczewski at gmail.com  Sun Sep 24 10:42:31 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 24 Sep 2006 09:42:31 -0500
Subject: [Masterview-devel] What is/was purpose of namespace override
	option in Renderer?
In-Reply-To: <20060922205542.LZSK12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20060922205542.LZSK12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609240742s5105dc4dy1f582b4a9ed82425@mail.gmail.com>

On 9/22/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - there's an old hook in the template parsing Renderer to take options
> from the client which can include :namespace option to override the default
> mv namespace.
>
> I need to understand why that was there and if it's something significant
> that we need to support.  Whatever the original purpose was probably doesn't
> work with the new metadata and namespaces mechanisms that I just put in.
>
> I'd like to either get rid of that old :namespace option hook in Renderer or
> if it's important figure out what needs to be done to provide the desired
> functionality given the new metadata facilities.
>

I think the original idea was that if you wanted to change the
namespace so that there wasn't one or to something different so it
didn't conflict with other things that you could do it. However I
don't really see this being necessary for any scenarios I can
currently envision. I am fine with removing it in light of the new
custom namespacing that you have created.

From jeff.barczewski at gmail.com  Sun Sep 24 10:45:47 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 24 Sep 2006 09:45:47 -0500
Subject: [Masterview-devel] Proposed change to default directive
	attributeformula
In-Reply-To: <20060923211643.NMA21457.fed1rmmtao07.cox.net@fed1rmimpo02.cox.net>
References: <20060923010413.RHIP13992.fed1rmmtao11.cox.net@fed1rmimpo02.cox.net>
	<20060923211643.NMA21457.fed1rmmtao07.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609240745g718cc372t4a14ab5f3c41eafa@mail.gmail.com>

On 9/23/06, Deb Lewis <djlewis at acm.org> wrote:
> >>  one-liner change to modify the default directive attribute name
> >> derived from a class name so that std. camel casing can be used on
> >> directive class names.
>
> Had intended to hold off on submitting this until you'd had a chance to
> point out any flaws in my justification that this won't introduce any compat

Seems like a good update to me.  The more consistency the better.

From jeff.barczewski at gmail.com  Sun Sep 24 12:04:48 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 24 Sep 2006 11:04:48 -0500
Subject: [Masterview-devel] And while I'm on this
	wrapping-internals-in-namespaces kick
In-Reply-To: <20060923211643.FGCW2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>
References: <20060923211643.FGCW2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190609240904n3eb1d3c1md7656060ee3b3c7f@mail.gmail.com>

On 9/23/06, Deb Lewis <djlewis at acm.org> wrote:
> ... what about MasterView::IO to wrap the MIO classes?
>

Yes, I think that would be great.

From djlewis at acm.org  Sun Sep 24 19:04:04 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 24 Sep 2006 16:04:04 -0700
Subject: [Masterview-devel] Code review request: support layouts in MV Admin
	pages
Message-ID: <20060924230417.CRDA6711.fed1rmmtao04.cox.net@fed1rmimpo01.cox.net>

Jeff - it was really bugging me that our admin pages weren't able to use
layouts, so I poked around in ActionController's implementation and figured
out what I think is a safe/stable way to slide in alongside the standard
services.

So the main index/list page and the three config info pages now use layouts.
(We should clean up the other pages in there at some point, but I'm punting
for now, need to go back and finish some loose ends in directive metadata
mechanisms)

Background: problem was that the base Rails layout mechanism has an
assumption about working (only) in the context of app/views/layouts dir
bolted down in its roots.  But we want to be able to render with a layout
file that we pull up from the mv installation dir (plugin or gem).

**Please code review this and test on your system!!  I'm running Rails
1.1.2; I think/hope this area of Rails is pretty stable w.r.t the way I
wrote this code, but testing on newer versions would be good.

Our hook is installed as
ActionController::Base.masterview_render_file_with_layout; impl is in
masterview_controller (at least for now - someday I'd like to maybe
reorganize our rails extensions into an explicit rails_ext dir, along the
lines of how rails organizes its core ruby extensions, which I think is a
good clear way to manage these).

I didn't check into rails issues db to see if there's any outstanding
tickets on this, supposed it would be good to add and maybe propose a patch,
but need to go over protocol issues before making such a proposal for
general use.

~ Deb



From jeff.barczewski at gmail.com  Mon Sep 25 06:44:36 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 25 Sep 2006 05:44:36 -0500
Subject: [Masterview-devel] Code review request: support layouts in MV
	Admin pages
In-Reply-To: <20060924230417.CRDA6711.fed1rmmtao04.cox.net@fed1rmimpo01.cox.net>
References: <20060924230417.CRDA6711.fed1rmmtao04.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190609250344i152a0e96gb38ea6a3e7bca952@mail.gmail.com>

On 9/24/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - it was really bugging me that our admin pages weren't able to use
> layouts, so I poked around in ActionController's implementation and figured
> out what I think is a safe/stable way to slide in alongside the standard
> services.
>
> So the main index/list page and the three config info pages now use layouts.
> (We should clean up the other pages in there at some point, but I'm punting
> for now, need to go back and finish some loose ends in directive metadata
> mechanisms)
>
> Background: problem was that the base Rails layout mechanism has an
> assumption about working (only) in the context of app/views/layouts dir
> bolted down in its roots.  But we want to be able to render with a layout
> file that we pull up from the mv installation dir (plugin or gem).
>
> **Please code review this and test on your system!!  I'm running Rails
> 1.1.2; I think/hope this area of Rails is pretty stable w.r.t the way I
> wrote this code, but testing on newer versions would be good.
>
> Our hook is installed as
> ActionController::Base.masterview_render_file_with_layout; impl is in
> masterview_controller (at least for now - someday I'd like to maybe
> reorganize our rails extensions into an explicit rails_ext dir, along the
> lines of how rails organizes its core ruby extensions, which I think is a
> good clear way to manage these).
>
> I didn't check into rails issues db to see if there's any outstanding
> tickets on this, supposed it would be good to add and maybe propose a patch,
> but need to go over protocol issues before making such a proposal for
> general use.
>

Good idea Deb! I am still working on my presentation for tomorrow but
will check out what you have after that. I'll make sure the code is
working in 1.1.6 and Rails edge.