From jeff.barczewski at gmail.com  Tue Oct  3 17:43:27 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 3 Oct 2006 16:43:27 -0500
Subject: [Masterview-devel] [Masterview-users] mv:text_input id is
	overriding the id of the input field
In-Reply-To: <3df642dd0610031022o54c06033x1312c66b9548e39a@mail.gmail.com>
References: <3df642dd0610031022o54c06033x1312c66b9548e39a@mail.gmail.com>
Message-ID: <19cda190610031443x3431115ejc28e5347af082152@mail.gmail.com>

On 10/3/06, Ed Howland <ed.howland at gmail.com> wrote:
> If you have an input tag like this:
> <input type="text" name="fax" id="fax" size="20" mv:text_input="contact,fax" />
>
> You get:
>   <%= text_field "contact", "fax", :id => "fax", :size => 20 %>
> which results in
> <input type="text" name="contact[fax]" id="fax" size="20" />
> instead of
>   <%= text_field "contact", "fax", :size => 20 %>
> which would result in
> <input type="text" name="contact[fax]" id="contact_fax" size="20" />
>
> Is this intentional? I point this out because 'name' is not copied
> from the parent element, and many WYSIWYG editors (like DW)
> automatically fill out the id and name attributes. Which makes us
> manually have to remove them from the HTML.
>

Yes, if you specify the id of an element, then typically you are
wanting to use that id for javascript or to be able to quickly
reference it later.

You could add an additional directive mv:attr=":id => 'contact_fax'"
to override it before it gets to mv:text_field, however that's extra
work so maybe we should figure out a better way.

I assume that DW setting this id on you is causing you problems and
there isn't any apparent way to make it stop doing that.

So rather than make you have to add mv:attr in we could add a new
option flag to the directive which would prevent this or we can create
a new directive that simply doesn't set the id. I'll bounce this off
Deb and see what seems the cleanest to her. I'm kind of leaning
towards an option for the directive but either way is fine.

Thanks for the heads up on the issue. I hadn't run in to that yet
(mostly since I don't have Dreamweaver). Much like NVU I wish these
products were more configurable so that you can get them to do what
you want :-) Of course since NVU is open source, I don't have much of
an excuse I just need to dive in and change the code :-)

Deb, if you get a chance let me know what you think.

Jeff

From djlewis at acm.org  Wed Oct  4 00:27:29 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 3 Oct 2006 21:27:29 -0700
Subject: [Masterview-devel] [Masterview-users] mv:text_input id is
	overriding the id of theinput field
In-Reply-To: <19cda190610031443x3431115ejc28e5347af082152@mail.gmail.com>
Message-ID: <20061004042732.PRZU6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>

I think our masterview directives which map onto rails form helpers need to
take the behavior/semantics of the helper into account when passing on
attributes from the template markup.  Passing on the id attribute from the
source template when the rails helper is going to (re)generate it from its
name argument simply seems wrong and you shouldn't have to provide
additional markup to tell the directive not to do something that it ought to
be able to figure out isn't sensible.

If working with an editing tool which is going to create the name or id
attribute anyway, then seems like you ought to be able to either omit the
first arg to mv:text_field or provide a distinguished value
(mv:text_field="*,theValue"), with the semantics being "hey, the name/id is
already there, use the value from the element attribute".  Don't make me say
things twice.

If the name arg *is* specified, then perhaps the appropriate semantics are
that the intent is to override any name/id markup on the attribute - hey,
I'm asking for the rails helper and this is exactly what I want.  So if
mv_text_field has name value specified, it should *not* pass on name/id
attributes from the source element.

On a bit of a tangent perhaps:  I'm trying to wrap up a rework of the
directive mechanisms for how metadata properties are specified (per
directive or per-directory, notably specifying alt name spaces).  I keep
speculating that perhaps the mechanism should be extended to support some
notion of configuring properties for specific directives that want
themselves to be configurable by the application in some fashion.  That
would let a DW user configure the policy for handling name/id values on form
elements if the tool has some standard behavior that would entail some
different behavior from the mv directive than some other user might want for
their templates.

~ Deb 

-----Original Message-----
From: masterview-users-bounces at rubyforge.org
[mailto:masterview-users-bounces at rubyforge.org] On Behalf Of Jeff Barczewski
Sent: Tuesday, October 03, 2006 2:43 PM
To: masterview-users at rubyforge.org; masterview-devel at rubyforge.org
Subject: Re: [Masterview-users] mv:text_input id is overriding the id of
theinput field

On 10/3/06, Ed Howland <ed.howland at gmail.com> wrote:
> If you have an input tag like this:
> <input type="text" name="fax" id="fax" size="20" 
> mv:text_input="contact,fax" />
>
> You get:
>   <%= text_field "contact", "fax", :id => "fax", :size => 20 %> which 
> results in <input type="text" name="contact[fax]" id="fax" size="20" 
> /> instead of
>   <%= text_field "contact", "fax", :size => 20 %> which would result 
> in <input type="text" name="contact[fax]" id="contact_fax" size="20" 
> />
>
> Is this intentional? I point this out because 'name' is not copied 
> from the parent element, and many WYSIWYG editors (like DW) 
> automatically fill out the id and name attributes. Which makes us 
> manually have to remove them from the HTML.
>

Yes, if you specify the id of an element, then typically you are wanting to
use that id for javascript or to be able to quickly reference it later.

You could add an additional directive mv:attr=":id => 'contact_fax'"
to override it before it gets to mv:text_field, however that's extra work so
maybe we should figure out a better way.

I assume that DW setting this id on you is causing you problems and there
isn't any apparent way to make it stop doing that.

So rather than make you have to add mv:attr in we could add a new option
flag to the directive which would prevent this or we can create a new
directive that simply doesn't set the id. I'll bounce this off Deb and see
what seems the cleanest to her. I'm kind of leaning towards an option for
the directive but either way is fine.

Thanks for the heads up on the issue. I hadn't run in to that yet (mostly
since I don't have Dreamweaver). Much like NVU I wish these products were
more configurable so that you can get them to do what you want :-) Of course
since NVU is open source, I don't have much of an excuse I just need to dive
in and change the code :-)

Deb, if you get a chance let me know what you think.

Jeff
_______________________________________________
Masterview-users mailing list
Masterview-users at rubyforge.org
http://rubyforge.org/mailman/listinfo/masterview-users



From jeff.barczewski at gmail.com  Wed Oct  4 12:49:39 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 4 Oct 2006 11:49:39 -0500
Subject: [Masterview-devel] [Masterview-users] mv:text_input id is
	overriding the id of theinput field
In-Reply-To: <20061004042732.PRZU6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>
References: <19cda190610031443x3431115ejc28e5347af082152@mail.gmail.com>
	<20061004042732.PRZU6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610040949p5586e2eeqc5a3363ec6b38e92@mail.gmail.com>

On 10/3/06, Deb Lewis <djlewis at acm.org> wrote:
> I think our masterview directives which map onto rails form helpers need to
> take the behavior/semantics of the helper into account when passing on
> attributes from the template markup.  Passing on the id attribute from the
> source template when the rails helper is going to (re)generate it from its
> name argument simply seems wrong and you shouldn't have to provide
> additional markup to tell the directive not to do something that it ought to
> be able to figure out isn't sensible.

I see your point, but one might want to legitimately override this
default id that rails provides, especially if you have multiple forms
on the screen that update different things, the simple context it
provides might not be enough. For instance one might have edit forms
for different parties both having contact_address, so the id needs to
be unique and one might want to tell rails what id to use so that you
can then do ajaxy things.

And you may very well want to have these id's setup in your html
template so that you can test out css styling and javascripts. So it
becomes important to respect the id that is in the html template if
provided.

>
> If working with an editing tool which is going to create the name or id
> attribute anyway, then seems like you ought to be able to either omit the
> first arg to mv:text_field or provide a distinguished value
> (mv:text_field="*,theValue"), with the semantics being "hey, the name/id is
> already there, use the value from the element attribute".  Don't make me say
> things twice.
>

Yes we could pull the name from a name attribute if provided.


> If the name arg *is* specified, then perhaps the appropriate semantics are
> that the intent is to override any name/id markup on the attribute - hey,
> I'm asking for the rails helper and this is exactly what I want.  So if
> mv_text_field has name value specified, it should *not* pass on name/id
> attributes from the source element.

So if I understand what you are suggesting here is that if the name in
mv:text_field is not * then don't pull name or id attributes. I'm not
sure if I like the name specification also triggering whether id is
pulled, seems a little surprising.

>
> On a bit of a tangent perhaps:  I'm trying to wrap up a rework of the
> directive mechanisms for how metadata properties are specified (per
> directive or per-directory, notably specifying alt name spaces).  I keep
> speculating that perhaps the mechanism should be extended to support some
> notion of configuring properties for specific directives that want
> themselves to be configurable by the application in some fashion.  That
> would let a DW user configure the policy for handling name/id values on form
> elements if the tool has some standard behavior that would entail some
> different behavior from the mv directive than some other user might want for
> their templates.
>

Maybe that is the middle ground we are searching for. A way to tweak
the operation of directives without requiring duplicate directives or
additional options. A way to set some default behavior. Would we want
to do this at the app level or page level? Would there be anyway to
override a behavior for one specific instance? (might not need that
last one if we are talking about default behavior, for instance one
could go ahead and specify :id => foo in the mv:text_field if they
wanted to override default behavior or not setting ids).

So I think this might be a good approach give us lots of power to
customize for each usage. We could have global settings and directive
specific settings that are all provided to the directive where they
can be used to influence behavior.

So Ed would set something at the app or page level that would say I
don't want any ids and that would be it.

Jeff on the other hand likes ids, if I specify them use em. So my
setting would be different.

I like it!!

So back to the question where should that default behavior
configuration go app or page level or both (page overrides app
settings)?

Jeff

From djlewis at acm.org  Wed Oct  4 21:36:22 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 4 Oct 2006 18:36:22 -0700
Subject: [Masterview-devel] status - rework for more flexible config of
	directive metadata
In-Reply-To: <19cda190610041021h2cdc3e78x76b772d007db9b87@mail.gmail.com>
Message-ID: <20061005013627.JQAD2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>

Jeff - I finally tracked down the problem I've been stuck on to some dopey
class var initialization ordering, so the rework I did last week to enable
metadata config options to be set at the app level as well as in directive
directories .metadata defaults, along with internal reorg of parser and
directive loading seems to be working.

Ran all the unit tests, plus did a quick regression test in my simple app
with a couple custom directives, all ok.

But.. I've been tearing my hair out for hours about why the tests break when
I run the entire suite.  Sigh.  One of my tests for the new features is
apparently fiddling the system state s.t. things don't get reset properly
and I can't for the life of me find which one right now.  Tired, giving up
for now.

Anyway, I think it's close, I hope this'll settle so I can get it committed
tomorrow.

~ Deb



From jeff.barczewski at gmail.com  Thu Oct  5 05:42:59 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 5 Oct 2006 04:42:59 -0500
Subject: [Masterview-devel] status - rework for more flexible config of
	directive metadata
In-Reply-To: <20061005013627.JQAD2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
References: <19cda190610041021h2cdc3e78x76b772d007db9b87@mail.gmail.com>
	<20061005013627.JQAD2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190610050242r54854c33q994836ec75a409ea@mail.gmail.com>

On 10/4/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - I finally tracked down the problem I've been stuck on to some dopey
> class var initialization ordering, so the rework I did last week to enable
> metadata config options to be set at the app level as well as in directive
> directories .metadata defaults, along with internal reorg of parser and
> directive loading seems to be working.
>
> Ran all the unit tests, plus did a quick regression test in my simple app
> with a couple custom directives, all ok.
>
> But.. I've been tearing my hair out for hours about why the tests break when
> I run the entire suite.  Sigh.  One of my tests for the new features is
> apparently fiddling the system state s.t. things don't get reset properly
> and I can't for the life of me find which one right now.  Tired, giving up
> for now.

Yeah I know how that goes. Well taking a break from it and coming back
fresh usually lets me see the problem fairly quickly, rather than
being up all night banging my head on the computer, hopefully the same
will be true for  you.

>
> Anyway, I think it's close, I hope this'll settle so I can get it committed
> tomorrow.
>

Sounds wonderful!

From djlewis at acm.org  Thu Oct  5 15:16:33 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 5 Oct 2006 12:16:33 -0700
Subject: [Masterview-devel] Unit tests and directive loading
Message-ID: <20061005191637.HVVR12909.fed1rmmtao05.cox.net@fed1rmimpo01.cox.net>

Jeff - figured out why running the unit test suite went whacko even though
individual tests all run.  Combination of not having a check in directive
unit tests that exposed the issue (the "missing test" condition!) and a
legit consequence of the changes being mad in directive loading, metadata
specification, and shift to separate mv: and mvx: namespaces (builtin vs.
addon directives).

So... I have to make a sweep over *all* the unit tests for directives and
tweak their loading setup; simply doing require on the direcive impl class
doesn't have the same effect as "normal" masterview system loading anymore.
[explanation below].

Not thrilled with this and it has ripples out to how a directive developer
has to set up their tests as well, but don't see an alternative yet.  

We needed to make a cleanup pass through our directive test cases anyway to
switch everything over to the simplifed DirectiveTestHelper services, so
this was needed at some point anyway.

~ Deb

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

ON DIRECTIVE LOADING, METADATA DEFAULTS, AND NAMESPACES

I starting writing this up here and it got long and I concluded we should
capture this more reliably in our own documentation, so I put a design note
on this subject into our underutilized masterview-devel project that resides
alongside the main masterview code project in the repository:

masterview/trunk/masterview-devel/design_notes/DirectiveLoadingAndMetadataDe
faults.txt

Some form of this eventually ought to get into proper docs in the masterview
project proper, but for now I just wanted to capture the working design
notes and rationale.

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



From jeff.barczewski at gmail.com  Fri Oct  6 11:03:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Fri, 6 Oct 2006 10:03:23 -0500
Subject: [Masterview-devel] Unit tests and directive loading
In-Reply-To: <20061005191637.HVVR12909.fed1rmmtao05.cox.net@fed1rmimpo01.cox.net>
References: <20061005191637.HVVR12909.fed1rmmtao05.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190610060803g62f268cfk57c58cdd3eca526f@mail.gmail.com>

On 10/5/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - figured out why running the unit test suite went whacko even though
> individual tests all run.  Combination of not having a check in directive
> unit tests that exposed the issue (the "missing test" condition!) and a
> legit consequence of the changes being mad in directive loading, metadata
> specification, and shift to separate mv: and mvx: namespaces (builtin vs.
> addon directives).
>
> So... I have to make a sweep over *all* the unit tests for directives and
> tweak their loading setup; simply doing require on the direcive impl class
> doesn't have the same effect as "normal" masterview system loading anymore.
> [explanation below].
>
> Not thrilled with this and it has ripples out to how a directive developer
> has to set up their tests as well, but don't see an alternative yet.
>
> We needed to make a cleanup pass through our directive test cases anyway to
> switch everything over to the simplifed DirectiveTestHelper services, so
> this was needed at some point anyway.
>
> ~ Deb
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> ON DIRECTIVE LOADING, METADATA DEFAULTS, AND NAMESPACES
>
> I starting writing this up here and it got long and I concluded we should
> capture this more reliably in our own documentation, so I put a design note
> on this subject into our underutilized masterview-devel project that resides
> alongside the main masterview code project in the repository:
>
> masterview/trunk/masterview-devel/design_notes/DirectiveLoadingAndMetadataDe
> faults.txt
>
> Some form of this eventually ought to get into proper docs in the masterview
> project proper, but for now I just wanted to capture the working design
> notes and rationale.
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

Ok, thanks for the heads up. I will take a look at it.

From djlewis at acm.org  Sat Oct  7 16:22:29 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 7 Oct 2006 13:22:29 -0700
Subject: [Masterview-devel] Unit tests and directive loading
In-Reply-To: <20061005191637.HVVR12909.fed1rmmtao05.cox.net@fed1rmimpo01.cox.net>
Message-ID: <20061007202232.XYWD6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>

status: spent a good part of yesterday doing complete cleanup pass over all
the unit tests to hook them into the directive-test-helper framework.  Big
improvement, you can now look at a test case and have an idea of what it
thinks it ought to be doing.  

[which i for sure couldn't do before, when the essence of the test was
buried under mounds of directive sets and dcs's and logistical internals!]

Spent all morning today rewriting some core portions of the metadata
infrastructure trying to hunt down source of subtle bug that intermittently
showed up as inconsistent metadata values.  Finally found a subtle timing
problem related to to the notification from ruby's class machinery about our
directive base class being inherited, which we use to pick up additions to
the set of known directives.

So after all that... all the individual unit tests run, my basic test site
with MV templates plus custom directive usage runs, and.... I still get a
failure when running the entire suite.  Some test is somehow affecting the
state of the directive registry s.t. the template parsing test case doesn't
find the builtin directives.  

Out of ideas for now on how else to debug the tests, taking a break.  I
think the problem is the tests, not the actual code, but there it is.

~ Deb



From djlewis at acm.org  Sat Oct  7 19:11:41 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 7 Oct 2006 16:11:41 -0700
Subject: [Masterview-devel] Directive metadata config rework,
	unit tests overhaul committed
Message-ID: <20061007231142.EVCA22977.fed1rmmtao08.cox.net@fed1rmimpo02.cox.net>

Finally found what was causing the problem with directive resolution when
running the entire test suite as a whole, so committed all the code changes.
There's still a bunch of trashy code and leftover debugging/tracing hooks
from my attempts to track down the timing/loading problems; eventually that
should be cleaned up, but for the short term I'd like to keep that around
just in case some other problem with this rework shows up.

I've got a little more cleanup and polishing to do in some of the directive
classes and unit tests, plus some final additions to the docs, but I
think/hope this should wrap up the bulk of this work.  Finally!!

~ Deb



From djlewis at acm.org  Sun Oct  8 01:06:55 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 7 Oct 2006 22:06:55 -0700
Subject: [Masterview-devel] Admin page doesn't render properly in IE
Message-ID: <20061008050658.MKYV22977.fed1rmmtao08.cox.net@fed1rmimpo01.cox.net>

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]

~ Deb



From djlewis at acm.org  Sun Oct  8 14:41:30 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 8 Oct 2006 11:41:30 -0700
Subject: [Masterview-devel] Code review request
Message-ID: <20061008184133.ALQ22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>

Jeff - please code review the changes I'm proposing to make to analyzer.rb
before I submit that; I ended up doing more than just cosmetic name-changing
and I'm not sure how good how test coverage is in this area, so I'd like you
to check before I commit.

Objective: getting rid of the MasterView::NamespacePrefix constant(s), I
don't think a module-level constant is the right way to expose that, esp.
since we now have 2 flavors of namespace defaults (mv: and mvx:).

rubyforge.org/var/svn/masterview/branches/djl-analyzer-changes-preview/analy
zer.rb - I put out a copy from the trunk and then stored changes so you
should be able to diff the two versions there in the branch.

Thanks.

~ Deb



From djlewis at acm.org  Sun Oct  8 16:37:23 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 8 Oct 2006 13:37:23 -0700
Subject: [Masterview-devel] Conditional global directives
Message-ID: <20061008203730.ZEBB12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

I'm adding a support for a variation of the :global_directive? mechanism
that we currently use for unconditionally installing the GlobalInlineErb
directive.  Purpose is to allow a directive to conditionally install itself
on an element even if not explictly specified in the markup.

Details below.  Let me know what you think.

~ Deb

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

Use case: I have a custom directive in my app that I want applied to all
<img> elements and I don't want to have to manually annotate each document.
My template docs use local refs to some images for design-time viewing that
need to be mapped to the rails asset dirs in the running site.  I don't care
about the rails image helper because my template already says what it needs
to, so mv:image_tag isn't relevant.

The explicit directive markup I'd have to use would be:

   <img class="docIcon" src="../ximages/mydocimage.gif" mvx:image_attrs=""
/>

but I really want to simply write what I would have in my normal html
markup:

   <img class="docIcon" src="../ximages/mydocimage.gif" />

Experimenting a bit with the protocol and metadata decl notation.  Basic
idea is that the metadata value specifies 'true' for unconditional use
(GlobalInlineErb), or a callback which takes args tag_name and element_attrs
and returns the attr_value for instantiating the directive if it wants to be
activated or nil/false if not applicable.

E.g., my global img element directive specifies its activation condition as:

      metadata :priority => :default,
        :global_directive? => Proc.new { | tag_name, element_attrs | 
          # activate on all <img> attributes w/out explicit directive markup
          ( tag_name == 'img' && ! element_attrs.has_key?( attribute_qname )
) ? '' : false
          }

A more general variation of this might also check for mv:image_tag, although
in my case I don't bother because I don't use that.

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



From jeff.barczewski at gmail.com  Mon Oct  9 10:32:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 9 Oct 2006 09:32:35 -0500
Subject: [Masterview-devel] Conditional global directives
In-Reply-To: <20061008203730.ZEBB12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20061008203730.ZEBB12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610090732o37862230s95c3c41e3f6e8c4e@mail.gmail.com>

On 10/8/06, Deb Lewis <djlewis at acm.org> wrote:
> I'm adding a support for a variation of the :global_directive? mechanism
> that we currently use for unconditionally installing the GlobalInlineErb
> directive.  Purpose is to allow a directive to conditionally install itself
> on an element even if not explictly specified in the markup.
>
> Details below.  Let me know what you think.
>
> ~ Deb
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> Use case: I have a custom directive in my app that I want applied to all
> <img> elements and I don't want to have to manually annotate each document.
> My template docs use local refs to some images for design-time viewing that
> need to be mapped to the rails asset dirs in the running site.  I don't care
> about the rails image helper because my template already says what it needs
> to, so mv:image_tag isn't relevant.
>
> The explicit directive markup I'd have to use would be:
>
>    <img class="docIcon" src="../ximages/mydocimage.gif" mvx:image_attrs=""
> />
>
> but I really want to simply write what I would have in my normal html
> markup:
>
>    <img class="docIcon" src="../ximages/mydocimage.gif" />
>
> Experimenting a bit with the protocol and metadata decl notation.  Basic
> idea is that the metadata value specifies 'true' for unconditional use
> (GlobalInlineErb), or a callback which takes args tag_name and element_attrs
> and returns the attr_value for instantiating the directive if it wants to be
> activated or nil/false if not applicable.
>
> E.g., my global img element directive specifies its activation condition as:
>
>       metadata :priority => :default,
>         :global_directive? => Proc.new { | tag_name, element_attrs |
>           # activate on all <img> attributes w/out explicit directive markup
>           ( tag_name == 'img' && ! element_attrs.has_key?( attribute_qname )
> ) ? '' : false
>           }
>
> A more general variation of this might also check for mv:image_tag, although
> in my case I don't bother because I don't use that.
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
>


That sounds pretty good!! I will look closer at it.

Does this or should this be related in anyway to the ability to
customize default options for directives? Kind of seems like one could
specify something like this at the app or page level similar to what
we were thinking about for default settings. Something like this might
allow one to use standard directives in a similar fashion. For
instance the app or page level setting might provide a block that gets
executed determining whether it is a global_directive and it might
allow the massaging of attributes (and the directive's attribute) as
well setting some default behavior.

Just wondering what you thought.

From djlewis at acm.org  Mon Oct  9 11:15:50 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 9 Oct 2006 08:15:50 -0700
Subject: [Masterview-devel] Conditional global directives
In-Reply-To: <19cda190610090732o37862230s95c3c41e3f6e8c4e@mail.gmail.com>
Message-ID: <20061009151554.WANY12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

... 
>> ... related in anyway to the ability to customize default options 
>> for directives? ... specify something like this at the app or page level 
>> similar to what we were thinking about for default settings. 

Yeah, might be interesting, would like to think about this whole area a bit
more before we decide what/how to tackle.  I kind of tabled the
per-directive config setting until everything else got settled, too many
things broken and in flux to cope with new ideas.  But I think this notion
will be useful.

Per-page mv config might be done with a directive that we introduce for that
purpose - maybe an element containing the code to evaluate so that
notationally it follows the same pattern as in the mv config settings .rb
files. 

BTW note that the config settings we introduced recently to allow
customization of the relative paths for assets (images, stylesheets) are
really a case of per-directive customization - we just didn't recognize that
at the tme!

~ Deb



From jeff.barczewski at gmail.com  Mon Oct  9 15:58:26 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 9 Oct 2006 14:58:26 -0500
Subject: [Masterview-devel] Conditional global directives
In-Reply-To: <20061009151554.WANY12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <19cda190610090732o37862230s95c3c41e3f6e8c4e@mail.gmail.com>
	<20061009151554.WANY12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610091258l6da8a62cl96ad8e92b80ea2e3@mail.gmail.com>

On 10/9/06, Deb Lewis <djlewis at acm.org> wrote:
> ...
> >> ... related in anyway to the ability to customize default options
> >> for directives? ... specify something like this at the app or page level
> >> similar to what we were thinking about for default settings.
>
> Yeah, might be interesting, would like to think about this whole area a bit
> more before we decide what/how to tackle.  I kind of tabled the
> per-directive config setting until everything else got settled, too many
> things broken and in flux to cope with new ideas.  But I think this notion
> will be useful.

Yes, I agree.

>
> Per-page mv config might be done with a directive that we introduce for that
> purpose - maybe an element containing the code to evaluate so that
> notationally it follows the same pattern as in the mv config settings .rb
> files.

That sounds like a nice approach.

>
> BTW note that the config settings we introduced recently to allow
> customization of the relative paths for assets (images, stylesheets) are
> really a case of per-directive customization - we just didn't recognize that
> at the tme!
>

Sooner or later things evolve into what they need to be :-)

From jeff.barczewski at gmail.com  Tue Oct 10 14:38:21 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 10 Oct 2006 13:38:21 -0500
Subject: [Masterview-devel] [Masterview-users] Safer code in rendered
	output
In-Reply-To: <3df642dd0610091637h2c8bdc7dvb218d2bcd18dab26@mail.gmail.com>
References: <3df642dd0610091637h2c8bdc7dvb218d2bcd18dab26@mail.gmail.com>
Message-ID: <19cda190610101138i13386601v84266ecbe45e0c2b@mail.gmail.com>

On 10/9/06, Ed Howland <ed.howland at gmail.com> wrote:
> When rendering the directives into tags, you should almost always use
> the 'fn(p1, p2)' form rather than the 'fn  p1, p2' style. This is
> because you can't predict what extra options the users are going to
> put on the mv: directives. W/o doing this, some ERb stuff is going to
> barf in Ruby because eventually, it all gets compiled down to a call
> to:
>  _erbout(  .... )
>
> Passing multiple hashes to mv: directives like mv:form in order to put
> html_options will cause this
> problem.
>
> Note: You can get around the problem by explicitly parenthesizing
> stuff like this:
>
> <form .... mv:form="({:action => 'chart'},  {:name => 'chart'})">
>
> It may look prettier in the rendered output, but you should always opt
> for the safer output.
>
> Ed
> --

We do test the ability to pass in multiple hashes with the directives
but you are right that it can get tricky depending on the scenario.

I did have some directive tests for multiple hashes (link_to) and
others so we were trying to make sure that they worked.

However let me go back and review those test cases and also make sure
that erb was working with the output of those as well. Sounds like you
for sure hit a situation when it didn't.

If that is the case then it is fairly easy change to change to
method() style output with the new refactoring. And I think you are
right in that it is safer (easier for the parser to interpret).

Thanks for the heads up.

Jeff

From jeff.barczewski at gmail.com  Wed Oct 11 13:50:13 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 11 Oct 2006 12:50:13 -0500
Subject: [Masterview-devel] Conditional global directives
In-Reply-To: <20061008203730.ZEBB12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20061008203730.ZEBB12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610111050ncbdd35o24dcbd7412e90886@mail.gmail.com>

On 10/8/06, Deb Lewis <djlewis at acm.org> wrote:
> I'm adding a support for a variation of the :global_directive? mechanism
> that we currently use for unconditionally installing the GlobalInlineErb
> directive.  Purpose is to allow a directive to conditionally install itself
> on an element even if not explictly specified in the markup.
>
> Details below.  Let me know what you think.
>
> ~ Deb
>
> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
> Use case: I have a custom directive in my app that I want applied to all
> <img> elements and I don't want to have to manually annotate each document.
> My template docs use local refs to some images for design-time viewing that
> need to be mapped to the rails asset dirs in the running site.  I don't care
> about the rails image helper because my template already says what it needs
> to, so mv:image_tag isn't relevant.
>
> The explicit directive markup I'd have to use would be:
>
>    <img class="docIcon" src="../ximages/mydocimage.gif" mvx:image_attrs=""
> />
>
> but I really want to simply write what I would have in my normal html
> markup:
>
>    <img class="docIcon" src="../ximages/mydocimage.gif" />
>
> Experimenting a bit with the protocol and metadata decl notation.  Basic
> idea is that the metadata value specifies 'true' for unconditional use
> (GlobalInlineErb), or a callback which takes args tag_name and element_attrs
> and returns the attr_value for instantiating the directive if it wants to be
> activated or nil/false if not applicable.
>
> E.g., my global img element directive specifies its activation condition as:
>
>       metadata :priority => :default,
>         :global_directive? => Proc.new { | tag_name, element_attrs |
>           # activate on all <img> attributes w/out explicit directive markup
>           ( tag_name == 'img' && ! element_attrs.has_key?( attribute_qname )
> ) ? '' : false
>           }
>
> A more general variation of this might also check for mv:image_tag, although
> in my case I don't bother because I don't use that.
>

Looks like a nice addition.

From jeff.barczewski at gmail.com  Wed Oct 11 14:30:02 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 11 Oct 2006 13:30:02 -0500
Subject: [Masterview-devel] It appears that we need to enclose our method
	calls in parens so ERB can parse complex methods - Re:
	[Masterview-users] Safer code in rendered output
Message-ID: <19cda190610111130maefc5bcj9cbcd7fd152c5e55@mail.gmail.com>

On 10/10/06, Jeff Barczewski <jeff.barczewski at gmail.com> wrote:
> On 10/9/06, Ed Howland <ed.howland at gmail.com> wrote:
> > When rendering the directives into tags, you should almost always use
> > the 'fn(p1, p2)' form rather than the 'fn  p1, p2' style. This is
> > because you can't predict what extra options the users are going to
> > put on the mv: directives. W/o doing this, some ERb stuff is going to
> > barf in Ruby because eventually, it all gets compiled down to a call
> > to:
> >  _erbout(  .... )
> >
> > Passing multiple hashes to mv: directives like mv:form in order to put
> > html_options will cause this
> > problem.
> >
> > Note: You can get around the problem by explicitly parenthesizing
> > stuff like this:
> >
> > <form .... mv:form="({:action => 'chart'},  {:name => 'chart'})">
> >
> > It may look prettier in the rendered output, but you should always opt
> > for the safer output.
> >
> > Ed
> > --
>
> We do test the ability to pass in multiple hashes with the directives
> but you are right that it can get tricky depending on the scenario.
>
> I did have some directive tests for multiple hashes (link_to) and
> others so we were trying to make sure that they worked.
>
> However let me go back and review those test cases and also make sure
> that erb was working with the output of those as well. Sounds like you
> for sure hit a situation when it didn't.
>
> If that is the case then it is fairly easy change to change to
> method() style output with the new refactoring. And I think you are
> right in that it is safer (easier for the parser to interpret).
>
> Thanks for the heads up.
>

Deb,

I have confirmed Ed's finding that erb cannot handle parsing of
form_tag with multiple hashes without the surrounding parens. So I
guess the best solution is for the directives to render parens around
the arguments. This is a simple fix in the new code since
prepare_output gets all the arguments ready for erb_content, however I
will have to go through and update a bunch of test cases.

Let me know if you see any reason why we shouldn't always put parens
around directive generated methods (to help out ERB). I should be able
to go through and make the changes tomorrow morning.

PS. rubyforge appears to be down so, copy me directly on this reply so
I get it sooner.

Jeff

From jeff.barczewski at gmail.com  Wed Oct 11 13:42:33 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 11 Oct 2006 12:42:33 -0500
Subject: [Masterview-devel] Code review request
In-Reply-To: <20061008184133.ALQ22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>
References: <20061008184133.ALQ22409.fed1rmmtao04.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610111042i71d7f4a0h1e565c4be6189d5@mail.gmail.com>

On 10/8/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - please code review the changes I'm proposing to make to analyzer.rb
> before I submit that; I ended up doing more than just cosmetic name-changing
> and I'm not sure how good how test coverage is in this area, so I'd like you
> to check before I commit.
>
> Objective: getting rid of the MasterView::NamespacePrefix constant(s), I
> don't think a module-level constant is the right way to expose that, esp.
> since we now have 2 flavors of namespace defaults (mv: and mvx:).
>
> rubyforge.org/var/svn/masterview/branches/djl-analyzer-changes-preview/analy
> zer.rb - I put out a copy from the trunk and then stored changes so you
> should be able to diff the two versions there in the branch.

I reviewed the code Deb and I think it looks good. Go ahead and
commit. Once you commit it to the trunk we'll just have to test this
code to be sure.

Thanks,

Jeff

From djlewis at acm.org  Thu Oct 12 01:11:17 2006
From: djlewis at acm.org (Deb Lewis)
Date: Wed, 11 Oct 2006 22:11:17 -0700
Subject: [Masterview-devel] It appears that we need to enclose our
	method calls in parens so ERB can parse complex methods - Re:
	[Masterview-users] Safer code in rendered output
In-Reply-To: <19cda190610111130maefc5bcj9cbcd7fd152c5e55@mail.gmail.com>
Message-ID: <20061012051120.LLCO16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>

Jeff - I should probably go through some of the code and some examples
again, but I think I agree with Ed that our directive implementations should
be emitting parenthesized fcn call notation.

I really don't see any downside.  It's slightly less declarative looking in
simple cases, but then this is generated code and correctness is more
important.

There are cases where the paren-less function notation permitted by Ruby is
quite nice (all the DSL-style, declarative notations that it enabled), but I
certainly find for my own coding style that are many situations where the
more traditional notation with parens seems more approprate.

While our generated code might use parens that perhaps you'd have omitted if
writing the equivalent .rhtml by hand, I think anyone reading the output
will not be confused by the paren notation.

Nobody should *ever* have to write the sort of markup Ed described:

> > Note: You can get around the problem by explicitly parenthesizing 
> > stuff like this:
> >
> > <form .... mv:form="({:action => 'chart'},  {:name => 'chart'})">
> >
>

So I'd vote to proceed with this.  Changing/improving tests cases as a side
effect is a good thing.

[all yours, I'm not in any of that code right now.  Just working on
finishing up some final sections of the developer's documentation for the
new directive implementation mechanism]

~ Deb



From jeff.barczewski at gmail.com  Thu Oct 12 17:05:44 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 12 Oct 2006 16:05:44 -0500
Subject: [Masterview-devel] It appears that we need to enclose our
	method calls in parens so ERB can parse complex methods - Re:
	[Masterview-users] Safer code in rendered output
In-Reply-To: <20061012051120.LLCO16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
References: <19cda190610111130maefc5bcj9cbcd7fd152c5e55@mail.gmail.com>
	<20061012051120.LLCO16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610121405o35cb7cc3j22cce660c2d21c15@mail.gmail.com>

On 10/12/06, Deb Lewis <djlewis at acm.org> wrote:
> Jeff - I should probably go through some of the code and some examples
> again, but I think I agree with Ed that our directive implementations should
> be emitting parenthesized fcn call notation.
>
> I really don't see any downside.  It's slightly less declarative looking in
> simple cases, but then this is generated code and correctness is more
> important.
>
> There are cases where the paren-less function notation permitted by Ruby is
> quite nice (all the DSL-style, declarative notations that it enabled), but I
> certainly find for my own coding style that are many situations where the
> more traditional notation with parens seems more approprate.
>
> While our generated code might use parens that perhaps you'd have omitted if
> writing the equivalent .rhtml by hand, I think anyone reading the output
> will not be confused by the paren notation.
>
> Nobody should *ever* have to write the sort of markup Ed described:
>

I fully agree. Just wanted to make sure before I changed all the test cases :-)

Thanks again Ed for bringing this to our attention.

From djlewis at acm.org  Tue Oct 17 08:53:14 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 17 Oct 2006 05:53:14 -0700
Subject: [Masterview-devel] Code review: adding parens in generated output
	erb
Message-ID: <20061017125323.PKZL12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>

I think the resulting expressions using paren'd function notation is fine.

But.. it's a bit odd to see "if( foo )" and "elseif( bar )" without a space,
though it does seem to parse correctly.  Dunno if it's worth adding a
special-case check for conditional keywords vs. function name in
prepare_output.

~ Deb



From jeff.barczewski at gmail.com  Tue Oct 17 11:07:59 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 17 Oct 2006 10:07:59 -0500
Subject: [Masterview-devel] Code review: adding parens in generated
	output erb
In-Reply-To: <20061017125323.PKZL12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
References: <20061017125323.PKZL12909.fed1rmmtao05.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610170807y34884c55g9aa4751acd128a4@mail.gmail.com>

Great.

Well personally when I use the parens with conditionals I usually do
it without the space (like it is), but we can do something special if
you think it is necessary, otherwise I think simple is good.

Jeff

On 10/17/06, Deb Lewis <djlewis at acm.org> wrote:
> I think the resulting expressions using paren'd function notation is fine.
>
> But.. it's a bit odd to see "if( foo )" and "elseif( bar )" without a space,
> though it does seem to parse correctly.  Dunno if it's worth adding a
> special-case check for conditional keywords vs. function name in
> prepare_output.
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>

From jeff.barczewski at gmail.com  Tue Oct 17 11:10:23 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Tue, 17 Oct 2006 10:10:23 -0500
Subject: [Masterview-devel] Testing this weekend went fine,
	except I found a problem with rails edge
Message-ID: <19cda190610170810lbb05bem79497fec4bcf8c27@mail.gmail.com>

Testing this weekend went fine, except I found a problem with rails
edge. They refactored some things so I am in the process of fixing
that appropriately. I fixed one thing but now the view_rhtml is not
working from admin page. It probably won't take much to fix once I
have some time.

After that if you want to move towards having a release I think we can do so.

Jeff

From djlewis at acm.org  Tue Oct 17 12:37:06 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 17 Oct 2006 09:37:06 -0700
Subject: [Masterview-devel] Testing this weekend went fine,
	except I found a problem with rails edge
In-Reply-To: <19cda190610170810lbb05bem79497fec4bcf8c27@mail.gmail.com>
Message-ID: <20061017163712.VVEG16798.fed1rmmtao09.cox.net@fed1rmimpo02.cox.net>

yes, i think we should stabilize and get this release out.  There's a bunch
of good new stuff there now and I think it's at a pretty good point w.r.t.
completeness - there's more we can do, of course, but it's a coherent
package of things now.

~ Deb 

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Tuesday, October 17, 2006 8:10 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Testing this weekend went fine, except I found a problem with rails
edge

Testing this weekend went fine, except I found a problem with rails edge.
They refactored some things so I am in the process of fixing that
appropriately. I fixed one thing but now the view_rhtml is not working from
admin page. It probably won't take much to fix once I have some time.

After that if you want to move towards having a release I think we can do
so.

Jeff



From djlewis at acm.org  Tue Oct 17 12:37:06 2006
From: djlewis at acm.org (Deb Lewis)
Date: Tue, 17 Oct 2006 09:37:06 -0700
Subject: [Masterview-devel] Code review: adding parens in generated
	output erb
In-Reply-To: <19cda190610170807y34884c55g9aa4751acd128a4@mail.gmail.com>
Message-ID: <20061017163712.JLNT18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>

>>> personally when I use the parens with conditionals 
>> I usually do it without the space (like it is)

reeaally???? wow, ok then. I never do and questioned whether it was even
syntactically legal when I saw that notation in the test cases.

as long as it compiles and executes correctly, leave it be.

~ Deb



From jeff.barczewski at gmail.com  Wed Oct 18 10:25:46 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 18 Oct 2006 09:25:46 -0500
Subject: [Masterview-devel] I have resolved the rails edge issue,
	so we can release whenever ready
Message-ID: <19cda190610180725i57a12b4dq20b0d1e228c19424@mail.gmail.com>

I have resolved the rails edge issue. So there are no outstanding
issues that I am aware of.

We can release whenever ready.

Jeff

From jeff.barczewski at gmail.com  Wed Oct 18 10:36:05 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 18 Oct 2006 09:36:05 -0500
Subject: [Masterview-devel] Integration tests of MasterView running in rails
Message-ID: <19cda190610180736j4495c1bcl883bee78dfaa0c90@mail.gmail.com>

Eventually I do want to add some integration tests to automatically
test out functionality when running in rails both with rails 1.1.6 and
with edge rails. So I am envisioning a test that would generate a
rails tree, swap out the database.yml, run masterview generators, fire
up rails, test pages, and admin pages. It would do this for both
latest release of rails and with rails edge.

I'm not sure the best way to do all of this but I was thinking that I
would simply write a rake task that calls system to execute these
commands and then runs some rails integration tests checking the
output for 0 failures, 0 errors.

This will allow us to programmatically kick off these tests and
eliminate the manual verification. We can easily run on both linux and
windows environments and any number of other factors (mongrel vs
webrick vs lighttpd, different versions of rails, etc).

This nothing to hold up the release with, but something I would like
to put in place sooner than later to make things easier on us and
improve our breadth of testing.

If you have any additional ideas on how I should go about doing this
let me know. Otherwise I am going to brush up on my ruby system calls
and how to get at the output as well as calling rails integration
tests. I guess I can use a migration to create a database and maybe a
fixture file to load it.

Thanks,

Jeff

From djlewis at acm.org  Thu Oct 19 11:18:53 2006
From: djlewis at acm.org (Deb Lewis)
Date: Thu, 19 Oct 2006 08:18:53 -0700
Subject: [Masterview-devel] I have resolved the rails edge issue,
	so we can release whenever ready
In-Reply-To: <19cda190610180725i57a12b4dq20b0d1e228c19424@mail.gmail.com>
Message-ID: <20061019151856.FLUZ12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>

yes, let's do that.  I think we should both take a final look at the docs
and the change notes/upgrade instructions for this release, since the
directive rework is pretty major.  What else can you think of that we should
do?

I'm tinkering with the implementation of my site to start taking advantage
of the new directive infrastructure, it finally lets me do some cool and
interesting stuff in reasonable ways!

I like your proposal for a better integration test suite, but that needn't
hold up doing this release I think.

~ Deb 

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Wednesday, October 18, 2006 7:26 AM
To: masterview-devel at rubyforge.org; djlewis at acm.org
Subject: I have resolved the rails edge issue, so we can release whenever
ready

I have resolved the rails edge issue. So there are no outstanding issues
that I am aware of.

We can release whenever ready.

Jeff



From jeff.barczewski at gmail.com  Thu Oct 19 14:21:28 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 19 Oct 2006 13:21:28 -0500
Subject: [Masterview-devel] I have resolved the rails edge issue,
	so we can release whenever ready
In-Reply-To: <20061019151856.FLUZ12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>
References: <19cda190610180725i57a12b4dq20b0d1e228c19424@mail.gmail.com>
	<20061019151856.FLUZ12581.fed1rmmtao02.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190610191121l6f760dfbl5fdaae8d61be3fce@mail.gmail.com>

On 10/19/06, Deb Lewis <djlewis at acm.org> wrote:
> yes, let's do that.  I think we should both take a final look at the docs
> and the change notes/upgrade instructions for this release, since the
> directive rework is pretty major.  What else can you think of that we should
> do?


Yeah, I agree, lets take a look at everything and make sure we have
some decent upgrade notes/instructions.


>
> I'm tinkering with the implementation of my site to start taking advantage
> of the new directive infrastructure, it finally lets me do some cool and
> interesting stuff in reasonable ways!

Wonderful!! I am dying to get back to my fancy grid directives. Hopefully soon.

>
> I like your proposal for a better integration test suite, but that needn't
> hold up doing this release I think.


I agree, just wanted to get idea out there and see if you had any
thoughts about how best to do it. I don't want to hold up the release
for that though.

Jeff

From jeff.barczewski at gmail.com  Wed Oct 25 11:06:21 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 25 Oct 2006 10:06:21 -0500
Subject: [Masterview-devel] rails template engine: php?
In-Reply-To: <6754b9660610241418h8e8b8b3h88bff5e23697ba09@mail.gmail.com>
References: <6754b9660610241418h8e8b8b3h88bff5e23697ba09@mail.gmail.com>
Message-ID: <19cda190610250806o6952610asc602000acd68fbfa@mail.gmail.com>

On 10/24/06, Don Park <don.park at gmail.com> wrote:
>
> hello.
> im stuck writing a PHP app when I want to write a rails app. The
> people writing the view code require PHP. So the thought struck me,
> could a rails template engine be written that evaluated html/php code
> instead of the .rhtml files that rails nomally uses.
>
> i figured you'd be the person to ask seeing as how masterview seems to
> be the leading alternative rails template engine.
>
> do you know if such a thing has been written or how difficult it would be
> to do?



Don,

I understand your dilemma, I have a similar situation at work where we have
legacy java code to integrate with. It kills me to have to continue to use
unproductive java code when a few lines of ruby would be much simpler, but
it is what it is.

Anyway, if I understand your question, then the answer is yes. To rephrase
your question I believe you are asking whether a template engine like
MasterView could generate PHP instead of rhtml. If that is the question then
the answer is yes.

When I was posed with a recent requirement, I concluded that one of the
quickest ways for me to implement the new code in java (and even be able to
regenerate for ruby) would be to use MasterView.

The WYSIWYG editable templates could be styled and laid out by a designer
(or a developer using something like NVU) and then easily generate the
marked up jsp or rhtml.

MasterView doesn't have a hard requirement to use rails, its has many
directives to make using with rails easy, but doesn't require it. So that
being said it would be fairly simple with the latest version of MasterView
to generate JSP, rhtml, or even PHP. Really it could be used to generate any
html like syntax.

The newest version which we are preparing to release (just working on
release docs) has simplified greatly the creation of directives, so that it
is very simple to create custom directives that would generate jsp markup,
php markup, etc.

If all goes well, I will be using MasterView for my own legacy java project,
so I will be first hand using it to generate for another language. It
wouldn't be hard to create what you need for PHP too.

So if you want to go down that path, I will do my best to support you. I'll
hopefully be doing a similar thing for Java as well.

And though I still think MasterView has some signifigant advantages over
some of the other projects, for completeness I would also mention that
Kwartz another template engine has the ability to generate for Java, Ruby,
and PHP currently. However it's not a WYSIWYG solution and falls short on
many other areas too, but I thought I would mention it anyway.
http://www.kuwata-lab.com/kwartz/

Anyway, thanks for taking the time to write. I think there would be some
nice merit in going down the path of generating PHP (or JSP) from MasterView
in addition to rhtml, it also allows us a way to potentially run in either
environment. For instance this legacy project I am referring to might have
to have that code run inside a Java web container along with the other code
or it might also be running standalone disconnected on laptops not
integrated with anything else (in which case it might be running on
something lightweight like rails).

I think MasterView would provide an elegant way to handle a good portion of
the work to do this. It certainly would be straight forward to generate the
view portion. I'll know more as we get into it, but from the surface that
would seem pretty straight forward.

Blessings,

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

From jeff.barczewski at gmail.com  Thu Oct 26 20:13:40 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Thu, 26 Oct 2006 19:13:40 -0500
Subject: [Masterview-devel] Another supporter of MasterView
Message-ID: <19cda190610261713x79f175b3i862e4d43321756ad@mail.gmail.com>

---------- Forwarded message ----------
From: Andrew <andrewzielinski at bigpond.com>
Date: Oct 26, 2006 7:08 PM
Subject: MW Templates
To: jeff.barczewski at gmail.com

I haven't had a play around with it yet, but very much intend to. Great
work. I have never been a fan of how rails has implemented its templates and
have always like the xml based approach. As far as i'm concerned this is a
godsend.





Cheers,



Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061026/93473ab5/attachment-0001.html 

From djlewis at acm.org  Fri Oct 27 12:34:01 2006
From: djlewis at acm.org (Deb Lewis)
Date: Fri, 27 Oct 2006 09:34:01 -0700
Subject: [Masterview-devel] Well enough with my goofing around,
	I am going to go through and shore up the release notes for a
	release this weekend
In-Reply-To: <19cda190610270717j3f0594d0ub4020ad52a7c3cb4@mail.gmail.com>
Message-ID: <20061027163400.KXZR13992.fed1rmmtao11.cox.net@fed1rmimpo01.cox.net>

> > I was thinking about renaming the directive_base_old.rb to
deprecated_directive_base.rb,  
>> this seems to be how they do it on the rails edge. Seem ok to you? 
>> It is clear about its status and then easy to find when we want to remove
later. 
 
Yes.  I'd almost go further and put it completely on the side (e.g. separate
deprecated subdir or something like that), with upgrade instructions on what
to require in legacy code.  This is fairly aggressive and not necesssarily a
technique I'd advocate at a more mature level of the life cycle, but it's
already that case that an existing impl would need to be touched to change
the superclass name, so asking them to do an explicit compat require isn't
that much more of a burden.
 
And  given the small size of the impacted clients and the huge improvement
of the new facility, I think it's ok to be fairly agressive about accepting
some breakage right now.
 
We should flag this very clearly in the release information, noting that it
deviates from desirable policy of not causing breakage, and ask for pushback
from users think we've gone too far at pushing burden onto them, but I think
this will be acceptable.
 
~ Deb
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061027/18cece46/attachment.html 

From jeff.barczewski at gmail.com  Sat Oct 28 11:26:45 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 28 Oct 2006 10:26:45 -0500
Subject: [Masterview-devel] Kwartz has recently added some rails support
	that looks similar to some of our rails form helper directives
Message-ID: <19cda190610280826p4eda692cw842a836acc8aa4fe@mail.gmail.com>

It looks like the kwartz project has started adding some rails support
in the past several months that works similar to us in the rails form
helper directive areas.

We can keep an eye on what they are doing and potentially get some
ideas and more inspiration.

http://www.kuwata-lab.com/kwartz/kwartz3ruby-users-guide.03.html#rails

But all in all only a small overlap, otherwise the projects' feature
sets and usage are quite different.

Jeff

From jeff.barczewski at gmail.com  Sat Oct 28 11:13:38 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 28 Oct 2006 10:13:38 -0500
Subject: [Masterview-devel] MasterView questions
In-Reply-To: <3c4c8fa60610280457uf896f73jdd15a86402565718@mail.gmail.com>
References: <3c4c8fa60610192025pcc64c09i1fa9c9fef0f8bdb0@mail.gmail.com>
	<19cda190610200946i236d58eao5a2113c32493f6d0@mail.gmail.com>
	<3c4c8fa60610201012w763b49e2jf01284130c4e8cd7@mail.gmail.com>
	<19cda190610201225k59f047c8nf72bee2edfe99660@mail.gmail.com>
	<3c4c8fa60610201945waf77656w4de75d9e8108c59e@mail.gmail.com>
	<19cda190610231131s307010c1ic06b25a37493847c@mail.gmail.com>
	<3c4c8fa60610280457uf896f73jdd15a86402565718@mail.gmail.com>
Message-ID: <19cda190610280813i3b4fd739w62de4f92cf16377b@mail.gmail.com>

On 10/28/06, Hendy Irawan <gauldong at gmail.com> wrote:
>
> Hi, I've tried MasterView. Works great. Some issues (more on these
> later, one of them is that I can't figure out how to put <!DOCTYPE on
> top of my output htmls)).

Hmmm, maybe its a bug, I will look into it. Might be an oversite on my part.

> Liquid works fine (very nice). Haven't tried with Rails Engine and
> theme_support plugin, but expects failure.
>
> Seems that MasterView is quite a "radical" change in development style
> than plain eRb+rails... What I worry so much is not MasterView itself,
> but whether it works fine with other [plugins|Rails Engines] that I'm
> going to use/develop...

It is a bit of a conceptual shift, but we try to use rails like syntax
where possible to soften the learning curve. The combined/rolled up
view templates is one of the brand new things to get used to.

As far as working with other things that you will use/develop, one
goal of mine is that MasterView will play nice with other plugins,
templates, etc. So I am trying my best to work within the Rails
framework properly as to be compatible. Currently with rails
generating rhtml it should be very compatible with everything else as
far as coexisting. One can even turn all the magic off and just have
MasterView generate rhtml to the file system and one can even deploy
that rhtml on a production server without MasterView installed, once
the erb is generated it doesn't rely on anything.

However the magic makes it more fun to work with especially for
development (autogenerating of rhtml on template change...), so I am
trying to make that work seamlessly in the rails framework. The other
question that occurs to me in your question is to use liquid or other
template technology right inside MasterView templates. I haven't done
anything with that yet,  so I will have to look into that to see.

So I guess my thought is that at the moment, I am not aware of any
things that MasterView is not compatible with, if they are used side
by side (MasterView can generate rhtml, including layouts and partials
and you can use those layouts and partials along with any other rails
technology/templates, but I just haven't tried mixing things in the
templates themselves yet).

I will take a TODO item to look at the doctype issue and to see if and
how we could mix things as well. One obvious step would be to have
directives that generate liquid that way you could have WYSIWYG
editing of the full page. I'll have to look at all that to see what
would work best. For now though you should be safe in using things
separately (not in the same template).

>
> Conclusions is congratulations for making such a very good product. I
> was also surprised that you had the time to write all that docs &
> guides. You're a very diligent person. :-) Can't believe what your
> work must have been had someone gave you $1 million funding ;-)

Thank you for your time to write and kind words. Actually, I have to
give most of the credit for the document to my wonderful partner, Deb
Lewis, she has worked tirelessly on the documentation and has been
invaluable in helping to extend and refactor MasterView into what it
is now. It would not be half of what it is without all of her help. (I
am copying her on the response so she'll get to see your comments).

So if you run into any issues with compatibility let us know, I expect
side by side use to work fine. I will keep you posted as we do any
more advanced integration (like liquid directives) between
technologies.

Many blessings to you and your family,

Jeff

From djlewis at acm.org  Sat Oct 28 13:24:39 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 28 Oct 2006 10:24:39 -0700
Subject: [Masterview-devel] Kwartz has recently added some rails support
	that looks similar to some of our rails form helper directives
In-Reply-To: <19cda190610280826p4eda692cw842a836acc8aa4fe@mail.gmail.com>
Message-ID: <20061028172437.RBIP28934.fed1rmmtao07.cox.net@fed1rmimpo02.cox.net>

thanks, I'll put it on my (ever-growing!) list of things to explore.

~ Deb

-----Original Message-----
From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Saturday, October 28, 2006 8:27 AM
To: djlewis at acm.org; masterview-devel at rubyforge.org
Subject: Kwartz has recently added some rails support that looks similar to
some of our rails form helper directives

It looks like the kwartz project has started adding some rails support in
the past several months that works similar to us in the rails form helper
directive areas.

We can keep an eye on what they are doing and potentially get some ideas and
more inspiration.

http://www.kuwata-lab.com/kwartz/kwartz3ruby-users-guide.03.html#rails

But all in all only a small overlap, otherwise the projects' feature sets
and usage are quite different.

Jeff



From djlewis at acm.org  Sat Oct 28 15:40:39 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 28 Oct 2006 12:40:39 -0700
Subject: [Masterview-devel] Some code org issues
Message-ID: <20061028194037.JQQ18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>

Jeff - I went in this morning to take a look at knocking off one more to-do
item before we release and it's turned up a couple interesting issues.

Recall that we'd kind of agreed that introducing a module namespace
structure onto the MIO classes would probably be a good idea.  And indeed
when I go in and try out introducing a MasterView::IO layer in io.rb I think
it's bit better - the rdoc is clearer, shifts a lot of things out of the top
level of the MasterView namespace which are primarily mechanism classes.

Discoveries:

- I think we don't need InvalidArgumentError that's declared in io.rb - just
use ArgumentError from the standard library [not sure this is used in any
case]

- it turns out we've got two declararations of InvalidPathError - oops!! You
used in io.rb and then I recently invented an equivalent guy as part of
directive_load_path.  Need to reconcile this, I'll look at it further.

Related: I'd like to shift masterview/pathname_extensions.rb into
masterview/core_ext/pathname.rb - that dir structure follows the pattern I
see in rails and I think is a better way to organize the files, makes it
very clear where we've got stuff that affects existing platform elements vs.
what's really our own, new stuff.

[and maybe at some point tease the methods that we patch into rails classes
into an explicit masterview/rails_ext directory, although I don't mind
deferring that until later; pathname was easy to spot and shift because you
already set it up cleanly in the first place]

But... this'll take at least few hours to go over, retest, etc.  Should we
do this now?  I would rather like to get our namespace juggling settled in
this release if possible, given that we did some similar changes elsewhere
(parser), so that we don't have continuing churn in the namespace structure.

~ Deb



From jeff.barczewski at gmail.com  Sat Oct 28 17:59:03 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sat, 28 Oct 2006 16:59:03 -0500
Subject: [Masterview-devel] Some code org issues
In-Reply-To: <20061028194037.JQQ18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>
References: <20061028194037.JQQ18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610281459n75b551e6qd084f3ec3698262b@mail.gmail.com>

On 10/28/06, Deb Lewis <djlewis at acm.org> wrote:
>
> Jeff - I went in this morning to take a look at knocking off one more
> to-do
> item before we release and it's turned up a couple interesting issues.
>
> Recall that we'd kind of agreed that introducing a module namespace
> structure onto the MIO classes would probably be a good idea.  And indeed
> when I go in and try out introducing a MasterView::IO layer in io.rb I
> think
> it's bit better - the rdoc is clearer, shifts a lot of things out of the
> top
> level of the MasterView namespace which are primarily mechanism classes.
>
> Discoveries:
>
> - I think we don't need InvalidArgumentError that's declared in io.rb -
> just
> use ArgumentError from the standard library [not sure this is used in any
> case]



ok


- it turns out we've got two declararations of InvalidPathError - oops!! You
> used in io.rb and then I recently invented an equivalent guy as part of
> directive_load_path.  Need to reconcile this, I'll look at it further.



agreed. let me know if you need my help in resolving.


Related: I'd like to shift masterview/pathname_extensions.rb into
> masterview/core_ext/pathname.rb - that dir structure follows the pattern I
> see in rails and I think is a better way to organize the files, makes it
> very clear where we've got stuff that affects existing platform elements
> vs.
> what's really our own, new stuff.



yes, that sounds like a good reorg

[and maybe at some point tease the methods that we patch into rails classes
> into an explicit masterview/rails_ext directory, although I don't mind
> deferring that until later; pathname was easy to spot and shift because
> you
> already set it up cleanly in the first place]



I agree it would be good to do now rather than waiting since this is a big
release anyway


But... this'll take at least few hours to go over, retest, etc.  Should we
> do this now?  I would rather like to get our namespace juggling settled in
> this release if possible, given that we did some similar changes elsewhere
> (parser), so that we don't have continuing churn in the namespace
> structure.



I am fine with us taking the time to do it now. I am just about finished
with the missing xml declaration and doctype. Should be commiting within the
next half hour, though I don't know that it will conflict with anything you
are mentioning anyway.

I will be working more on the release notes after that commit.

I think all these changes you mentioned are good and should go into this
release so we'll just hold off until it is ready. Depending on your
availability for the changes you mentioned, its possible that we can still
get it in this weekend anyway, but not a huge deal if it needs to wait. As
long as we are moving forwards we'll get there :-)

Thanks. Keep me posted of your progress and I'll do the same.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061028/980daa30/attachment-0001.html 

From djlewis at acm.org  Sat Oct 28 20:14:13 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sat, 28 Oct 2006 17:14:13 -0700
Subject: [Masterview-devel] Some code org issues
In-Reply-To: <19cda190610281459n75b551e6qd084f3ec3698262b@mail.gmail.com>
Message-ID: <20061029001412.MVHP12909.fed1rmmtao05.cox.net@fed1rmimpo01.cox.net>

Jeff - right then, let's proceed.  I started on the namespace changes this
morning and then backed off to see if you agreed it was worth doing now;
I'll finish it in the morning after synching to pick up your changes.
 
RE: InvalidPathError - I think we should keep InvalidPathError exception
declared at the top level (MasterView::InvalidPathError), since this is
properly exposed to clients.  I'll keep IO using that and tweak the
directive-path variation accordingly (might subclass to carry extra parm
value that current impl provides with the actual path entry, but that's
pretty minor either way I think).
 
RE: just about finished with the missing xml declaration and doctype - good,
that's important to handle
 
~ Deb

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

From djlewis at acm.org  Sun Oct 29 11:15:28 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 29 Oct 2006 08:15:28 -0800
Subject: [Masterview-devel] deprecated/deprecated_directive_base.rb
Message-ID: <20061029161532.YCEX18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>

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

` Deb



From djlewis at acm.org  Sun Oct 29 11:37:24 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 29 Oct 2006 08:37:24 -0800
Subject: [Masterview-devel] Well I hit a problem with doctype and am
	debugging
In-Reply-To: <19cda190610281749u4798c0cp53b535e0ef4c39f@mail.gmail.com>
Message-ID: <20061029163728.RUD28934.fed1rmmtao07.cox.net@fed1rmimpo02.cox.net>

Maybe a combo strategy - I don't like blindly patching libraries we're
using, but it would also be good to make this as simple as possible.
 
Maybe a config switch with default computed based on our understanding of
broken/fixed versions of rexml.
 
~ Deb

  _____  

From: Jeff Barczewski [mailto:jeff.barczewski at gmail.com] 
Sent: Saturday, October 28, 2006 5:49 PM
To: djlewis at acm.org
Subject: Re: Well I hit a problem with doctype and am debugging


It is a problem in the sax2parser of rexml. I found that they aren't
handling doctype declarations properly. They have some code in there but it
is broken. 

And of course their test cases are missing the appropriate test or they
would have caught it. 

I will work up a patch and test case for them and send it in. 

Not sure what to do about our code since most people will have the broken
code until it gets fixed in ruby mainlib or they manually upgrade which most
won't. I guess we'll have to include the patched rexml file in our distro so
that people can get at doctypes properly. I guess that is the nice thing
about Ruby that we can hotfix things if we have to. Should we wrap a
configuration switch around this or simply check the rexml version assuming
that once I get him the fix it will be in his next release? (and only
require it if version is not high enough) 

Boy something so simple turns into something bigger. Oh well at least I know
what is wrong now and how to fix.

yeah, the Cardinals suprised us all this time. Detroit wasn't playing its
best though, without their errors we wouldn't have won.  It was pretty
exciting to watch. 

Later,

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

From djlewis at acm.org  Sun Oct 29 15:59:51 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 29 Oct 2006 12:59:51 -0800
Subject: [Masterview-devel] Release readiness status
Message-ID: <20061029205956.KPVW6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>

Believe I've done the bulk of the namespace fiddling and code reorganizing
at this point; there's a few misc. classes still in the MasterView namespace
root that might be better if shifted into one of the nested namespaces
related to parsing or directives that time permitting I might still move,
but nothing earthshaking.

Also moved some code in core_ext and rails_ext dirs; there's probably a bit
more rails stuff in extras that we could shift around, these were the
obvious ones that were easy.

I've run the unit tests and my app, rechecked change parsing and the admin
page...  Do run through whatever you've got as well.

I'd intended to use MasterView::IO as our namespace on the io.rb classes,
but got tripped up with name resolution conflict on the base ruby IO class,
so changed to MasterView::MIO.  Not as nice, but wasn't sure we wante to
deal with the IO name overlap.  Let me know what you think, it's not hard to
put in an alias or dis-amibiguate our references if you'd prefer
MasterView::IO, I think it just showed up in a few places.

~ Deb



From djlewis at acm.org  Sun Oct 29 16:43:11 2006
From: djlewis at acm.org (Deb Lewis)
Date: Sun, 29 Oct 2006 13:43:11 -0800
Subject: [Masterview-devel] Release readiness status
In-Reply-To: <20061029205956.KPVW6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>
Message-ID: <20061029214316.PFNF2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>

ah - one more thing we should look at fixing if possible: admin pages don't
render properly in IE.

~ Deb



From jeff.barczewski at gmail.com  Sun Oct 29 17:44:35 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Sun, 29 Oct 2006 16:44:35 -0600
Subject: [Masterview-devel] Commited xmldecl and doctype fix - added custom
	patched REXML classes
Message-ID: <19cda190610291444g54608108x5bc7de47eb42fc1b@mail.gmail.com>

I have committed the xmldecl (version and encoding) and doctype fix so that
MasterView will output those if they are supplied in the template.

In fixing the doctype issue, I discovered that the sax2 parser in REXML was
not triggering the doctype event. Checking the code confirmed this as well
as the missing test case.

I pulled the latest REXML code version 3.1.5, created a couple test cases
and a fix for the doctype issue. I submitted them to the REXML trac site
with the patch for all of the above.

Since REXML is normally shipped with Ruby, it is likely that our users will
have a broken version for quite some time.

So using the patched code I created our own custom sax2 parser called
Sax2ParserWithDoctypeFix and baseparser BaseParserWithDoctypeFix so that
MasterView can use the patched code immediately. Once REXML applies the
patch I sent them and we can determine a release number for it, then we can
conditionally use these classes or the core REXML classes (if  user has the
lastest version). For right now I always use the patched classes until we
can determine a version to check.

These two patched classes live in
masterview/lib/rexml/parsers

Since we have created our own classes we will not interfere with anyone
using the core classes.

The REXML bug fix ticket is 92
http://www.germane-software.com/projects/rexml/ticket/92

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

From jeff.barczewski at gmail.com  Mon Oct 30 06:04:29 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 30 Oct 2006 05:04:29 -0600
Subject: [Masterview-devel] Release readiness status
In-Reply-To: <20061029214316.PFNF2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>
References: <20061029205956.KPVW6077.fed1rmmtao01.cox.net@fed1rmimpo02.cox.net>
	<20061029214316.PFNF2704.fed1rmmtao03.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610300304h2666d96aqdc3db5650a2d3310@mail.gmail.com>

MIO is fine with me, don't want things to get confused.

I will take a look at admin pages too.

Thanks for all your hard work.

I finally got the REXML fix in, so now I'll go back to looking at the docs
and release notes so we can get this out.

My dad is having back surgery this morning so it will be after that is done.

Thanks,

Jeff

On 10/29/06, Deb Lewis <djlewis at acm.org> wrote:
>
> ah - one more thing we should look at fixing if possible: admin pages
> don't
> render properly in IE.
>
> ~ Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061030/f7950abc/attachment.html 

From jeff.barczewski at gmail.com  Mon Oct 30 06:05:11 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 30 Oct 2006 05:05:11 -0600
Subject: [Masterview-devel] deprecated/deprecated_directive_base.rb
In-Reply-To: <20061029161532.YCEX18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>
References: <20061029161532.YCEX18985.fed1rmmtao10.cox.net@fed1rmimpo02.cox.net>
Message-ID: <19cda190610300305l10e0411ek12c9014491614de1@mail.gmail.com>

ok

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)
>
> ` Deb
>
>
> _______________________________________________
> Masterview-devel mailing list
> Masterview-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/masterview-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061030/80eb764d/attachment-0001.html 

From djlewis at acm.org  Mon Oct 30 11:12:51 2006
From: djlewis at acm.org (Deb Lewis)
Date: Mon, 30 Oct 2006 08:12:51 -0800
Subject: [Masterview-devel] Release readiness status
In-Reply-To: <19cda190610300304h2666d96aqdc3db5650a2d3310@mail.gmail.com>
Message-ID: <20061030161256.MYML2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>

Jeff - your REXML solution looks good.
 
I'm going to tinker a bit more this morning looking for loose ends in how
things are organized in namespace structures and look over how things appear
in docs and rdoc for a bit of final polishing.
 
Hope your dad's back surgery goes well, messing with backs and necks is not
something to be taken lightly.
 
~ Deb
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061030/acb576ea/attachment.html 

From jeff.barczewski at gmail.com  Mon Oct 30 11:32:36 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 30 Oct 2006 10:32:36 -0600
Subject: [Masterview-devel] Release readiness status
In-Reply-To: <20061030161256.MYML2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
References: <19cda190610300304h2666d96aqdc3db5650a2d3310@mail.gmail.com>
	<20061030161256.MYML2704.fed1rmmtao03.cox.net@fed1rmimpo01.cox.net>
Message-ID: <19cda190610300832w19e64ae6m9cd1b503b6533e19@mail.gmail.com>

On 10/30/06, Deb Lewis <djlewis at acm.org> wrote:
>
>  Jeff - your REXML solution looks good.
>


Thanks. I decided that this would be the safer approach all things
considered.


I'm going to tinker a bit more this morning looking for loose ends in how
> things are organized in namespace structures and look over how things appear
> in docs and rdoc for a bit of final polishing.
>


Sounds good.


Hope your dad's back surgery goes well, messing with backs and necks is not
> something to be taken lightly.
>


Thanks. We got in there for the surgery and the surgeon called in sick, so
we'll be rescheduling.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/masterview-devel/attachments/20061030/2a3f2696/attachment.html