ASP.Net Book without builtin control use?

[mjpmsa]

Hello,

I've been using the O'Reilly book _Programming ASP.Net_ to learn
ASP.Net, but it frustrates me because all of the examples seem to use
the built in form controls. I write good, standards compliant HTML, I
understand forms, I write Javascript, and in short, I don't want to use
the canned form things necessarily.

Can anyone suggest a reference or tutorial in a book or on the web that
just gets to the meat of the application server? Things like: what is
all the ASP.Net syntax (I know C#, I mean the things you will put in
the web page itself), how do you do simple tasks like handling a form
post, etc?

Thanks,
Matt

[Joerg Jooss]

mj****@yahoo.com wrote:

Hello,

I've been using the O'Reilly book _Programming ASP.Net_ to learn
ASP.Net, but it frustrates me because all of the examples seem to use
the built in form controls. I write good, standards compliant HTML, I
understand forms, I write Javascript, and in short, I don't want to
use the canned form things necessarily.

Actually, a ready-to-use library of powerful web controls was supposed
to be one of the major benefits of ASP.NET... why reinvent the wheel by
reimplementing core framework functionality? Yes, ASP.NET's rendered
HTML isn't really that good, but that should be remedied with ASP.NET
2.0.

Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Michel de Becdelièvre]

>> I've been using the O'Reilly book _Programming ASP.Net_ to learn

ASP.Net, but it frustrates me because all of the examples seem to use
the built in form controls. I write good, standards compliant HTML, I
understand forms, I write Javascript, and in short, I don't want to
use the canned form things necessarily.

Actually, a ready-to-use library of powerful web controls was supposed
to be one of the major benefits of ASP.NET... why reinvent the wheel by
reimplementing core framework functionality? Yes, ASP.NET's rendered
HTML isn't really that good, but that should be remedied with ASP.NET
2.0.

Except when the added value is nil. I *do* like DataGrid, Repeater and
other really powerfull controls, but I just hate Label, ListBox, Literal : I
like to know what I'm doing, and I do not code for "IE only".

Luckilly we do not need to reimplement HTML controls, we can use the
System.Web.UI.HtmlControls controls for pure HTML work, and DOMValidators
for non IE6 validation.

[mjpmsa]

It bothers me that client side form elements are considered "core
framework functionality". It may indeed be that asp:button, etc are
the best way to do things, but I haven't found any serious discussion
of the reasons for or against. I know from my experience with
ColdFusion that the built in controls often are not very good.

As to why reinvent the wheel...it is because it would be easier for me
not to have to use them. Even from simple examples, I noticed that
ASP.Net uses the <font> tag in Firefox instead of <style>.

[mjpmsa]

Thank you, I will look at those controls.

[Joerg Jooss]

Michel de Becdelièvre wrote:

I've been using the O'Reilly book _Programming ASP.Net_ to learn
ASP.Net, but it frustrates me because all of the examples seem to

use >> the built in form controls. I write good, standards compliant
HTML, I >> understand forms, I write Javascript, and in short, I
don't want to >> use the canned form things necessarily.

Actually, a ready-to-use library of powerful web controls was
supposed to be one of the major benefits of ASP.NET... why reinvent
the wheel by reimplementing core framework functionality? Yes,
ASP.NET's rendered HTML isn't really that good, but that should be
remedied with ASP.NET 2.0.

Except when the added value is nil. I do like DataGrid, Repeater
and other really powerfull controls, but I just hate Label, ListBox,
Literal : I like to know what I'm doing, and I do not code for "IE
only".

What you're missing is the fact the these controls are meant to
abstract from the actual HTML they produce. This enforces uniform HTML
rendering at the component level, which is a good thing for large scale
development.

The downside of this is that if the rendererd HTML is not satisfactory
for whatever reason, and you cannot easily override the rendering
logic, you're pretty much screwed.

At the end of the day, you need to decide between a lightweight
approach (with a lot of explicit HTML) and a heavyweight approach (with
lots of powerful controls). The same is true for similar technologies
like JSP Tag libraries.
Cheers,
--
http://www.joergjooss.de
mailto:ne********@joergjooss.de

[Michel de Becdelièvre]

"Joerg Jooss" <ne********@joergjooss.de> a écrit dans le message de news:
xn****************@msnews.microsoft.com...

Michel de Becdelièvre wrote:

Except when the added value is nil. I do like DataGrid, Repeater
and other really powerfull controls, but I just hate Label, ListBox,
Literal : I like to know what I'm doing, and I do not code for "IE
only".

What you're missing is the fact the these controls are meant to
abstract from the actual HTML they produce. This enforces uniform HTML
rendering at the component level, which is a good thing for large scale
development.

Indeed, I want to do HTML, unless there is a big added value to use
another rendering model.

This is the case for a number of controls, such as DataGrid, Reapeater,
Validators (pity they are IE only - we are lucky that DOMValidators exists).

ascx files are also a big plus for behaviour standardisation, as are
probably master pages and partial classes (I only do 1.1 so far, I never
tested them).

In my experience, what you are missing with the "high level" controls is
good quality standard rendering and fine grained control on position in
anything but the simplest relative positioning scenarios.

You are also missing the use of external CSS sheets, since you do not
really control the rendering (much to many things end up "inline") , and
this can be a pain to assure uniform look of a site. These CSS sheets can
also cut on the bandwidth requirements of a site, since they are often
cached.

So I avoid System.Web.UI.WebControls in favour of
System.Web.UI.HtmlControls unless there is a big payback, which is the
mostly case for big complex objects, but to each his own : I like .Net
because it supports different styles well enough, I do not have this "we
know better than you how you SHOULD program" feeling that I get with Java.