From krkoceja at wi.rr.com  Sun Oct  1 16:53:53 2006
From: krkoceja at wi.rr.com (Ken Koceja)
Date: Sun, 01 Oct 2006 15:53:53 -0500
Subject: [Masterview-users] MasterView Admin Controller problem and more
Message-ID: <45202AE1.7010602@wi.rr.com>

I can't get to the MasterView Admin Controller. I have enabled it by 
setting the |"enable_admin_pages"| configuration setting to true in the 
"C:\rails\config\masterview\settings.rb" file. When I go to URL 
"http://localhost:3000/masterview", I get the following error: Routing 
Error / Recognition failed for "/masterview"

Also, running the MasterView generator for my Admin controller created 
all the expected html files alongside the existing rhtml files. It 
appears that Rails is only using the rhtml files as modifications to the 
html files are not reflected when the app is run. Did I generate the 
files incorrectly or am I misunderstanding how MasterView works?

Any help would be appreciated.

Thanks,
Ken


From jeff.barczewski at gmail.com  Mon Oct  2 06:46:41 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Mon, 2 Oct 2006 05:46:41 -0500
Subject: [Masterview-users] MasterView Admin Controller problem and more
In-Reply-To: <45202AE1.7010602@wi.rr.com>
References: <45202AE1.7010602@wi.rr.com>
Message-ID: <19cda190610020346m448f1689y4bab1938c872a183@mail.gmail.com>

On 10/1/06, Ken Koceja <krkoceja at wi.rr.com> wrote:
> I can't get to the MasterView Admin Controller. I have enabled it by
> setting the |"enable_admin_pages"| configuration setting to true in the
> "C:\rails\config\masterview\settings.rb" file. When I go to URL
> "http://localhost:3000/masterview", I get the following error: Routing
> Error / Recognition failed for "/masterview"
>
> Also, running the MasterView generator for my Admin controller created
> all the expected html files alongside the existing rhtml files. It
> appears that Rails is only using the rhtml files as modifications to the
> html files are not reflected when the app is run. Did I generate the
> files incorrectly or am I misunderstanding how MasterView works?
>

Ken,

It sounds to me that somehow the admin controller is not getting
loaded at startup as well as the automatic reparsing of the html
feature and the loading of rhtml directly from masterview rather than
writing to file system feature.

Can you reply with a copy of the output that is given when you start
your server? Hopefully the output will shed some light on what is
happening. Here's what I see when I start a copy on windows.

C:\rails\demoa>ruby script\server
=> Booting WEBrick...
 INFO MasterView: Initializing MasterView configuration (2006-10-02 05:22)
 INFO MasterView: Program name = script/server
 INFO MasterView: MasterView Admin pages enabled
 INFO MasterView: Adding hook to allow MasterView to check for templates that ha
ve changed when processing a request
 INFO MasterView: Adding hooks to enable Rails to read erb directly
from MasterView
 INFO MasterView: MasterView plugin initialized - Version 0.2.5
=> Rails application started on http://0.0.0.0:3000
=> Ctrl-C to shutdown server; call with --help for options
[2006-10-02 05:22:16] INFO  WEBrick 1.3.1
[2006-10-02 05:22:16] INFO  ruby 1.8.4 (2005-12-24) [i386-mswin32]
[2006-10-02 05:22:16] INFO  WEBrick::HTTPServer#start: pid=3688 port=3000


If you could also mention the steps you went through to get things up
and running, maybe that will help. For instance indicate whether you
installed via gem or plugin and what generate commands you used.
Something like

gem install masterview_gem_pack
cd c:\rails
rails demo
cd demo
ruby script\generate masterview_plugin
ruby script\generate masterview Product Store
ruby script\server

Finally if you could give the output of these commands it might also help

gem list rails
gem list masterview

Are you running rails 1.1.6, edge rails, or an older version?

Thanks,

Jeff

From ed.howland at gmail.com  Tue Oct  3 13:22:03 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Tue, 3 Oct 2006 12:22:03 -0500
Subject: [Masterview-users] mv:text_input id is overriding the id of the
	input field
Message-ID: <3df642dd0610031022o54c06033x1312c66b9548e39a@mail.gmail.com>

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.

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

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-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-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 10:12:37 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 4 Oct 2006 09:12:37 -0500
Subject: [Masterview-users] MasterView Admin Controller problem and more
In-Reply-To: <45231401.5080703@wi.rr.com>
References: <45202AE1.7010602@wi.rr.com>
	<19cda190610020346m448f1689y4bab1938c872a183@mail.gmail.com>
	<45231401.5080703@wi.rr.com>
Message-ID: <19cda190610040712t57f804b9vfd16f667fe477c20@mail.gmail.com>

On 10/3/06, Ken Koceja <krkoceja at wi.rr.com> wrote:
> I installed MasterView using gem and I'm using Rails 1.1.6.
>
> If I recall correctly, these were my steps. I created a Rails skeleton
> application, created my DB and model, and then used the rails scaffold
> generator for the model and admin controller. Finally, I executed the
> MasterView generator for the model and controller. I believe I included
> everything you asked for below. I'm new to both Rails and MasterView so
> please excuse my ignorance.
>
> =====================================================
> C:\rails\work\seniorcolony>ruby script\server
> => Booting WEBrick...
> => Rails application started on http://0.0.0.0:3000
> => Ctrl-C to shutdown server; call with --help for options
> [2006-10-03 20:14:17] INFO  WEBrick 1.3.1
> [2006-10-03 20:14:17] INFO  ruby 1.8.2 (2004-12-25) [i386-mswin32]
> [2006-10-03 20:14:18] INFO  WEBrick::HTTPServer#start: pid=2924 port=3000
> =====================================================

No problem Ken. My goal is to make this simple to use for anyone
(rookies and veterans alike), so once we can figure out what is not
working for you, we can update the documentation (or install)
appropriately.

Did you perhaps not run the generate plugin step? (Try doing this)

cd yourwebapp
ruby script\generate masterview_plugin

You need to do this once for each new web application because it
copies a minimal amount of things into the web app so that it gets
loaded as a plugin. This is in addition to any masterview scaffolding
you do (ruby script\generate masterview Product Store).

It will copy some things into vendor/plugins/masterview

If you don't remember it's fine to run it again, it won't hurt anything.

Let me know if after you do this if you have more output when you
start your server and hopefully things start working :-) The only
other thing we might and should probably do is to

Thanks,

Jeff

From ed.howland at gmail.com  Wed Oct  4 12:48:06 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Wed, 4 Oct 2006 11:48:06 -0500
Subject: [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: <3df642dd0610040948r1df52f8ar2b8fae38d304cf85@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.
>

Deb, I agree this is the most sensible approach.


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

I agree with this. And a simpler strategy might be just to fill out
more mv: directives to corresponding helper tags. Because then people
could use text_helper_tag which just takes a name as the minimum and
name and id attributes have the same values. But if you give it the id
attr it overrides it in the rendered tag.

These _tag helpers are used when you don't have a model/db table
corresponding to the form field. The mv  directive can just be an
empty one like mv:image that gets the name from the original element,
but if any are supplied in the directive arguments, they override any
in the surrounding element. Now that you have a directives DSL, that
should be a P.O.C, right? :)

That way it is all nice and consistent and DW-like WYSIWYG editors
won't force us users to play guessing games as to directive arguments,
surrounding element attributes that are the default for the directive,
or optional configuration settings.*

My guess is Rails programmers are the ones who will put in the mv:
directives** and they are probably expecting the same behaviour as the
Rails helpers.


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

* Convention over configuration
** although here, my DW guy knows all about mv:block, mv:content,
mv:replace as well as the mv: form directives. I might not ever have
to touch another .html file forever.  (If only! :)

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-users] [Masterview-devel] 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 ed.howland at gmail.com  Mon Oct  9 19:37:21 2006
From: ed.howland at gmail.com (Ed Howland)
Date: Mon, 9 Oct 2006 18:37:21 -0500
Subject: [Masterview-users] Safer code in rendered output
Message-ID: <3df642dd0610091637h2c8bdc7dvb218d2bcd18dab26@mail.gmail.com>

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
-- 
Ed Howland
http://greenprogrammer.blogspot.com

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-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 14:30:02 2006
From: jeff.barczewski at gmail.com (Jeff Barczewski)
Date: Wed, 11 Oct 2006 13:30:02 -0500
Subject: [Masterview-users] It appears that we need to enclose our method
	calls in parens so ERB can parse complex methods - Re: 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 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-users] It appears that we need to enclose our
	method calls in parens so ERB can parse complex methods - Re:
	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-users] It appears that we need to enclose our
	method calls in parens so ERB can parse complex methods - Re:
	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.