Announcement

#2 · 03-30-05, 08:11 AM

colons in form field names

Hi Adam,

You have to escape restricted characters if you want to use them in variable
names. I did not test with colons, but suppose it should work too.

Ivo
http://mivo.truxoft.com

-----Original Message-----
From: Adam Denning
Sent: Wednesday, March 30, 2005 5:54 PM
To: Miva Users
Subject: [meu] colons in form field names

Anyone know if colons are allowed in form field names? I'm working with
an app that uses them for setting global structures, and it creates
javascript problems (which can be worked around, to some extent). From
what I've read, it sounds like they shouldn't be used, but parsers must
allow them to work.

From <A HREF ="http://www.w3.org/TR/REC-xml/">http://www.w3.org/TR/REC-xml/</A>

"The Namespaces in XML Recommendation [XML Names] assigns a meaning to
names containing colon characters. Therefore, authors should not use the
colon in XML names except for namespace purposes, but XML processors
must accept the colon as a name character."

Regards,

Adam

#3 · 03-30-05, 08:17 AM

colons in form field names

On Wed, 30 Mar 2005 07:54:05 -0800, Adam Denning <[email protected]> wrote:
> Anyone know if colons are allowed in form field names? I'm working with
> an app that uses them for setting global structures, and it creates
> javascript problems (which can be worked around, to some extent). From
> what I've read, it sounds like they shouldn't be used, but parsers must
> allow them to work.
>
> From <A HREF ="http://www.w3.org/TR/REC-xml/">http://www.w3.org/TR/REC-xml/</A>
>
> "The Namespaces in XML Recommendation [XML Names] assigns a meaning to
> names containing colon characters. Therefore, authors should not use the
> colon in XML names except for namespace purposes, but XML processors
> must accept the colon as a name character."
>

I've used them in forms with no trouble, but I wasn't using any JS on
the forms. Helps cut down on the global clutter, as you can have
form:fname, form:lname, form:address, etc. and only have to deal with
a single global.

--
Bill Guindon (aka aGorilla)

#4 · 03-30-05, 08:29 AM

colons in form field names

Ivo,

Greetings from the other side of the pond. So it is a restricted
character? I guess what I'm asking is, *should* one make a habit of
using colons in form field names. Are there potential problems, even
with escaping in client scripting?

Here's what I've found using a javascript debugger, given

<form method="post" name="test">
<input type="text" name="foo:foo">
</form>

test 1)

document.test.foo:foo.value='bar';

Result: Does NOT work. "Error: invalid label"

test 2)

document.test['foo:foo'].value='bar';

Result: Works, but still produces an error in the console. "Error:
document.test has no properties"

test 3)

document.test['foo:foo'].value='bar';

Result: Works, no errors.

Maybe that answers my question. Having to always escape colons in
client-side scripting seems enough of a reason to not use them IMO.

Adam

Ivo Truxa wrote:
> Hi Adam,
>
> You have to escape restricted characters if you want to use them in variable
> names. I did not test with colons, but suppose it should work too.
>
> Ivo
> http://mivo.truxoft.com
>
>
> -----Original Message-----
> From: Adam Denning
> Sent: Wednesday, March 30, 2005 5:54 PM
> To: Miva Users
> Subject: [meu] colons in form field names
>
> Anyone know if colons are allowed in form field names? I'm working with
> an app that uses them for setting global structures, and it creates
> javascript problems (which can be worked around, to some extent). From
> what I've read, it sounds like they shouldn't be used, but parsers must
> allow them to work.
>
> From <A HREF ="http://www.w3.org/TR/REC-xml/">http://www.w3.org/TR/REC-xml/</A>
>
> "The Namespaces in XML Recommendation [XML Names] assigns a meaning to
> names containing colon characters. Therefore, authors should not use the
> colon in XML names except for namespace purposes, but XML processors
> must accept the colon as a name character."
>
> Regards,
>
> Adam

#5 · 03-30-05, 08:46 AM

colons in form field names

Bill,

Nice to see the guerrilla in these parts again.

I've always used underscores. Not as slick as structures, but using a
common prefix for all globals in an app avoids variable collisions.
Recently I've been working with an app that uses colons all over the
place for form field names. I thought this was a cool idea initially,
and started using them in a new project. Then I found the scripting
issues. I think I'll go back to underscores. As neat as they are,
everything doesn't have to be a structure...

Adam

Bill Guindon wrote:
> On Wed, 30 Mar 2005 07:54:05 -0800, Adam Denning <[email protected]> wrote:
>
>>Anyone know if colons are allowed in form field names? I'm working with
>>an app that uses them for setting global structures, and it creates
>>javascript problems (which can be worked around, to some extent). From
>>what I've read, it sounds like they shouldn't be used, but parsers must
>>allow them to work.
>>
>> From <A HREF ="http://www.w3.org/TR/REC-xml/">http://www.w3.org/TR/REC-xml/</A>
>>
>>"The Namespaces in XML Recommendation [XML Names] assigns a meaning to
>>names containing colon characters. Therefore, authors should not use the
>>colon in XML names except for namespace purposes, but XML processors
>>must accept the colon as a name character."
>>
>
>
> I've used them in forms with no trouble, but I wasn't using any JS on
> the forms. Helps cut down on the global clutter, as you can have
> form:fname, form:lname, form:address, etc. and only have to deal with
> a single global.

#6 · 03-30-05, 09:05 AM

colons in form field names

On Wed, 30 Mar 2005 08:46:47 -0800, Adam Denning <[email protected]> wrote:
> Bill,
>
> Nice to see the guerrilla in these parts again.
>
> I've always used underscores. Not as slick as structures, but using a
> common prefix for all globals in an app avoids variable collisions.
> Recently I've been working with an app that uses colons all over the
> place for form field names. I thought this was a cool idea initially,
> and started using them in a new project. Then I found the scripting
> issues. I think I'll go back to underscores. As neat as they are,
> everything doesn't have to be a structure...

It'd take a lot of deprogramming for me to change my thinking on
structures. I'm quite hooked on them. I doubt the JS issue would be
large enough to force me stop now, especially since you've already
found a solution :)

I used the underscore approach for years too, but I've been quite
pleased by the things I can do with structures that I can't do with a
collection of single variables.

The ability to replace lumps like this:
<MvFUNCTION NAME = "Customer_Insert" PARAMETERS =
"login, pw_email, password, ship_fname, ship_lname, ship_email,
ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
bill_state, bill_zip, bill_cntry"
STANDARDOUTPUTLEVEL = "">

with this:
<MvFUNCTION NAME = "Customer_Insert" PARAMETERS="cust" STANDARDOUTPUTLEVEL="">

was enough to convince me.

Once you start coding like that, you fall in love with the fact that
you can change your structure as often as you like, without having to
remember to change the parameters list for every function that needs
the full list.

--
Bill Guindon (aka aGorilla)

#7 · 03-30-05, 09:12 AM

colons in form field names

Bill Guindon wrote:
> I used the underscore approach for years too, but I've been quite
> pleased by the things I can do with structures that I can't do with a
> collection of single variables.
>
> The ability to replace lumps like this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS =
> "login, pw_email, password, ship_fname, ship_lname, ship_email,
> ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
> ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
> bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
> bill_state, bill_zip, bill_cntry"
> STANDARDOUTPUTLEVEL = "">
>
> with this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS="cust" STANDARDOUTPUTLEVEL="">
>
> was enough to convince me.
>
> Once you start coding like that, you fall in love with the fact that
> you can change your structure as often as you like, without having to
> remember to change the parameters list for every function that needs
> the full list.
>

I totally agree. Perfect example of why to use structures. I have some
old functions with so many parameters it's silly. No more of that.

BUT, I am not going to use them for form field names ;) A common
function to convert the underscore approach to structures, if you really
need it, should be easy enough, right. Anyway, my mind is made up, back
to coding :)

Adam

#8 · 03-31-05, 04:01 PM

colons in form field names

Hi Bill,

"The ability to replace lumps like this:
<MvFUNCTION NAME =3D "Customer_Insert" PARAMETERS =3D
"login, pw_email, password, ship_fname, ship_lname, ship_email,
ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
bill_state, bill_zip, bill_cntry"
STANDARDOUTPUTLEVEL =3D "">

with this:
<MvFUNCTION NAME =3D "Customer_Insert" PARAMETERS=3D"cust"
STANDARDOUTPUTLEVEL=3D"">

was enough to convince me. "

I write this way quite often, too, but more and more I come to the
realisation that in many cases this is not such a wise choice. It is =
nice
and easy to write, but a mess later on when you want to reuse code
elsewhere, because you don't really know anymore what values are =
required by
the interface and you end up then reading the code or the comments (if =
there
are any....) to figure out what is what.=20

Today I try to limit this to function that can be overloaded or that =
need to
remain flexible, or use a combination of both were required values are
indicated in the interface and the optional parameters in form of
structures. For those this technique/style is of course unbeatable.

Markus

-----Original Message-----
From: [email protected] [mailto:[email protected]] On =
Behalf
Of Bill Guindon
Sent: Mittwoch, 30. M=E4rz 2005 19:06
To: Adam Denning
Cc: Miva Users
Subject: Re: [meu] colons in form field names

On Wed, 30 Mar 2005 08:46:47 -0800, Adam Denning =
<[email protected]>
wrote:
> Bill,
>=20
> Nice to see the guerrilla in these parts again.
>=20
> I've always used underscores. Not as slick as structures, but using a=20
> common prefix for all globals in an app avoids variable collisions.
> Recently I've been working with an app that uses colons all over the=20
> place for form field names. I thought this was a cool idea initially,=20
> and started using them in a new project. Then I found the scripting=20
> issues. I think I'll go back to underscores. As neat as they are,=20
> everything doesn't have to be a structure...

It'd take a lot of deprogramming for me to change my thinking on =
structures.
I'm quite hooked on them. I doubt the JS issue would be large enough to
force me stop now, especially since you've already found a solution :)

I used the underscore approach for years too, but I've been quite =
pleased by
the things I can do with structures that I can't do with a collection of
single variables.

The ability to replace lumps like this:
<MvFUNCTION NAME =3D "Customer_Insert" PARAMETERS =3D
"login, pw_email, password, ship_fname, ship_lname, ship_email,
ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
bill_state, bill_zip, bill_cntry"
STANDARDOUTPUTLEVEL =3D "">

with this:
<MvFUNCTION NAME =3D "Customer_Insert" PARAMETERS=3D"cust"
STANDARDOUTPUTLEVEL=3D"">
=20
was enough to convince me. =20

Once you start coding like that, you fall in love with the fact that you =
can
change your structure as often as you like, without having to remember =
to
change the parameters list for every function that needs the full list.

--
Bill Guindon (aka aGorilla)

#9 · 03-31-05, 05:20 PM

colons in form field names

On Fri, 1 Apr 2005 02:01:04 +0200, MvMarkus <[email protected]> wrote:
> Hi Bill,
>
> "The ability to replace lumps like this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS =
> "login, pw_email, password, ship_fname, ship_lname, ship_email,
> ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
> ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
> bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
> bill_state, bill_zip, bill_cntry"
> STANDARDOUTPUTLEVEL = "">
>
> with this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS="cust"
> STANDARDOUTPUTLEVEL="">
>
> was enough to convince me. "
>
> I write this way quite often, too, but more and more I come to the
> realisation that in many cases this is not such a wise choice. It is nice
> and easy to write, but a mess later on when you want to reuse code
> elsewhere, because you don't really know anymore what values are required by
> the interface and you end up then reading the code or the comments (if there
> are any....) to figure out what is what.
>
> Today I try to limit this to function that can be overloaded or that need to
> remain flexible, or use a combination of both were required values are
> indicated in the interface and the optional parameters in form of
> structures. For those this technique/style is of course unbeatable.
>

While I'll admit that I'm a bit of a zealot when it comes to
structures, even I use a mix of both styles.

I typically use named variables in all of my small helper functions --
the ones most likely to be copied from app to app.

For me, structures seem to work best when you're thinking in terms of
an "object". Customer, Product, Order Item, all of these seem to be
perfect fits. And in those cases, maintenance is rarely an issue as
the branches typically don't change, and even if they do, there's
usually at least one "defining" function that has them all together
(typically a database reader, or a form validator).

Every now and then, I'll take it a step further and have a definition
function that contains a list of all of the fields, and then build
generic setters/getters from that.

In the end, we all use the style that suits us best - unless convinced
otherwise ;)

--
Bill Guindon (aka aGorilla)

#10 · 03-31-05, 08:50 PM

colons in form field names

MvMarkus wrote:
> Hi Bill,
>
> "The ability to replace lumps like this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS =
> "login, pw_email, password, ship_fname, ship_lname, ship_email,
> ship_comp, ship_phone, ship_fax, ship_addr, ship_city, ship_state,
> ship_zip, ship_cntry, bill_fname, bill_lname, bill_email,
> bill_comp, bill_phone, bill_fax, bill_addr, bill_city,
> bill_state, bill_zip, bill_cntry"
> STANDARDOUTPUTLEVEL = "">
>
> with this:
> <MvFUNCTION NAME = "Customer_Insert" PARAMETERS="cust"
> STANDARDOUTPUTLEVEL="">
>
> was enough to convince me. "
>
>
> I write this way quite often, too, but more and more I come to the
> realisation that in many cases this is not such a wise choice. It is nice
> and easy to write, but a mess later on when you want to reuse code
> elsewhere, because you don't really know anymore what values are required by
> the interface and you end up then reading the code or the comments (if there
> are any....) to figure out what is what.
>
> Today I try to limit this to function that can be overloaded or that need to
> remain flexible, or use a combination of both were required values are
> indicated in the interface and the optional parameters in form of
> structures. For those this technique/style is of course unbeatable.
>
> Markus
>

Howdy Markus. I like it for backwards compatibility. If you have a
function to, say, add a record to a database, and another app that calls
that function, you can make that app continue to work if it isn't
upgraded by setting default values.

Interesting topic.

Adam

Announcement

colons in form field names

colons in form field names

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment