Masterview devel - Oct 2006 - mv:text_input id is overriding the id of the input field

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

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

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

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! :)

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