- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Perhaps this will shed some light: You are correct that the names of the fields will be submitted to the server and act as strings, or perhaps as keys on a hash or associative array, but what you are missing is that they are also used to address the widget from client-side scripting. Since their names become essencially pointers to the widget object, knowing their type is useful, given that different types of widgets can have different properties, methods, attributes, etc.
I hope this clears it up.
-dZ.
Admin
Fair enough... now why the hell would you ID a label since you don't actually use it for anything? Does ASP.net require you to ID every single HTML element out there?
If by "UI dev" you mean javascript dev, he or she already has the information, and your very specs/documentations should define the correspondance between IDs and elements if one considers that he needs them, since IDs are unique for a given page (and usually coherent throughout the application)
If your "UI dev" is a designer, he or she will use the outputted page's code anyway, even though i'll agree that documentation may be useful. Form styling being a pain in the ass and an awfully precisely hand crafted pile of donkey poo, she/he'll have all the classes and IDs of your form burned into her/his retinas before long anyway
One wonders about that, especially when they're merely repeating the object's inherent characteristics (like it's type)
Admin
I guess that's better than "Form.Sumbit()" (which I've seen in actual code)
Admin
Mung Kee -- I do need to complement you on your avatar -- it fits perfectly with your rather angry posting style!
Then again ... maybe your posts have actually been quite calm, thoughtful and reasonable, but subconciously I have been putting aggressive inflections on the text as I've read it due to the avatar? I may have to revisit!
Admin
Hey!
Admin
If you want to dynamically generate a page, then YES. Even the contents of labels change -- in fact, sometimes more than anything else -- when your HTML is dynamically generated using ASP.NET. Look at this page, right now -- 99% of the text you see right now is a label that has been dynamically created or altered by ASP.NET.
Admin
The avatar is Samir from Office Space. Ever seen it?
I think we pretty much covered miscommunication in language architectures (you typically operate on object instances of the HTML widgets in ASP code). In Java and Perl, its a hash. A list of name value pairs. An HTML select box only submits one value...the selected one. A radio button group only submits one value...the selected one.
What's a spliced and hacked glue language, or did you make that up? Have you ever developed a significant application using another language or is this your first job? If you're unaware of all the wonderful languages and platforms out there then you are surely missing out. Each one of them may have their own caveates, but to learn them is always rewarding.
Admin
If you've read on in the thread, you'll see that I said I have seen variables named strFirstname and intZip in Java code. It was primarily "sel" (meaning a select box) that I have a problem with on the server side. Typically I, like most of us, do develop an application end to end so I dont rely on a UI person and its not an issue. I just don't see the value in it.
Admin
I can't believe this naming discussion went on for so many posts, when it should have ended long ago.
Perhaps I can help to bring it to an end, because if you look at it from above it really is easy.
You have a server that is responsible to provide form data, accept form data and perhaps store it away or process it in some way.
You have a client that is responsible to to show the user a form filled with data and accept the users input.
To make both interact you have an (transportation) interface, that allows
and
Now if this transportation interface where some kind of proprietary network protocol, no one here would recommend, that the protocol should encapsulate any implementation details from either server or client side.
But this discussion is not about a proprietary network protocol, but about HTML/HTTP client server interaction, where most frameworks use the HTML form control's name for that interface, because that is what the browser is required to do per spec (and here this browser behavior is part of the client side).
Now while naming the control's should actually be only of interest to the "GUI" developer (a.k.a. web designer in this case) it may become part of the transportation interface due to the mentioned browser behavior.
Mung Kee's position is, that because the transportation interface should not reflect GUI decisions, you should never name your controls in a way, that their type is reflected in the transportation interface (and that's also my position and I think, as it is good design, it should be everybody's position).
However, others have the opposite opinion, and .... uhmm ... and I really really tried to see to their point and defend it here as at least sometimes sensible, but actually I can't. Even if you use frameworks, that generate HTML code for you and hide the request/response cycle involved in web apps and therefor the transportation interface, I can't see ANY reason to name data fields by the associated GUI elements.
Well, now that I've written this post, I think I'll fail to end this discussion, but I still can't believe it went on for so long in the first place.
cu
Admin
<font size="2">
Yes, because it is still a server-side object instance (you can accept the default, label1, lable2, but that's just nasty). Also, If I need to manipulate it on the client, I need to know its name (identifier).
</font><font size="2">
I mean "anyone who may need to reference the element, now or in the future".
</font>
<font size="2">
Uh, doubtful. Most UI/js designers/devs I've worked with appreciate a little help.
</font><font size="2">
I agree. For typed languages, it's redundant. For the case where an element is generated on a server, then referenced in a loosely-typed language on the client, I think it has merit.
</font>
Admin
I wasn't missing that at all. I have done quite a bit of JavaScript and DHTML over the years and am well aware of the JavaScript DOM (cross-browser). My underlying assumption here is that the GUI developer should know that "firstname" is a text field in a form. If it's an issue of too many fields on the form, you need to design it as a workflow and not a single screen. It's not that difficult to remember what HTML widget is used for 10-20 pieces of data.
As you'll see in a later post if you can rationalize "sel" prefixing a select box name lets do it on DB tables and everything in between.
Admin
<font size="2">
</font><font size="2">
I believe you answered your own question.
</font><font size="2">
</font><font size="2"></font>
Admin
Eagle -- nice post, I couldn't agree more.
The debate seems to be more about whether or not programmers who decide that they like to prefix things occasionally shoud be fired, shot, or worse; and whether or not it really truly affects the enterprise and overall productivity.
being the spineless bastard that I am, I feel that if the guy writing the html/javascript likes to use prefixes, which mean sthat the form submitted will have a name/value pair of "txtName" instead of "Name", how much of my time and productivity should I spend ranting, raving and complaining to anyone that will listen about it, when it literally means I have to type 3 more characters on they keyboard now and then.
Would I prefer "name" ? Sure! Would I use "Name". Absolutely! Might I even suggest that the html guy uses "name" also? You bet! But will I rant and rave and complain and call people "retarded" and question their programming skill and try to get people fired and assume that this "txtName" object has caused massive productivity issues?
Nah .... I'll get over it.
Admin
Admittedly, at times they are/were both. Many times I post something that is sarchastic and meant as a joke that can come off as angry, but sometimes I can definitely post something is meant to be a flame. Who doesn't? I have never met an engineer who hasn't gotten heated about something for which he has conviction.
Admin
Sorry dude, you weren't around! We needed one.
Admin
You know the difference between a data field (in OO-languages also called member, in procedural languages often called variable, and in databases often called column) and a control, don't you?
The whole point here is, that the browser uses the control's name also as the name of the data field, when sending data back to the server. Now if you think it is good design to write design-dependent server side code, then go on, keep naming your HTML controls by their (control) type, but if you (as Mung Kee) think you should write your server side code independent from the design (e.g. to make it reusable), then refrain from doing so, and instead name your controls after the data they handle.
cu
Admin
Finally something I agree with!
uh... with which I agree.
Admin
I'm not a huge fan of what-if programming* but suppose we want to change the UI altogether. Maybe we want to expose it as a web service instead of an ASP/JSP/PHP page. What does "selTitle" or "txtFirstName" mean then? Nothing, because it's out of context. The point is, you never really know for sure whats going to happen with your app down the road, so let's not muck it up with things that are there only to jumstart a GUI developers brain.
*what-if programming - v. - The act of programming in which upwards of 75% of the code is written for "might-be scenarios" that will never be realized
Admin
How the fuck is the ASP page, whose sole purpose is to generate the client-side HTML, going to be "reused" to do something else?
Once the server-side page scrapes the submitted form, it will construct/fill a business class instance with the data. At that time, the abstraction to the business tier can occur, and the business object's members name's can reflect that.
Admin
I still don't see where we are disagreeing or where anything I wrote contradicts anything you've said... The "txt" prefix of "txtName" means nothing to the ASP page even BEFORE your "what-if" scenerio, as you've mentioned over and over.
But again, remember the point of that ASP page is to accept a post from an HTML page. Whether you like it or not, they are tightly bound. There are other technologies -- web services, for example -- that you should be using if you want to think about writing a generic page that accepts requests from various sources -- even non-HTML forms -- and does things with it.
Admin
Prefixing the database column names and prefix UI controls is not the same thing. In the database case, you're describing the data type with a prefix. In the UI case, you're describing the data representation. Both of these are adding information to your variable names, but not the same information.
As I mentioned before, I'd rather have the advantages of lbl, txt and sel in my html IF I was writing a lot of code to manipulate it. But this has nothing to do with wanting type names on my database schema.
Thus, thinking hungarian notation on column names is stupid does not require you to think that representation names on UI objects are stupid. Obviously the real problem is with the HTML standard, that doesn't allow you to simply rename postdata with a name different than the object it came from.
After typing that I realize I only assume HTML can't do that (simply). If it can, then your position is the correct one.
"This forum is here to discuss irregularities or peculiar implementations. That's what I was doing when I mentioned this."
It seemed to me that the "discussion" was becoming an "ad-hominem flamewar," which is why I suggested that the serverside coders would burst into flame at "txtLastName." And yes, I know that it takes two sides to flame.
Admin
AFAIK, that's not entirely correct. Didn't FORTRAN originally actually use the first letter of the variable name to determine the type?
Admin
They are not (or shouldn't be anyway) tightly bound. Here is an example. I just finished an application that had to post securely, to a remote third-party application using Java. I could easily have queried the database for relevant data, passed it to a JSP page, with a form, and set it to post onload using JS, as many of their clients do. But since there was no need for a VIEW (of MVC/Model2) for this application, my better design sense told me I should programatically post it. In this case, the server expected fields named only after the data they represent and the front end was not coupled with the server side code in any way.
Admin
I'm really not getting this line of reasoning... How do we go from prefixing(or postfixing) our UI controls in the presentation layer down to doing the same thing at the storage level? Obviously there is abstraction between the two layers(dear God, please let there be), so we have objects that we instantiate, take properties from that object and populate a web form. Are you saying from some twisted reasoning that those properties should be prefixed the same way? Why? They're not text boxes, they're going to be other objects or value types.
I really think that this whole discussion has primarily been a miscommunication about different web development platforms. ASP.NET identifies almost every control you place on a page. Those controls have server side objects representing them. So when I place a label on a web form, it also gets declared in my code behind, same for pretty much every other control. A lot of the controls have HTML equivalents that can be used without having this code behind object, but most of the time that the objects are used, are because they are being manipulated in some way. Labels and text boxes have their text properties changed in the code behind. Drop downs and list boxes have their data sources bound to, and buttons have events wired up in the code behind.
I'm not going to talk about perl and php platforms because I have no experience with them. However, I find prefixing controls very useful in ASP.NET development, and I don't see why there is a HUGE uproar about this. I do not see the HARM in doing this, and I definitely don't see the reasoning behind the statement that our database columns should be prefixed with the control types that are used in the presentation layer to represent those columns.
Strangely enough, as I mentioned earlier, I do not care for hungarian notation in anything lower than the presentation layer.
Admin
Of course they aren't using the same information. They are using application layer specific terminology to describe themselves. They can't use the same information. You are using "sel", "txt", "rad" to describe your widgets in HTML and I'm using "VCHAR20", "DTIME" and "NUM" prefixes to describe my widgets in the database. How am I wrong?
Admin
Of course I don't promtoe this cockeyed DB table idea. I was just using it to highlight what I perceive to be an absurdity of using the same priciples on the client. Apparently M$ (shorthand) interpetation of separation between the client and the web layer is different than Sun's. ASP.NET gives you server-side represenations of the HTML widgets while Java gives you a hash. That doesn't mean you HAVE to name a field with the prefix, does it?
Admin
No, I don't HAVE to name them with a prefix, but what is the harm? I find it more useful, my co-workers find it more useful, and we all use it(this is at three different companies, two small ones, one very large). It has been referred to in this thread as a crutch, but a crutch is something that you rely on that actually slows you down or impedes performance. There is no performance benefit or penalty on using this naming convention, and at least for me personally, I find it speeds up my development(especially when combined with IDE sugar like Intellisense).
Admin
I know you're not promoting it, I'm just not getting the connection. That's like saying since I put my cereal in a ceramic bowl, that my cereal must be made of ceramic.
Admin
I could also develop a client server application instead. That would speed up development wouldn't it? It just wouldn't be as maintainable, extensible or well designed.
Admin
Ok, so we've made the jump from presentation layer container names having the same name as database column names. Now we're making the jump from naming conventions you don't like being the same as re-writing the application with a completely different architecture. How in the hell does the naming convention I use keep an application from being maintainable, extensible, or well designed?
Admin
I can see how you could perceive it that way. Forget about the fact that ASP pages can put data into the database (or that you can put cereal into your bowl). What I was saying was, if I use these prefixes to help describe my HTML widgets, while Im writing my JavaScript, why can't i use prefixes to help describe the database fields, so when I see them in my Java/Perl/C/VB/etc code I can immediately tell what the validation should be?
Admin
The only thing you were "wrong" in was your initial claim -- that if you describe your widgets with prefixes, you should be ok with describing databases with prefixes.
The choice to add a prefix to a variable is dependent on the tradeoff between things you gain from the prefix versus compromises you have to make elsewhere (in this case, the application layer). The benefits from "sel" is different from "dtime," and so are the compromises.
Thus, the statement, "why not carry it to the presentation layer and name columns like DTIME_OMFG" implies that these two things are identical and should be either both done or neither done. I claim they are NOT identical and that statement was a slippery slope argument designed to make the reader think "Wow, Hungarian notation in database columns is stupid. And that's the same as prefixing widget types, so I prefixing widget types is stupid too."
Trying to play logic police here, hopefully without being a dick or introducing new logical fallacies.
Admin
First you're saying a certain HTML naming convention is tantamount to naming DB attributes the same way, now you're saying it's analogous to a completely differeent architecture? Sorry, your hyperbole ain't workin'.
Admin
//sucks at forums
Meant to quote this.
Admin
I didn't say all or none, forst of all. You say the benefit/tradeoff is different, but you never say how. They both allow you to immediately recognize information about the [thing] that you wouldn't otherwise know if it were named FIRST_NAME of firstname.
How do the tradeoffs differ?
P.S.
You can try to use psychology to explain my wording if you please, but aren't all our statements "designed" to be compelling in some way? If one is not trying to compel, one should probably keep one's mouth shut, because there is likely no value in the statement.
Admin
Because those prefixes don't describe what type of object the database column is. They tell the programmer what type of control it is. On top of that, the columns in the database could be used in multiple controls. Perhaps I fill a drop down with multiple values from one column, and then on the next page I fill a text box with one value from the same column.
Again, I have to state that this is a personal preference. I am not advocating that you should do it this way, and I don't see why you are strongly advocating against it. My personal preference is not going to break any kind of design, extensibility, or maintainability. If my co-workers hated it also, I would stop doing it, but I would probably do my personal coding the way I like.
Admin
They don't describe what type of object it is, since it's not an object. But, like "selCountry" tells the JavaScript developer what attributes can be used to describe the widget (text value, length, enabled, etc.), my prefixes describe the type of data and the max length. I say, on some perverse level, it's very intuitive. <HAHA>
On top of that, the columns in the database could be used in multiple controls.
My prefixes, though rediculous, don't disallow multiple controls from using the data.
Admin
Ok, so no we're going to go over semantics. Replace object with data type if you prefer, but the point is still there. You are saying that if you're prefixing control names, then that prefix should propagate down to the database column name. So if I happen to fill a text box with the value from one column in one row from one table, that column should be named "txtWhatever" since my form control is "txtWhatever".
I had a question about something you mentioned earlier. You said that you can understand the use of prefixes in an MFC application. Why would it be any different for an ASP.NET application?
Admin
Oh sure - you contradict what you said in the snippet I posted in some of your other posts but that merely shows that you're not a very good thinker. That doesn't show anything.
You asked for concrete proof why I drew the conclusion I did.
I cited my reasoning, along with your offending text.
Then, you told me that the snippet wasn't good enough.
It's clear that not only are you a poor employee but you're also an inconsistent thinker. There's no use having a conversation who is inconsistent so, take care. I hope you get fired soon because you don't have the gumption to speak up when you see a better way to do things. [Of course, maybe you're just not capable of seeing better ways to do things. Regardless, you've got a lot of problems.]
Admin
No, the column should be named using it's own layer specific terminology.
I can understand it in an MFC application because the business logic and the view (the controls) are more often than not in the same classes. My original point (what seems ike 10 years ago) was that the business logic should not have any specific knowledge of the front ned. I gather that, as with Swing, client server is more widely accepted in MFC than in web applications.
Admin
To clarify, if the HTML uses "sel" to say that it's a select box, then we use VCHAR20 to say that it's varchar of 20 character length. Sadly, I have seen many tables with the prefix "TBL_", as if I didnt know it was a table when I opened Toad or ran a query on it.
Admin
I haven't coded with Swing in quite some time(never done MFC), but if I remember correctly, the basic layout of a form class is like so:
public class FormName implements (whatever listener you want)
{
Form Member1
Form Member2
...
Form MemberN
Methods
}
This is essentially the same way win forms work with C# as well. In addition to that, ASP.NET code behinds look similar to this as well. ASP.NET development is a metaphor of window form development(and I'll be the first to admit it's not a very good one), but you will see all of your controls listed as global members of the code behind, and they are manipulated using these server objects. The asp.net page, in a well designed system at least, will either access the Business Entity layer directly, or via a user process layer.
I will again state my opinion that this disagreements in this discussion have mostly stemmed from the fact that some of us are talking about web development with experience in ASP.NET and others are coming from a Java, perl, etc background.
Admin
>>How do the tradeoffs differ?
Pros to using "sel", "txt", etc:
Programmer uses a style he is familiar with
Arguably useful typechecking for javascript
Potentially faster code completion over postfix (lblLastName / txtLastName is better than LastName/LastNameLabel for code completion)
Cons:
Server-side processing contains reference to presentation. Changing presentation name requires changing server-side processing.
Pros to using DTIME_FOO:
Programmers writing SQL should never mess up a column data type
Cons:
Programmers writing SQL have to type extra crap.
There are probably other things to put as pros and cons, I've never tried it some I'm not really sure.
P.S.
You can try to use psychology to explain my wording if you please, but aren't all our statements "designed" to be compelling in some way? If one is not trying to compel, one should probably keep one's mouth shut, because there is likely no value in the statement.
There is a difference between statements designed to compel and statements designed to mislead. Everyone wants people to listen to what they say, and everyone wants to convice other people they are right. You see the statement "why not carry it to the presentation layer and name columns like DTIME_OMFG" as a way to convince people you are right, and I claim it is logically flawed. I apologize for implying that you were intentionally being misleading, as it is obvious you believe it to be true. I have attempted to point out why I think they are different above. I also thought you were being intentionally misleading by picking the most verbose SQL naming convention as possible, where a better parallel would be "datLastLogin" and "txtFirstName" instead of "DTIME_LAST_LOGIN" and "VARCJAR20_FIRST_NAME."
I think there are situations in which breaking a little bit of the layer-based design can be beneficial, especially in smaller systems. I agree that this makes your design worse, but if it makes your coding easier, it can be worth it, in my opinion.
Admin
PERL and PHP let me take bits and parts of other laguages including syntax and put it all in one big mess of code standard nightmare
Admin
I guess it takes a lot of JavaScript to hide every detail of how the HTML page is made from the server. In my imagination I see the picture of a static(*) HTML page that uses AJAX to fetch all data from the server and build the actually displayed page.
(*) Of course the behaviour is dynamic, but the HTML source is always the same, not the kind you get from an old-fashioned web application where the server fills a template with actual data.
Admin
And an AJAX page is the poster child for widgets on demand. When you post from a sufficiently complex AJAX app (and there is room for good, old-fashioned posting), you may know what the form target is (CGI script, code-behind page, whatever -- let's not even pretend to know what the target platform is) and what data you want to move there, but you don't necessarily know what widgets will be in play at the time. It's probably the worst-case scenario for a widget prefix argument.
Admin
Yes, the snippet wasn't good enough. You drew wild, inaccurate conclusions based on a very vague sequence of 2 sentences I wrote, using vague terminology like "not crying" about things ... now, instead ofmaking up your own little stories and assumptions about what I was referring to, why don't you calm down, take a little bit of time to actually read my posts, and see if you can figure it out. I'll give you a clue -- I spelled it out, literally, at least 4 or 5 times. Feel free to point out any inconsistencies that you like, as long as you don't take my statments and go off on wild assumptions and put words in my mouht, and I'll do my best to clarify for you.
But, please, enough with the name calling and "I hope you get fired!" stuff ... try to act like an adult, ok? I'm sorry that if I ask you to actually read what I write offends you, I don't mean it that way, it's just that I'd rather not have to repeat myself even more than I already have and it really makes a conversation easier when two people actually give the other party the courtesy of listening to the other and paying attention. Thanks!
Admin
How was the snippet I quoted vague? It seemed pretty clearly stated.
After you answer that one, explain to me why I should bother with someone who is inconsistent in their thinking?
As for your plea to act like an adult, look at some of the stuff you've written, change your ways, and then we can talk about that.
Admin
I aggree; in this setup, the server no longer needs to know the widget types, so prefixing would be a bad (probably not terribly bad, but ugly nonetheless). But, correct me if I'm wrong, this is a relatively new way to build apps. With many of the commonly used frameworks, like JSF, Struts, WebForms, the server is still responsible for creating the forms with all the widgets; in that scenario, prefixing is IMO acceptable.
Admin
Embedding type information in variable names auto-snookers one of the more useful OO-design benefits; polymorphism.
For this reason alone derivatives (and users) of Hungarian notation need to be taken out, beat up, and shot.
Kudos to the poster a few back that demonstrated a technique for run-time class type enumeration in JS - now that was useful.