Comment On Real Programmers Build Their Own Form

Who doesn't love String concatenation?  I hope they have  'form1' defined globally somewhere.



P.S.

I loathe when people prefix HTML widget names with "sel" or "txt", as
if the server code has any interest in whether  it's a 
goddamn  text box or select box.  Let's hang him, then we'll
stab him...and then we'll kill him.

as opposed to onchange="this.form.submit();"

Astonishing. Really, truly astonishing. But this can't be wrong. After all, it's javascript.





I eagerly await an apologist to tell me why





form1.submit()





would have been a bad thing.



Bonus mini-WTF: the variables in the GET url are not escaped or encoded
in any way. Hey, if you are going to go balls-out with the javascript,
go all the way.

I guess that's designer code.



I need a beer.

Hmm... I've just thought of something.

Perhaps there's a hidden element on the form <input name="doit" value="yes"> - and if the server sees this (a real form submission) then it acts on the information.

So a submit() call would be out of place... the form just needs to reload, preserving the already filled-out information.

This could still be fixed with an
    onchange="this.form.doit.value = ''; this.form.submit();"

Oh, this is nothing at all... I have far to often seen forms where a
"programmer" came up with a quick "solution" that "just works". You
know you've all seen them, forms with onclick, onchange, etc attributes
that contain about 2 pages of javascript embedded in them.



There's this image map on a site the bossman made that has an image map
and the client wanted a box to display the text describing the county
clicked on. Each coord (or whatever) in the image map contains an
onmouseover attribute that has about a page worth of js, all of it
identical, the only thing that changes is the text (which is also
embedded in the attribute).



[edit]

Oh my.. I just noticed that he does the form's job for it by creating the get query string inside. BRILLANT!!

[/edit]

Mung Kee:

Who doesn't love String concatenation?  I hope they have  'form1' defined globally somewhere.

Check the first line of code.

Anonymous:

--snip--


Oh my.. I just noticed that he does the form's job for it by creating the get query string inside. BRILLANT!!

http://dictionary.reference.com/search?q=brillant

No entry found for brillant.

Did you mean Brillante?

Anonymous:

I have far to often seen forms where a
"programmer" came up with a quick "solution" that "just works".

I know we talked about the "bridge to far", but where is "often" and how far is it to there?

redtetrahedron:

Mung Kee:

Who doesn't love
String concatenation?  I hope they have  'form1' defined
globally somewhere.

Check the first line of code.

That first line does $hit to give you the reference to form1.  You
still need use the object model to get it (document.all or
document.forms['form1']).

This code is truly before its time.  I dub thee AHAX.

Did you mean Brillante?



No, he didn't.

chb:

Anonymous:

--snip--


Oh my.. I just noticed that he does the form's job for it by creating the get query string inside. BRILLANT!!

http://dictionary.reference.com/search?q=brillant

No entry found for brillant.

Did you mean Brillante?

Try searching for brillant in that little box at the top.  You'll understand.

No, you don't.

chb:

Anonymous:

--snip--
Oh my.. I just noticed that he does the form's job for it by creating the get query string inside. BRILLANT!!

http://dictionary.reference.com/search?q=brillant

No entry found for brillant.

Did you mean Brillante?

Nope... the Brillant is now the official SI unit of coding excellence.  Sort of like the what Helen is to beauty where a millihelen is the beauty required to launch a single ship.

Oh oh, looks like Paula got a job at Form Design.

chb:

Anonymous:

--snip--


Oh my.. I just noticed that he does the form's job for it by creating the get query string inside. BRILLANT!!

http://dictionary.reference.com/search?q=brillant

No entry found for brillant.

Did you mean Brillante?

I try to add a little gayness and sparkle to every line of code I write.

Brillante

\Bril*lan"te\, adv. [It. See Brilliant, a.] (Mus.) In a gay, showy, and sparkling style.

Mung Kee:

I loathe when people prefix HTML widget names with "sel" or "txt", as
if the server code has any interest in whether  it's a 
goddamn  text box or select box.

hungarian warts are there to help programmers not the code and in
writing the server side portion it'd probably be useful to know what
type of control a value came from, especially if you're recreating the
form and want to set the selected item in a <select> dropdown.

WIldpeaks:

Oh oh, looks like Paula got a job at Form Design.

No, Paula's code would be tidier, more elegant...submitting the form
would just display an alert box saying "Form sumbitted" with no
post-back.

Anonymous:

Mung Kee:

I loathe when people prefix HTML widget names with "sel" or "txt", as
if the server code has any interest in whether  it's a 
goddamn  text box or select box.

hungarian warts are there to help programmers not the code and in
writing the server side portion it'd probably be useful to know what
type of control a value came from, especially if you're recreating the
form and want to set the selected item in a select dropdown.

I maintain, why does the server give a damn about what kind of control
it is?  All the server needs to know is the front end needs the
selected value and a list of possible values.  It's the GUI's
burden to compare the selected value with the items in the list, to
determine how to render the widget.

Mung Kee:

Anonymous:

Mung Kee:

I
loathe when people prefix HTML widget names with "sel" or "txt", as
if the server code has any interest in whether  it's a 
goddamn  text box or select box.

hungarian warts are there to help programmers not the code and in
writing the server side portion it'd probably be useful to know what
type of control a value came from, especially if you're recreating the
form and want to set the selected item in a select dropdown.

I maintain, why does the server give a damn about what kind of control
it is?  All the server needs to know is the front end needs the
selected value and a list of possible values.  It's the GUI's
burden to compare the selected value with the items in the list, to
determine how to render the widget.

To repeat:  hungarian notion is used to help the PROGRAMMER (you
know, a person) remember what datatypes different variables are, not
for a "server". 



From your other post: the object form1 is a perfectly valid reference
for the javascript, since the context it is running in is the document.

Mung Kee:

That first line does $hit to give you the reference to form1.  You
still need use the object model to get it (document.all or
document.forms['form1']).

Browsers, especially IE, tend to inject forms and inputs by their name
and all tags by their id into the global JS namespace. It's a "help"
for lazy developers, resulting in unsightly JS code all over the world.

Jeff S:

Mung Kee:

Anonymous:

Mung Kee:

I
loathe when people prefix HTML widget names with "sel" or "txt", as
if the server code has any interest in whether  it's a 
goddamn  text box or select box.

hungarian warts are there to help programmers not the code and in
writing the server side portion it'd probably be useful to know what
type of control a value came from, especially if you're recreating the
form and want to set the selected item in a select dropdown.

I maintain, why does the server give a damn about what kind of control
it is?  All the server needs to know is the front end needs the
selected value and a list of possible values.  It's the GUI's
burden to compare the selected value with the items in the list, to
determine how to render the widget.

To repeat:  hungarian notion is used to help the PROGRAMMER (you
know, a person) remember what datatypes different variables are, not
for a "server". 



From your other post: the object form1 is a perfectly valid reference
for the javascript, since the context it is running in is the document.

When I said the server, I was implying the server-side code.  When
you use ASP to interact with the database, they are one in the
same.  In the Java world, JSP pages are often considered the front
end, since they usually do very little of the heavy lifting. 
Typically you would adopt or write some MVC architecture (such as
Struts or JSF) in which a controller interacts with business objects
and passes the result of those interactions to a JSP page. 
Someone, far more experienced with M$ technologies than I, can probably
say whether this paradigm exists in that camp.



RE: defining form1, I stand corrected.  'document' is assumed.

Mung Kee:

Someone, far more experienced with M$ technologies than I, can probably
say whether this paradigm exists in that camp.

Of course it does.

And your use of "M$" says volumes...not good ones.

John Smallberries:

Mung Kee:

Someone, far more experienced with M$ technologies than I, can probably
say whether this paradigm exists in that camp.

Of course it does.

And your use of "M$" says volumes...not good ones.

It's just shorthand dude.  I'm not a hater.

Mung Kee:

Jeff S:

Mung Kee:

Anonymous:

Mung Kee:

I loathe when people prefix HTML widget names with "sel" or "txt", as if the server code has any interest in whether  it's a  goddamn  text box or select box.

hungarian warts are there to help programmers not the code and in writing the server side portion it'd probably be useful to know what type of control a value came from, especially if you're recreating the form and want to set the selected item in a select dropdown.

I maintain, why does the server give a damn about what kind of control it is?  All the server needs to know is the front end needs the selected value and a list of possible values.  It's the GUI's burden to compare the selected value with the items in the list, to determine how to render the widget.

To repeat:  hungarian notion is used to help the PROGRAMMER (you know, a person) remember what datatypes different variables are, not for a "server". 

From your other post: the object form1 is a perfectly valid reference for the javascript, since the context it is running in is the document.

When I said the server, I was implying the server-side code.  When you use ASP to interact with the database, they are one in the same.  In the Java world, JSP pages are often considered the front end, since they usually do very little of the heavy lifting.  Typically you would adopt or write some MVC architecture (such as Struts or JSF) in which a controller interacts with business objects and passes the result of those interactions to a JSP page.  Someone, far more experienced with M$ technologies than I, can probably say whether this paradigm exists in that camp.

RE: defining form1, I stand corrected.  'document' is assumed.

What is trying to be said is that as a programmer or prorammers working on a large business application, with a web based front end, it will be exponitally easier to write, update, debug..... if the type of the control is indicated in some way in the the control name. Especially since in most case the server side code for the UI will need to marshal data to and from controls and the database and a humna has to manage the code for this action, the human will 9 times out of 10 be glad for the txt, ddl, lst, btn, rdo and so on.

Where I'm at now we do everything basackwards so we do PasswordTXT or SubmitBTN or WhyTheFUckIsThePrefixBeingPostedDDL 

John Bigboote:

WIldpeaks:

Oh oh, looks like Paula got a job at Form Design.

No, Paula's code would be tidier, more elegant...submitting the form
would just display an alert box saying "Form sumbitted" with no
post-back.

Wouldn't that be 'Form submtted'? :)

I'm not a big fan of hungarian notation, but I find UI development a great deal easier when using it.



As for anything below the presentation layer, hungarian notation is evil.



Just my opinion of course.  [:#]

I love M$!   Their architecture problems have paved the way
for many in India to make a decent liv...  ugh shhhhhhhhh... I'll
go back to my M$ code.

Anonymous:

Where I'm at now we do everything basackwards
so we do PasswordTXT or SubmitBTN
or WhyTheFUckIsThePrefixBeingPostedDDL 

I'm not sure why, but the only things
I indicate type for are UI elements. When I do that, I do append the
type indicator, not prepend it. The reason is that I usually know the
name of the control I want to reference (but not necessarily its type),
and I want autocomplete to find it that way. Ex: _lastNameTextBox.



This way, all things having to do with last name are grouped (TextBox _lastNameTextBox, String _lastName...)

Wouldn't that be 'Form submtted'? :)

Brillant!!!

christoofar:

I love M$!   Their architecture problems have paved the way
for many in India to make a decent liv...  ugh shhhhhhhhh... I'll
go back to my M$ code.

Ahem, "their" architecture problems, or the architecture problems you've created by improperly using their technology?

Anonymous:

What is trying to be said is that as a
programmer or prorammers working on a large business application, with
a web based front end, it will be exponitally easier to write, update,
debug..... if the type of the control is indicated in some way in the
the control name. Especially since in most case the server side code
for the UI will need to marshal data to and from controls and the
database and a humna has to manage the code for this action, the human
will 9 times out of 10 be glad for the txt, ddl, lst, btn, rdo and so
on.

Where I'm at now we do everything basackwards so we do PasswordTXT
or SubmitBTN or WhyTheFUckIsThePrefixBeingPostedDDL 

Everyone seems to be preaching for it but no one has given me an
example of when the server code should care what type it is.  When
all is said and done, it's just a hash you're working with on the
server anyway.  Who cares what the visual representation is on the
client but the client itself?

Anonymous:

Oh, this is nothing at all... I have far to often seen forms where a
"programmer" came up with a quick "solution" that "just works".

Would that be "just" as in "barely"?



Just do it!



Good weekend, folks!  (This is my "Friday".  I am going to a gaming convention in Seattle for a long weekend.)



Sincerely,



Gene Wirchenko

Mung Kee:

Anonymous:

What is trying to be said is that as a
programmer or prorammers working on a large business application, with
a web based front end, it will be exponitally easier to write, update,
debug..... if the type of the control is indicated in some way in the
the control name. Especially since in most case the server side code
for the UI will need to marshal data to and from controls and the
database and a humna has to manage the code for this action, the human
will 9 times out of 10 be glad for the txt, ddl, lst, btn, rdo and so
on.

Where I'm at now we do everything basackwards so we do PasswordTXT
or SubmitBTN or WhyTheFUckIsThePrefixBeingPostedDDL 

Everyone seems to be preaching for it but no one has given me an
example of when the server code should care what type it is.  When
all is said and done, it's just a hash you're working with on the
server anyway.  Who cares what the visual representation is on the
client but the client itself?

You are not listening/understanding .... It is helpful so that you, the
PROGRAMMER, has some idea what UI element these different object
variables represent while you are writing/designing/editing your
pages.   YOu can see that "txtName" is a text box, while
"lstName" is a drop-down, or whatever convention you use.  It has
nothing to do with a server accepting or parsing a GET string and then
somehow using the name of the name/value pair to be able to do
something with it... it is for a person, a programmer, to use an an
aid, a "trick" if you will,  while designing pages to help job
their memory  .... does this make any sense at all?

John Smallberries:

I'm not sure why, but the only things
I indicate type for are UI elements.

It's too much work to revamp Visual Studio's default naming of a
control, so most people back out the 1..N it adds to the identifier and
add something significant...



    textBox1 becomes textBoxLastName



A busy window with say, 70 controls (including all the labels, panels,
edits, menu items, etc) it gets hairy very quickly... especially if you
are in a rush.   Since Intellisense can quickly give me the
type of edit I am dealing with, I prefer to just append the word Edit
if its a "field" on a form (radio, text, dropdown, selectbox, slider),
"Label" if it's a label, "Picture" if it is an image, and "Grid" if it
is a MS or DevExpress grid on the screen.  So you would see:



#region

private string    _lastName;

private Label     _lastNameLabel;  /* "Last Name: " , etc */

private TextBox   _lastNameEdit;



private string    _firstName;

private TextBox   _firstNameEdit;



private Image     _paulaImage;

private Label     _paulaLabel;  /* Brillant! */

.

.

.

sorry lots of typos in that last one ...last lines should be:



it is for a person, a programmer, to use as an
aid, a "trick" if you will,  while designing pages to help jog their memory  .... does this make any sense at all?

Wow. Just.... Wow.

I looked at this and quite literally dropped my jaw when I realized just what was being done.

Wow.

Mung Kee:

Everyone seems to be preaching for it but no one has given me an
example of when the server code should care what type it is.  When
all is said and done, it's just a hash you're working with on the
server anyway.  Who cares what the visual representation is on the
client but the client itself?

Are you proposing that it's appropriate to have a client-side
identifier (Id) be named one thing, but its server-side identifier
(Name) named something different? Like "selWhatever" and "whatever"? If
that's that case, I would rather have them the same, even if the server
doesn't care about the type prefix.

John Smallberries:

christoofar:

I love M$!   Their architecture problems have paved the way
for many in India to make a decent liv...  ugh shhhhhhhhh... I'll
go back to my M$ code.

Ahem, "their" architecture problems, or the architecture problems you've created by improperly using their technology?

While I'll certainly admit their architectural ability has gotten
better with .Net, you can not gaze upon the hideousness that is MFC
without having a portion of your life spirited away.

Chris F:

John Smallberries:

christoofar:

I love M$!   Their architecture problems
have paved the way
for many in India to make a decent liv...  ugh shhhhhhhhh... I'll
go back to my M$ code.

Ahem, "their" architecture problems, or the architecture problems you've created by improperly using their technology?

While I'll certainly admit their architectural ability has gotten
better with .Net, you can not gaze upon the hideousness that is MFC
without having a portion of your life spirited away.

Ok, MFC was/is nasty.

Even so, with some effort, I was able to use to it build reasonably elegent and maintainable applications.



I still feel that too many developers blame the IDE/framework/OS/language instead of themselves for writing shitty code.

Jeff S:

Mung Kee:

Anonymous:

What is trying to be said is that as a
programmer or prorammers working on a large business application, with
a web based front end, it will be exponitally easier to write, update,
debug..... if the type of the control is indicated in some way in the
the control name. Especially since in most case the server side code
for the UI will need to marshal data to and from controls and the
database and a humna has to manage the code for this action, the human
will 9 times out of 10 be glad for the txt, ddl, lst, btn, rdo and so
on.

Where I'm at now we do everything basackwards so we do PasswordTXT
or SubmitBTN or WhyTheFUckIsThePrefixBeingPostedDDL 

Everyone seems to be preaching for it but no one has given me an
example of when the server code should care what type it is.  When
all is said and done, it's just a hash you're working with on the
server anyway.  Who cares what the visual representation is on the
client but the client itself?

You are not listening/understanding .... It is helpful so that you, the
PROGRAMMER, has some idea what UI element these different object
variables represent while you are writing/designing/editing your
pages.   YOu can see that "txtName" is a text box, while
"lstName" is a drop-down, or whatever convention you use.  It has
nothing to do with a server accepting or parsing a GET string and then
somehow using the name of the name/value pair to be able to do
something with it... it is for a person, a programmer, to use an an
aid, a "trick" if you will,  while designing pages to help job
their memory  .... does this make any sense at all?

I understood that quite clearly the first time you typed it.  Just
please, PLEASE, tell me why you want to know that it was a text
box.  Why is this relevant?  Give me an example of why it
makes it exponentially easier to write/update/debug.

John Smallberries:

I still feel that too many developers blame the IDE/framework/OS/language instead of themselves for writing shitty code.

You got that right brother Smallberries

Mung Kee:

Just
please, PLEASE, tell me why you want to know that it was a text
box.  Why is this relevant?  Give me an example of why it
makes it exponentially easier to write/update/debug.

Ok, at the risk of getting flamed for invoking the evil of JS, here goes:



If I have a UI element that I'm manipulating client-side in JavaScript,
It's handy to know what it is so I can use the correct DOM properties
and methods. That's it, no big deal. I also keep the same name
server-side, simply for consistency.

Mung Kee:

Jeff S:

Mung Kee:

Anonymous:

What is trying to be said is that as a
programmer or prorammers working on a large business application, with
a web based front end, it will be exponitally easier to write, update,
debug..... if the type of the control is indicated in some way in the
the control name. Especially since in most case the server side code
for the UI will need to marshal data to and from controls and the
database and a humna has to manage the code for this action, the human
will 9 times out of 10 be glad for the txt, ddl, lst, btn, rdo and so
on.

Where I'm at now we do everything basackwards so we do PasswordTXT
or SubmitBTN or WhyTheFUckIsThePrefixBeingPostedDDL 

Everyone seems to be preaching for it but no one has given me an
example of when the server code should care what type it is.  When
all is said and done, it's just a hash you're working with on the
server anyway.  Who cares what the visual representation is on the
client but the client itself?

You are not listening/understanding .... It is helpful so that you, the
PROGRAMMER, has some idea what UI element these different object
variables represent while you are writing/designing/editing your
pages.   YOu can see that "txtName" is a text box, while
"lstName" is a drop-down, or whatever convention you use.  It has
nothing to do with a server accepting or parsing a GET string and then
somehow using the name of the name/value pair to be able to do
something with it... it is for a person, a programmer, to use an an
aid, a "trick" if you will,  while designing pages to help job
their memory  .... does this make any sense at all?

I understood that quite clearly the first time you typed it.  Just
please, PLEASE, tell me why you want to know that it was a text
box.  Why is this relevant?  Give me an example of why it
makes it exponentially easier to write/update/debug.

Personally for me it's because you usually have several controls of
each type that you need to do something with.  As an example, we
localize all of our labels, so I can easily access each label with
intellisense by prefixing them all with "lbl".  When I'm filling
text boxes with data, I just hit this.txt and intellisense will show me
all of the controls prefixed with txt.

Ytram:

Personally for me it's because you usually have several controls of
each type that you need to do something with.  As an example, we
localize all of our labels, so I can easily access each label with
intellisense by prefixing them all with "lbl".  When I'm filling
text boxes with data, I just hit this.txt and intellisense will show me
all of the controls prefixed with txt.

What is this intellisense you speak of?

Mung Kee:

Ytram:

Personally for me it's because you usually have several controls of
each type that you need to do something with.  As an example, we
localize all of our labels, so I can easily access each label with
intellisense by prefixing them all with "lbl".  When I'm filling
text boxes with data, I just hit this.txt and intellisense will show me
all of the controls prefixed with txt.

What is this intellisense you speak of?

Must be something from M$, implemeted in MFC.

John Smallberries:

Mung Kee:

Ytram:

Personally for me it's because you usually have several controls of
each type that you need to do something with.  As an example, we
localize all of our labels, so I can easily access each label with
intellisense by prefixing them all with "lbl".  When I'm filling
text boxes with data, I just hit this.txt and intellisense will show me
all of the controls prefixed with txt.

What is this intellisense you speak of?

Must be something from M$, implemeted in MFC.

When you mention MFC, I completely understand the need.  These
prefixs (txt,lbl,sel) aren't all that uncommon in Swing either.  I
was mentally in web context and not "stand-alone application"
context.  I just don't see the value in web programming.

Mung Kee:

Ytram:

Personally for me it's because you usually have several controls of each type that you need to do something with.  As an example, we localize all of our labels, so I can easily access each label with intellisense by prefixing them all with "lbl".  When I'm filling text boxes with data, I just hit this.txt and intellisense will show me all of the controls prefixed with txt.

What is this intellisense you speak of?

REAL programmers remember EVERY variable name in scope at all times.  You new-school pansies.

 

 

(intellisense: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vcovrAutomaticStatementCompletion.asp)

John Bigboote:

Astonishing. Really, truly astonishing. But this can't be wrong. After all, it's javascript.

Of course it's wrong... it should be constructing XML to send as the query string.

(I'm going to try previewing this post, even though everybody says that previewing is what causes the most common forum WTF, since it always bites me when I don't preview so what do I have to lose? At least I'll get to see it formatted properly, even if you don't.)