• (cs)

    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.

  • (cs)

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

  • (cs)

    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.

  • (cs)

    I guess that's designer code.

    I need a beer.

  • (cs) in reply to Maurits

    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();"

  • James (unregistered)

    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]

  • (cs) in reply to Mung Kee

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

    Check the first line of code.

  • (cs) in reply to James
    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?


  • (cs) in reply to James
    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?
  • (cs) in reply to redtetrahedron
    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']).
  • (cs)

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

  • (cs) in reply to chb

    Did you mean Brillante?

    No, he didn't.

  • (cs) in reply to chb
    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.
  • (cs) in reply to Mung Kee

    No, you don't.

  • Just another guy (unregistered) in reply to chb
    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.

  • (cs) in reply to Chris F

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

  • (cs) in reply to chb
    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.


  • AC (unregistered) in reply to Mung Kee
    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.
  • (cs) in reply to WIldpeaks
    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.
  • (cs) in reply to AC
    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.
  • (cs) in reply to Mung Kee
    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.

  • (cs) in reply to Mung Kee
    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.
  • (cs) in reply to Jeff S
    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.
  • (cs) in reply to Mung Kee

    <font size="2">

    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.</font>
  • (cs) in reply to John Smallberries
    John Smallberries:
    <font size="2">
    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.</font>


    It's just shorthand dude.  I'm not a hater.
  • x-sol (to lazy to login) (unregistered) in reply to Mung Kee

    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 

  • Oliver Klozoff (unregistered) in reply to John Bigboote
    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'? :)

  • (cs)

    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.  [:#]

  • (cs) in reply to Mung Kee

    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.

  • (cs) in reply to x-sol (to lazy to login)
    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...)
  • (cs) in reply to Oliver Klozoff

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



    Brillant!!!

  • (cs) in reply to christoofar
    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?
  • (cs) in reply to x-sol (to lazy to login)
    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?
  • (cs) in reply to James
    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

  • (cs) in reply to Mung Kee
    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?
  • (cs) in reply to John Smallberries
    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! */
    .
    .
    .
  • (cs) in reply to Jeff S

    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?


  • (cs) in reply to Gene Wirchenko

    Wow. Just.... Wow.

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

    Wow.

  • (cs) in reply to Mung Kee
    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.
  • (cs) in reply to John Smallberries
    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.
  • (cs) in reply to Chris F
    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.
  • (cs) in reply to Jeff S
    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.
  • (cs) in reply to John Smallberries
    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
  • (cs) in reply to Mung Kee
    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.
  • (cs) in reply to Mung Kee
    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.
  • (cs) in reply to Ytram
    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?
  • (cs) in reply to Mung Kee
    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.
  • (cs) in reply to John Smallberries
    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.
  • Lazy Lurker (unregistered) in reply to Mung Kee

    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)

  • (cs) in reply to John Bigboote
    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.)

Leave a comment on “Real Programmers Build Their Own Form”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article