i'm trying to decide if i should use "ASP server controls", or "HTML 

server controls", or just carry on with the same techniques that served me 

fine with the old ASP. 



i like to write web apps using bona fide web technologies, an ASCII text 

editor, and no microsoft wizards. bona fide web technologies include html, 

css, and javascript on the client, and (for the purposes of this 

discussion) C# and aspx files on the server. 



it seems to me that "ASP server controls" do nothing but obfuscate what is 

really happening. as far as i can tell they are nothing but microsoft 

wizards - all they do is write the HTML and javascript FOR you. they are 

not a real technology, only a crutch, and furthermore, one that is 

designed specifically for people who come from a Windows SDK background, 

not a web background. people who don't want to have to learn how HTML and 

HTTP really work (e.g. how to maintain state with an HTML Form all by 

yourself).



there is no such thing as an "onServerClick" event! a click can only 

happen on the client. this kind of thing only confuses the boundaries 

between server and client. that is not a convenience, it is a 

mystification of the process. 



does anyone like these new "server controls"? which type do you prefer, 

ASPServerControls or HTMLServerControls? why? why not just carry on 

writing the code yourself? i'm hoping to either be convinced of their 

superior merits, or be validated in my contempt. or do i just hate what i 

do not understand? 



thanks!



-dmitri

have you try to do some SDk version of asp.net coding?

you can use notepad.







-----Original Message-----

From: dmitri kalmar [mailto:dmitrikal@y...]

Sent: Thursday, December 20, 2001 9:42 AM

To: ASP+

Subject: [aspx] is it just me or do "server controls" just SUCK?





i'm trying to decide if i should use "ASP server controls", or "HTML 

server controls", or just carry on with the same techniques that served me 

fine with the old ASP. 



i like to write web apps using bona fide web technologies, an ASCII text 

editor, and no microsoft wizards. bona fide web technologies include html, 

css, and javascript on the client, and (for the purposes of this 

discussion) C# and aspx files on the server. 



it seems to me that "ASP server controls" do nothing but obfuscate what is 

really happening. as far as i can tell they are nothing but microsoft 

wizards - all they do is write the HTML and javascript FOR you. they are 

not a real technology, only a crutch, and furthermore, one that is 

designed specifically for people who come from a Windows SDK background, 

not a web background. people who don't want to have to learn how HTML and 

HTTP really work (e.g. how to maintain state with an HTML Form all by 

yourself).



there is no such thing as an "onServerClick" event! a click can only 

happen on the client. this kind of thing only confuses the boundaries 

between server and client. that is not a convenience, it is a 

mystification of the process. 



does anyone like these new "server controls"? which type do you prefer, 

ASPServerControls or HTMLServerControls? why? why not just carry on 

writing the code yourself? i'm hoping to either be convinced of their 

superior merits, or be validated in my contempt. or do i just hate what i 

do not understand? 



thanks!



-dmitri

DK:



as one who also prefers non-VS.NET editors and is well-versed in HTML and

client-script, I can understand your initial frustration with the ASP Server

Controls. However, I find the ASP namespace *very* useful. I also think you

are making some assumptions that are not quite correct.  Possibly it is

these assumptions that are contributing to your dislike of the ASP namespace

controls.



ABOUT THE ASP NAMESPACE CONTROLS

First, yes, they are designed with 'windows-like' attributes. This is a

great help to those who come from the Windows Forms background, but can be a

frustration for HTML geeks.  No way around it, but once you get used to the

new attributes, it's not at all bad.



For example, I rather like knowing that both the Label and the Textbox (span

and input in the HTML world) have a Text property. Instead of remembering

span.InnerHTml and Input.Value, i can just write label.Text and

TextBox.Text. Also, eing able to add a TextMode attribute to the Textbox

means that I can use just one control for TextArea, Password and standard

inputs.  Much simpler for me.



And the new CheckBoxList and RadioButtonList seem much smarter to me.

Including the ability to easily perform databinding against these controls

using typical arrays or even info from XML or relational database tables.



Finally, the Validation controls rock, IHMO.  This is a valuable set of

controls that I am now happy to be able to sue instead of writing my own

client and server code and making sure it works properly in all browsers and

in browsers that have clinet-scripting turned off for security reasons.



ABOUT ONSERVERCLICK VS ONCLICK

While you're correct that the ASP namespace has no onserver click, I think

you've missed the point there. The ASP controls have no ONSERVERCLICK

because *all clicks* happen on the server!  The HTML namespace is the only

set that supports both client-side (OnClick) and server-side (OnServerClick)

event-handling.  The ASP namespace only handles server-side events and uses

the OnClick attribute to link the control to the event code on the server.

I find this pretty simpelt to deal with, but I do miss the ability to link

into a client-side event like I can with the HTML namespace.



ABOUT THE JAVASCRIPT CODE

Yes, some of the ASP namespace controls burp out their own client code.  If

you're very particular about the code that gets shipped to the client,

you'll be bummed.  I am not so picky.  If it works - bingo.  Of course,

using the ASP namespace does not prevent us from writing all the client-side

code we wish.  I just choose to limit mine since I ma doing mostly

Internet-based apps where there could be lots of browser types hitting the

page. this makes my life easier.



MIX AND MATCH WORKS GREAT, TOO

Another thing I like about the framework is that you can easily mix and

match the HTML and ASP namespaces without worries.  often I'll use spans,

divs, and some other form controls along with the ASP validation controls or

the calendar, grid ot list controls all in the same form.



ROLL YOUR OWN

Lastly, I find the ability to use the controls base class to create my own

custom controls a real help.  I can create my own HTML-like controls that

behave a lot like the ASP namespace controls, but have attributes that I

recognize from HTML days.  I can also control the exact client-code that

gets spit out into the browser space.



All in all, i find the new environment much more robust, more reliable, and

more flexible.  I can't remember the last time I build a web page that

*didn't* use at least one of the new ASP namespace controls!



Just one mans' opinion



MCA







-----Original Message-----

From: dmitri kalmar [mailto:dmitrikal@y...]

Sent: Thursday, December 20, 2001 4:42 PM

To: ASP+

Subject: [aspx] is it just me or do "server controls" just SUCK?





i'm trying to decide if i should use "ASP server controls", or "HTML

server controls", or just carry on with the same techniques that served me

fine with the old ASP.



i like to write web apps using bona fide web technologies, an ASCII text

editor, and no microsoft wizards. bona fide web technologies include html,

css, and javascript on the client, and (for the purposes of this

discussion) C# and aspx files on the server.



it seems to me that "ASP server controls" do nothing but obfuscate what is

really happening. as far as i can tell they are nothing but microsoft

wizards - all they do is write the HTML and javascript FOR you. they are

not a real technology, only a crutch, and furthermore, one that is

designed specifically for people who come from a Windows SDK background,

not a web background. people who don't want to have to learn how HTML and

HTTP really work (e.g. how to maintain state with an HTML Form all by

yourself).



there is no such thing as an "onServerClick" event! a click can only

happen on the client. this kind of thing only confuses the boundaries

between server and client. that is not a convenience, it is a

mystification of the process.



does anyone like these new "server controls"? which type do you prefer,

ASPServerControls or HTMLServerControls? why? why not just carry on

writing the code yourself? i'm hoping to either be convinced of their

superior merits, or be validated in my contempt. or do i just hate what i

do not understand?



thanks!



-dmitri

Dmitri,



>i like to write web apps using bona fide web technologies, an ASCII

text 

>editor, and no microsoft wizards.



Me too! I use notepad all the time!



>it seems to me that "ASP server controls" do nothing but obfuscate what

is 

>really happening. as far as i can tell they are nothing but microsoft 

>wizards - all they do is write the HTML and javascript FOR you. they

are 

>not a real technology, only a crutch, and furthermore, one that is 

>designed specifically for people who come from a Windows SDK

background, 

>not a web background. people who don't want to have to learn how HTML

and 

>HTTP really work (e.g. how to maintain state with an HTML Form all by 

>yourself).



Well, you are correct in saying that server controls write HTML and

Javascript for you. As for your other points, Microsoft is not trying to

fool everyone by telling them that server controls are magic. They

readily admit and inform you that they emit the appropriate HTML for the

client's browser. No one (Microsoft included) is saying that you

shouldn't understand HTML, Javascript, etc. They are simply saying you

can develop ASP.NET pages without having to type all of the HTML and

Javascript - a very powerful capability for *most* people. Not everyone

wants to spend the time (time = money) to type everything themselves and

reinvent the functionality that is "baked" into ASP.NET server controls

and the ASP.NET Framework. If you do, then that's ok because Microsoft

is not saying or making you use server controls. As with any technology,

those who truly understand how it works behind the scenes will be better

developers, architects, etc. 



>there is no such thing as an "onServerClick" event! a click can only 

>happen on the client. this kind of thing only confuses the boundaries 

>between server and client. that is not a convenience, it is a 

>mystification of the process. 



Mystification? Not if you understand the difference between OnClick or

OnServerClick? Or the reason that OnServerClick exists? Basically,

OnServerClick exists because OnClick is an event that is already

recognized by HTML and Javascript as the name of an event that occurs on

the client side. So, if you need to have a client side click event and

an event that fires on the server side (i.e. the user has clicked a

submit button on the client and as a result you want code to execute on

the server) then you would use both the OnClick event and the

OnServerClick event. I'm not confused by this terminology and I don't

think anyone who has prior web programming experience would be confused

either - once they have *actually* read about ASP.NET (Server controls,

etc.) and how it works.



>does anyone like these new "server controls"? 



I personally love ASP.NET and the new ASP.NET server controls.



>which type do you prefer, 

>ASPServerControls or HTMLServerControls? why? 



It's not really a decision that should be made based on preference. They

each server a different purpose and there are some Web Controls that are

not available as HTML Controls. One thing I don't think you understand

is that HTML controls are really just plain old HTML wrapped in a

programmable package. So, an HTML control has all of the properties of

its equivalent HTML tag - nothing more, nothing less. This is great

because I can interact with the control (using it's ID) in my code. The

Web Controls provide me with controls like the DataGrid, Panel,

Repeater, DataList, etc. which don't have a counterpart HTML control.

So, if I want a functionality rich control that is not currently

available using an HTML tag then I have to use the Web Control. If I

just want a programmable HTML tag then I use the HTML controls.



>why not just carry on 

>writing the code yourself? 



Because it's expensive and my clients/boss want me to write code the

most efficient way possible. Yes, they want good code and I don't think

I have to give that up just because I am using ASP.NET Web Controls. How

many lines would it take you to build a Table display that had sorting,

paging, and inline editing capabilities? I can use the DataGrid Web

Control and create this functionality in approx. 125 lines (HTML/Web

Controls and Code included). I think you should spend some time using

ASP.NET before you complain. Have you built a sample application? Have

you rewritten a classic ASP application using ASP.NET? If you do these

things, I am confident you will see why ASP.NET is superior in many

ways. 



>i'm hoping to either be convinced of their 

>superior merits, or be validated in my contempt. or do i just hate what

i 

>do not understand? 



Hopefully, I have informed you of some things about ASP.NET that were

not aware of. I think you do need to have a better understanding of

ASP.NET before you knock it.

 



Regards,

Alex - AspFriends.com Moderation Team

 

ASP.NET Tips/Examples: http://aspalliance.com/aldotnet

Regarding your statements and questions:



(I will go from the most general and get specific)



1. All of today's active content web (both clients and servers) are

still working in the way things worked 5 years ago (have you ever

thought about it???): Clients are still requesting GET or POST requests,

servers are still using the good old CGI to gain user data persistence,

no matter if you call it CGI, ASP, JSP, SOAP, ASP.NET or anything else,

so from the tech point of view you can relax: nothing new should you

expect.



2. On the other hand, the basic CGI and GET/POST are a bit raw, mainly

because most of the data is most of the time internally handled (like

session cookies for exmaple)



3. The situation led to some very advanced sofware models based on the

current technology, but wrapping a "smart" envelop around the

technology, for the developer to have easier life developing complex

application without the need to get too TECHIE.



4. Some of the technology envelops are better known today as: ASP, JSP,

EJB, ASP.NET, CGI, XML-HTTP, SOAP, FrontPage server-extensions, ISAPI

filters, .NET httpHandler, etc.



5. Regarding ASP.NET: In doing what they did (applying the workframe the

way MS applied) microsoft brought software developers the greates

abstraction of the technology layer ever done yet.



6. Enabling the framework's users to ignore the complex network

interaction invloving http requests and responds and concentrate on the

higher levels of interaction (user interactions, business logic,

data-handling) was one of the most giagantic leaps towards bringing the

network vision into every house, and into every organization.



7. Regarding ASP.NET webcontrols: all that microsoft did was exposing

the object model to you. To my point-of-view, not only will this bring

good, but I think people don't just understand yet how powerful these

little HTML text emitter are. I think that the fact that all they do is

emit text is not a drawback, but rather their BIGGEST ADVANTAGE.



8. Web controls (very well explained in Wrox's "Professional ASP.NET")

are not a trivial subject, but rather an implementation of the

internals. I have searched for info about them, but have yet failed to

find, so you might just as well be a bit more patient, and the

explanations for all will come.



9. If you want to do something and do not succeed in doing it, maybe you

can tell us what you tried to do, what did you expect, and what went

wrong, because this is what people do here, not convincing people one or

another development suite is better than other. The way I see it, you

might have also misdesigned your application, so we might help you with

this as well.



10. Last thing: the Microsft corporation is the biggest company ever

existed on earth, and probably also the most influencing one, and in as

many aspects of our life we've never seen before. I know they have bugs

in their software, and so does the rest of the world, but I would

suggest you to be a bit more thorough before deciding that the new

web-development suit "just SUCK"



Best regards and have a great week,

Ziv.





-----Original Message-----

From: dmitri kalmar [mailto:dmitrikal@y...]

Sent: Thursday, December 20, 2001 6:42 PM

To: ASP+

Subject: [aspx] is it just me or do "server controls" just SUCK?





i'm trying to decide if i should use "ASP server controls", or "HTML

server controls", or just carry on with the same techniques that served

me

fine with the old ASP.



i like to write web apps using bona fide web technologies, an ASCII text



editor, and no microsoft wizards. bona fide web technologies include

html,

css, and javascript on the client, and (for the purposes of this

discussion) C# and aspx files on the server.



it seems to me that "ASP server controls" do nothing but obfuscate what

is

really happening. as far as i can tell they are nothing but microsoft

wizards - all they do is write the HTML and javascript FOR you. they are



not a real technology, only a crutch, and furthermore, one that is

designed specifically for people who come from a Windows SDK background,



not a web background. people who don't want to have to learn how HTML

and

HTTP really work (e.g. how to maintain state with an HTML Form all by

yourself).



there is no such thing as an "onServerClick" event! a click can only

happen on the client. this kind of thing only confuses the boundaries

between server and client. that is not a convenience, it is a

mystification of the process.



does anyone like these new "server controls"? which type do you prefer,

ASPServerControls or HTMLServerControls? why? why not just carry on

writing the code yourself? i'm hoping to either be convinced of their

superior merits, or be validated in my contempt. or do i just hate what

i

do not understand?



thanks!



-dmitri

I have to agree with Ziv...good analysis, reply.



The server controls that ASP.NET provides are in my opinon...awesome.  Do

they serve every purpose...no.  Do they make development easier...IMO, yes.

Do they make development faster...in my experience on a "real" (paying

Forutne 50 customer) application, we decreased development time versus

traditional ASP by roughly 40%.



If you want to use "bonafide" technologies, then stick to them.  You won't

gain the performance and ease of development by doing so, but feel free.  



Tim



-----Original Message-----

From: zivf@m... [mailto:zivf@m...] 

Sent: Sunday, December 23, 2001 1:24 AM

To: ASP+

Subject: [aspx] RE: is it just me or do "server controls" just SUCK?



Regarding your statements and questions:



(I will go from the most general and get specific)



1. All of today's active content web (both clients and servers) are

still working in the way things worked 5 years ago (have you ever

thought about it???): Clients are still requesting GET or POST requests,

servers are still using the good old CGI to gain user data persistence,

no matter if you call it CGI, ASP, JSP, SOAP, ASP.NET or anything else,

so from the tech point of view you can relax: nothing new should you

expect.



2. On the other hand, the basic CGI and GET/POST are a bit raw, mainly

because most of the data is most of the time internally handled (like

session cookies for exmaple)



3. The situation led to some very advanced sofware models based on the

current technology, but wrapping a "smart" envelop around the

technology, for the developer to have easier life developing complex

application without the need to get too TECHIE.



4. Some of the technology envelops are better known today as: ASP, JSP,

EJB, ASP.NET, CGI, XML-HTTP, SOAP, FrontPage server-extensions, ISAPI

filters, .NET httpHandler, etc.



5. Regarding ASP.NET: In doing what they did (applying the workframe the

way MS applied) microsoft brought software developers the greates

abstraction of the technology layer ever done yet. 



6. Enabling the framework's users to ignore the complex network

interaction invloving http requests and responds and concentrate on the

higher levels of interaction (user interactions, business logic,

data-handling) was one of the most giagantic leaps towards bringing the

network vision into every house, and into every organization.



7. Regarding ASP.NET webcontrols: all that microsoft did was exposing

the object model to you. To my point-of-view, not only will this bring

good, but I think people don't just understand yet how powerful these

little HTML text emitter are. I think that the fact that all they do is

emit text is not a drawback, but rather their BIGGEST ADVANTAGE.



8. Web controls (very well explained in Wrox's "Professional ASP.NET")

are not a trivial subject, but rather an implementation of the

internals. I have searched for info about them, but have yet failed to

find, so you might just as well be a bit more patient, and the

explanations for all will come.



9. If you want to do something and do not succeed in doing it, maybe you

can tell us what you tried to do, what did you expect, and what went

wrong, because this is what people do here, not convincing people one or

another development suite is better than other. The way I see it, you

might have also misdesigned your application, so we might help you with

this as well.



10. Last thing: the Microsft corporation is the biggest company ever

existed on earth, and probably also the most influencing one, and in as

many aspects of our life we've never seen before. I know they have bugs

in their software, and so does the rest of the world, but I would

suggest you to be a bit more thorough before deciding that the new

web-development suit "just SUCK"



Best regards and have a great week,

Ziv.





-----Original Message-----

From: dmitri kalmar [mailto:dmitrikal@y...]

Sent: Thursday, December 20, 2001 6:42 PM

To: ASP+

Subject: [aspx] is it just me or do "server controls" just SUCK?





i'm trying to decide if i should use "ASP server controls", or "HTML 

server controls", or just carry on with the same techniques that served

me 

fine with the old ASP. 



i like to write web apps using bona fide web technologies, an ASCII text



editor, and no microsoft wizards. bona fide web technologies include

html, 

css, and javascript on the client, and (for the purposes of this 

discussion) C# and aspx files on the server. 



it seems to me that "ASP server controls" do nothing but obfuscate what

is 

really happening. as far as i can tell they are nothing but microsoft 

wizards - all they do is write the HTML and javascript FOR you. they are



not a real technology, only a crutch, and furthermore, one that is 

designed specifically for people who come from a Windows SDK background,



not a web background. people who don't want to have to learn how HTML

and 

HTTP really work (e.g. how to maintain state with an HTML Form all by 

yourself).



there is no such thing as an "onServerClick" event! a click can only 

happen on the client. this kind of thing only confuses the boundaries 

between server and client. that is not a convenience, it is a 

mystification of the process. 



does anyone like these new "server controls"? which type do you prefer, 

ASPServerControls or HTMLServerControls? why? why not just carry on 

writing the code yourself? i'm hoping to either be convinced of their 

superior merits, or be validated in my contempt. or do i just hate what

i 

do not understand? 



thanks!



-dmitri