Controls v HTML

[ThatsIT.net.au]

I come from a classic asp background, but have started using ASP.NET about
12 months ago, but I'm still not sure about the pros and cons of using
controls v HTML spat out from code as you would in classic asp. I have also
been using System.Web.UI.ICallbackEventHandler to send data to the server
and back without using controls.

What I want to know is the pros and cons of each. To me you never have quite
the freedom using a control as you do manipulating html and spitting it out,
but it can be quicker using a control for more simple jobs.

what are the performance issues?

What have other classic asp users found to be best when using asp.net?

 

[darrel]

I come from a classic asp background, but have started using ASP.NET about

12 months ago, but I'm still not sure about the pros and cons of using
controls v HTML spat out from code as you would in classic asp. I have also
been using System.Web.UI.ICallbackEventHandler to send data to the server
and back without using controls.

The advantages of controls like DataGrid and the like is that it's simply
faster/easier to get data from your back end onto your front end.

The advantages of controls like repeaters and the like is that you can get
that 'ideal' separation of presentation on the front (.aspx) end with logic
on the back end (.vb/cs files)

The disadvantages of the built in web controls...ESPECIALLY in 1.1, was that
the HTML, for the most part, sucked. It wasn't very semantic and often
invalid.

So, I got in the habit of using a lot of stringwriters ala classic ASP.

I'm now trying ot break myself of that habit as I move into 2.0 ;o)

What I want to know is the pros and cons of each. To me you never have
quite the freedom using a control as you do manipulating html and spitting
it out, but it can be quicker using a control for more simple jobs.

that's pretty much it.

Even the 2.0 controls are somewhat limited. Ie, a datagrid is really easy to
set up to allow the viewing and editing of content from one table. But once
you start getting into manipulating data across tables via joins and the
like, then the datagrid becomes rather complex to deal with.

What have other classic asp users found to be best when using asp.net?

IMHO, if you are willing to embrace the entire concept of OOP development,
then do it, and go with ASP.net. If you prefer the ASP 'lifestyle' then
consider migrating to PHP, as that is closer in methedology.

-Darrel

 

[Guest]

I doubt there are any real performance issues, everything gets spit out to
the response output stream anyway, whether you do it "manually" or let a
control do it by responding to its Render method from the Page class.

I've seen developers coming from a classic ASP (and so did I) environment
who just refuse to accept progress and do everything the "old way". I would
suggest you change your mindset to the concept of ASP.NET controls - and even
consider writing some of your own CustomControls along the way.

If you run into a situation where you just absolutely cannot figure out how
to make the ASP.NET Controls on the Toolbox do what you need, you can always
fall back to building strings of HTML with a StringBuilder and attaching the
output HTML to a placeholder or HtmlGeneric("div") control's InnerHTML
property.

Peter

 

[ThatsIT.net.au]

The advantages of controls like DataGrid and the like is that it's simply
faster/easier to get data from your back end onto your front end.

The advantages of controls like repeaters and the like is that you can get
that 'ideal' separation of presentation on the front (.aspx) end with
logic on the back end (.vb/cs files)

The disadvantages of the built in web controls...ESPECIALLY in 1.1, was
that the HTML, for the most part, sucked. It wasn't very semantic and
often invalid.

So, I got in the habit of using a lot of stringwriters ala classic ASP.

I'm now trying ot break myself of that habit as I move into 2.0 ;o)

Same here. But sometimes it just easier to spit out html from script than
fiddle with a control for hours and find that you can't get it to do what
you want properly.

that's pretty much it.

Even the 2.0 controls are somewhat limited. Ie, a datagrid is really easy
to set up to allow the viewing and editing of content from one table. But
once you start getting into manipulating data across tables via joins and
the like, then the datagrid becomes rather complex to deal with.


IMHO, if you are willing to embrace the entire concept of OOP development,
then do it, and go with ASP.net. If you prefer the ASP 'lifestyle' then
consider migrating to PHP, as that is closer in methedology.

I have tried php, I found it messy and cumbersome.

There is a lot I like about ASP.NET. The main problem seems to be too many
choices and wasting time following the wrong choice for a few hours then
changing your approach, I guess this will improve with experience

 

[ThatsIT.net.au]

Yes I am trying to use controls where I can , but spit out html when it
needs that bit extra.

I have also been using System.Web.UI.ICallbackEventHandler to send data back
and forward to the server manually, this works very well, there no reload at
all, even Ajax gives a flicker here and there but using
System.Web.UI.ICallbackEventHandler there is absolutely no reload, but I
have found bugs such as you can not use the "i" as a variable in your loops,
it also dose not like functions that return Boolean values. I don't seem to
find much documentation on this approach or have I found anyone else that
uses it, I wonder if there is not any other bugs or problems with it.

 

[Kevin Spencer]

The answer really depends on what your career is. If you are a professional
developer, and plan to remain one, embrace and master object-oriented
programming, learn how to employ the power of OOP and good object-oriented
design and architecture patterns and practices, and expect to take a good
long time doing so. In the long run, you'll be much better off, write
software that is powerful, secure, easy to maintain and extend, and get much
more done in much less time.

If on the other hand, you are a hobbyist, it is entirely up to you whether
you want to go to all that trouble.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Phil H]

The answer really depends on what your career is. If you are a professional
developer, and plan to remain one, embrace and master object-oriented
programming, learn how to employ the power of OOP and good object-oriented
design and architecture patterns and practices, and expect to take a good
long time doing so. In the long run, you'll be much better off, write
software that is powerful, secure, easy to maintain and extend, and get much
more done in much less time.

If on the other hand, you are a hobbyist, it is entirely up to you whether
you want to go to all that trouble.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:http://www.miradyne.net









- Show quoted text -

I am inclined to agree with much of what has been said about embracing
ASP.NET I have never used ASP but one thing has stood out for me in
using ASP.NET is that it remains just as important to know HTML
thoroughly. Microsoft did not try to hide HTML from the developer with
ASP.NET rather they introduced a powerful set of tools for server-side
programming that communicates with the client in a W3C compliant
fashion but still supports traditional HTML in the source pages. Web
server controls, such as labels, hyperlinks and images are embedded
inside traditional tags but enable programmatic control of content
where needed. The two technologies complement one another very well.

As for migrating from ASP, even though I lack experience it seems
obvious to me that it is best left behind altogether and not to try
and "adapt" the new technology to the old, which will only obscure the
advantages of the newer methodologies.

 

[ThatsIT.net.au]

OOP is not the same as using controls.

I am a big believer in OOP. But I'm not sure that using controls is superior
to spitting out html. My query is not ASP v ASP.NET it is Controls v
spitting out html

 

[Mike Placentra II]

-Easier to reuse
Your next best option to reuse code that spits out dynamic HTML
would be to create a subscript. If you were to create a subscript that
does what the GridView control does, it would have more parameters
than would be worth dealing with.

-OOP benefits
What Kevin Spencer means is that you work with controls
programmatically in an OOP fashion. A control gives you events,
methods, and properties for interacting with it to make your code more
organized. A control is really an object, so using a control is using
OOP.

-IDE integration
You can work with controls graphically at design time, whether
they are user controls or server controls (assuming the server control
code has appropriate attributes and a ControlDesigner).

One who works primarily with ASP.net may take controls for granted,
but programmers of more procedural languages who understand ASP.net
controls sometimes envy you.

http://php.net/dotnet

(that's for the PHP programmers who haven't discovered the value of
those RAD frameworks for PHP)

-Michael Placentra II

 

[ThatsIT.net.au]

-Easier to reuse
Your next best option to reuse code that spits out dynamic HTML
would be to create a subscript. If you were to create a subscript that
does what the GridView control does, it would have more parameters
than would be worth dealing with.

yes I agree that using controls in some circumstances is a good thing, but
in many more complex cases it seems easier to use html. Using the
System.Web.UI.ICallbackEventHandler you can talk to the server from client
script and any html element can not do as any asp.net control.

-OOP benefits
What Kevin Spencer means is that you work with controls
programmatically in an OOP fashion. A control gives you events,
methods, and properties for interacting with it to make your code more
organized. A control is really an object, so using a control is using
OOP.

for that matter a html elements is a object,
What my point was, was that not using asp.net controls is not to say that
you are not using OOP. the making of classes and creating instances of them
is OOP.

-IDE integration
You can work with controls graphically at design time, whether
they are user controls or server controls (assuming the server control
code has appropriate attributes and a ControlDesigner).

One who works primarily with ASP.net may take controls for granted,
but programmers of more procedural languages who understand ASP.net
controls sometimes envy you.

http://php.net/dotnet

(that's for the PHP programmers who haven't discovered the value of
those RAD frameworks for PHP)

-Michael Placentra II

As for controls I think as I have stated above, they are good for many
occasions but can not be manipulated to the extent as you can with spitting
out html


One thing I would like to know is more about the pros and cons of using
System.Web.UI.ICallbackEventHandler to manually talk to the server from
JavaScript

 

[Mike Placentra II]

yes I agree that using controls in some circumstances is a good thing, but
in many more complex cases it seems easier to use html. Using the
System.Web.UI.ICallbackEventHandler you can talk to the server from client
script and any html element can not do as any asp.net control.

Are you saying that you can't manipulate the resulting HTML of
controls with JavaScript? You can retrieve the client ID from a server
control before it is outputted and inject it into your JavaScript, and
you would be able to work with that if you have some AJAXing to do.

Microsoft has an ASP.net AJAX framework ( http://asp.net/ajax/ ). This
really should cover most of your AJAX needs. I don't understand how or
why you want to compare controls with manual AJAX, because the
controls (other than Atlas controls or ASP.net AJAX controls or others
that do what you're talking about doing) don't replace your AJAX code.
You can create controls that use ICallbackEventHandler, and you can
manipulate the resulting code from controls with manual AJAX, but
other than that I don't see the point in this comparison.

for that matter a html elements is a object,

When you manipulate an HTML element (with runat="server") as an object
in your ASP.net code, it has become an (HTML) control anyway, so I
agree that HTML elements can be objects on the server side. But what
you're talking about is not utilizing the features of a control, but
rather generating the HTML yourself. OOP goes with controls because a
control is a class (look at a server controls tutorial). HTML elements
become an HtmlGenericControl. When you create a .ascx user control,
the class is created for you. When you type <asp:Literal ... />, the
instance of the control is created for you. You are also using OOP
when you work with them from your server code, I.E. Literal1.Text
= ...

What my point was, was that not using asp.net controls is not to say that
you are not using OOP. the making of classes and creating instances of them
is OOP.

People don't (shouldn't) just use OOP because it makes you cool to be
using it, it's good because it forces programmers to follow some rules
of a project, allows new design patterns, and keeps your code more
organized, among other benefits. Whether or not you can say you are
using OOP is not the issue. The reason OOP is worth pointing out here
is because you get to use it on the server when you use controls. You
aren't benefiting from saying that you are using HTML therefore DOM
therefore OOP, because that's not doing you any good on the server
side. It helps you a little in JavaScript, but using controls isn't
going to take that away from you.

As for controls I think as I have stated above, they are good for many
occasions but can not be manipulated to the extent as you can with spitting
out html

If you are the author of the control, you can manipulate the HTML
quite a bit. I can see what you mean if you want to create a section
of HTML that contains a large amount of unrelated things, but in that
case you should consider dividing it into more specific functions and
creating multiple controls.

One thing I would like to know is more about the pros and cons of using
System.Web.UI.ICallbackEventHandler to manually talk to the server from
JavaScript

As opposed to the lower level AJAX JavaScript things? Well, it saves
you a lot of time because you don't have to write more code for each
browsers' differences. It's more cumbersome than using an ASP.net AJAX
framework UpdatePanel control if all you're doing is updating a table,
though.

Good luck with everything,
-Michael Placentra II

 

[ThatsIT.net.au]

Are you saying that you can't manipulate the resulting HTML of
controls with JavaScript? You can retrieve the client ID from a server
control before it is outputted and inject it into your JavaScript, and
you would be able to work with that if you have some AJAXing to do.

It would be easier to just spit out html

Microsoft has an ASP.net AJAX framework ( http://asp.net/ajax/ ). This
really should cover most of your AJAX needs. I don't understand how or
why you want to compare controls with manual AJAX, because the
controls (other than Atlas controls or ASP.net AJAX controls or others
that do what you're talking about doing) don't replace your AJAX code.
You can create controls that use ICallbackEventHandler, and you can
manipulate the resulting code from controls with manual AJAX, but
other than that I don't see the point in this comparison.

Because you can have more control of what you are doing with manual
callbacks.

for instance when you click on a button you may want to make more controls
on the fly, that in return have events, than in return create more controls
on the fly that also have events. I tried to do this and found than after
asking for advice over and over on this group the best advice I got was to
spit out html to do it. From there I was able to use JavaScript events to do
manual callbacks. using asp.net controls I was only able to attach events to
the controls made on the fly after they were loaded and their events would
only fire the second time they were clicked.

When you manipulate an HTML element (with runat="server") as an object
in your ASP.net code, it has become an (HTML) control anyway, so I
agree that HTML elements can be objects on the server side. But what
you're talking about is not utilizing the features of a control, but
rather generating the HTML yourself. OOP goes with controls because a
control is a class (look at a server controls tutorial). HTML elements
become an HtmlGenericControl. When you create a .ascx user control,
the class is created for you. When you type <asp:Literal ... />, the
instance of the control is created for you. You are also using OOP
when you work with them from your server code, I.E. Literal1.Text
= ...

Each html element is a object with methods and properties there is little
difference there. but I think we are getting off topic, My point is that
controls don't always do as you want, sometimes there are very quick and do
the job well, some times you spend so much time fiddling with they to get
what you want, I find it better to create what you want by spitting html. I
tend to design my database well so that each table or group of tables
represents a object and following the relation ships of the database I can
navigate though my objects to get what data I need. For example a customer
object would represent a customer table in the DB. Each instance of the
object would be a record of that table, that customer record can in turn
call a invoice object that would represent a linked invoice table. This I
used to do in Classic ASP using COM+. To think that OOP is something new to
Classic ASP developers is not so, although not all asp developers may take
such a approach. To me this is the real Idea of OOP is to make each entity a
Object with properties and methods and collections. Properties usually
relate to the fields of the table the object represents, methods usually
change the the data and collections hold child objects that represent child
table records.

People don't (shouldn't) just use OOP because it makes you cool to be
using it, it's good because it forces programmers to follow some rules
of a project, allows new design patterns, and keeps your code more
organized, among other benefits. Whether or not you can say you are
using OOP is not the issue. The reason OOP is worth pointing out here
is because you get to use it on the server when you use controls. You
aren't benefiting from saying that you are using HTML therefore DOM
therefore OOP, because that's not doing you any good on the server
side. It helps you a little in JavaScript, but using controls isn't
going to take that away from you.

See above

If you are the author of the control, you can manipulate the HTML
quite a bit. I can see what you mean if you want to create a section
of HTML that contains a large amount of unrelated things, but in that
case you should consider dividing it into more specific functions and
creating multiple controls.

How the data is presented is just that presentation, using the asp.net
controls to connect strait to the database is fine, but to really follow OOP
principles I refer to my rant above, knowing the entities in your solution
and representing them as objects usually with a normalized relational
database as a backend is the real objecting of OOP and how you present the
data to the front end is not so important. Using a object to present data is
not what I would call OOP, I would call that using objects but not OOP.

As opposed to the lower level AJAX JavaScript things? Well, it saves
you a lot of time because you don't have to write more code for each
browsers' differences.

I atgree there

It's more cumbersome than using an ASP.net AJAX

framework UpdatePanel control if all you're doing is updating a table,
though.

Here I disagree, it really isn't so much to do, and making a web site Ajax
enabled is a bit of a hassle also.
I like to use manual callbacks but what I am worried about is some unknown
bugs or limitations as I can find so little info on the concept

 

[Mike Placentra II]

"[Writing manual callbacks] really isn't so much to do, and making a
web site Ajax enabled is a bit of a hassle also. I like to use manual
callbacks but what I am worried about is some unknown bugs or
limitations as I can find so little info on the concept"

I would not bother writing a callback for updating a table (refreshing
from a data source or inserting with a FormView) if I can do that with
pure drag-n-drop and property editing. Those opportunities to get
something done very quickly are the reasons I choose to use ASP.net
when I do.

When you can already recognize those instances where manual callbacks
are necessary, there shouldn't be an issue of Controls v HTML. I'm not
advocating using controls in all cases, but I'm trying to describe why
controls are useful so you can determine for yourself when they apply
to your situation.

Your original post and title say that you want information on when to
use controls versus when to use directly code-generated HTML with
manual callbacks, accounting for performance and similar crossover
experiences. You seem to have that already, would you like answers to
any more related questions?

-Michael Placentra II

 

[Kevin Spencer]

Each html element is a object with methods and properties there is little
difference there. but I think we are getting off topic, My point is that
controls don't always do as you want, sometimes there are very quick and
do the job well, some times you spend so much time fiddling with they to
get what you want, I find it better to create what you want by spitting
html. I tend to design my database well so that each table or group of
tables represents a object and following the relation ships of the
database I can navigate though my objects to get what data I need. For
example a customer object would represent a customer table in the DB. Each
instance of the object would be a record of that table, that customer
record can in turn call a invoice object that would represent a linked
invoice table. This I used to do in Classic ASP using COM+. To think that
OOP is something new to Classic ASP developers is not so, although not all
asp developers may take such a approach. To me this is the real Idea of
OOP is to make each entity a Object with properties and methods and
collections. Properties usually relate to the fields of the table the
object represents, methods usually change the the data and collections
hold child objects that represent child table records.

<snip>

First, you don't seem to understand the difference between
pseudo-object-oriented programming technology and true object-oriented
programming technology, and the difference is significant. For example, true
OOP employs inheritance, which is a powerful tool for obtaining code
maintainability and reusability. True OOP also includes encapsulation, which
enables objects to fully control access to their members. There are many
other aspects of OOP, the .Net platform, and managed code and languages that
make it extremely powerful and productivity-oriented.

In addition, there is more to ASP.Net than the programming platform it is
written on. ASP.Net has a structure that is very powerful and enhances
productivity immensely when it is fully-leveraged. This structure, and the
power of OOP come at a cost. It is not something one can easily or quickly
master. It requires an up-front investment of time in study and practice.
Such abstractions as the Provider Pattern and various other patterns and
practices can, over time, enable a developer to perform twice the work in
half the time, to produce solid, reusable, easily-maintainable software that
requires much less maintenance, and is much more reliable than software
written using classic ASP and COM.

These claims are not matters of speculation. They are supported by a large
volume of work which has been done by many developers using the technology
over a number of years, including my own. I have used ASP.Net since it first
emerged, in fact, since it was in its' initial version beta. And from my own
experience, it took me years to fully realize and leverage its' power. That
is not something which can be done by reading some Getting Started articles,
Quick Starts, and tutorials.

That said, a developer has to make a living. One has to produce something to
make a living. The art of programming entails a constant process of
compromise, between what can potentially be accomplished with unlimited time
and resources, and what can actually be done with limited time and
resources. I have never been able to create the perfect software, nor to
take advantage of every possible benefit available in a technology in doing
so, although I have learned to work as much more and sleep as much less as I
possibly can. The "fish or cut bait" moment looms ominously in every
project.

Most projects, and the prospect of learning many new technologies often
reminds me of an elephant that needs to be eaten. To think about eating the
entire elephant is highly likely to prevent one from taking the first bite.
But perfection is not something to be attained; it is something to be
approached. Regardless of whether or not it is impossible to eat an
elephant, it is certainly possible to begin to eat one. The process of
eating is simply an iterative process of taking one bite at a time. Taking a
single bite of anything is a trivial task.

In conclusion, my aim is not to discourage. The question here, of whether to
use Controls, or to simply output HTML, is not an ultimate issue. It may be
a pragmatic issue for the time being, depending on one's circumstances. In
other words, it is a decision to be made for the present situation, and need
not have any influence on future decisions. Each bite is taken in the time
frame of that bite. Each development decision is made in the time frame of
that project. A developer's technique evolves over time, as the developer
learns and practices the art.

So, if it seems inconvenient to use any or all of the ASP.Net suite of tools
and technologies (in this case), if one feels that it is necessary to forego
the employment of some seemingly intimidating (at the moment) process in the
interest of getting the current job done, this is what one must decide. That
decision may be for the best at any given time, and as a matter of practical
experience, it is a decision which we all must continue to make for just
about any project, for the length of our careers.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[ThatsIT.net.au]

<snip>

First, you don't seem to understand the difference between
pseudo-object-oriented programming technology and true object-oriented
programming technology, and the difference is significant. For example,
true OOP employs inheritance, which is a powerful tool for obtaining code
maintainability and reusability. True OOP also includes encapsulation,
which enables objects to fully control access to their members. There are
many other aspects of OOP, the .Net platform, and managed code and
languages that make it extremely powerful and productivity-oriented.

I have been developing with OOP for quite a long time, I am familiar with
inherited abstract and polymorphous.
I am familer with OOP in java ASP.NET and C++

In addition, there is more to ASP.Net than the programming platform it is
written on. ASP.Net has a structure that is very powerful and enhances
productivity immensely when it is fully-leveraged. This structure, and the
power of OOP come at a cost. It is not something one can easily or quickly
master. It requires an up-front investment of time in study and practice.
Such abstractions as the Provider Pattern and various other patterns and
practices can, over time, enable a developer to perform twice the work in
half the time, to produce solid, reusable, easily-maintainable software
that requires much less maintenance, and is much more reliable than
software written using classic ASP and COM.

It would seem to be new to you, but OOP is been around for longer than
Dot.Net and is not the relient on using controls as you seem to state in
your first post.

These claims are not matters of speculation. They are supported by a large
volume of work which has been done by many developers using the technology
over a number of years, including my own. I have used ASP.Net since it
first emerged, in fact, since it was in its' initial version beta. And
from my own experience, it took me years to fully realize and leverage
its' power. That is not something which can be done by reading some
Getting Started articles, Quick Starts, and tutorials.

That said, a developer has to make a living. One has to produce something
to make a living. The art of programming entails a constant process of
compromise, between what can potentially be accomplished with unlimited
time and resources, and what can actually be done with limited time and
resources. I have never been able to create the perfect software, nor to
take advantage of every possible benefit available in a technology in
doing so, although I have learned to work as much more and sleep as much
less as I possibly can. The "fish or cut bait" moment looms ominously in
every project.

Most projects, and the prospect of learning many new technologies often
reminds me of an elephant that needs to be eaten. To think about eating
the entire elephant is highly likely to prevent one from taking the first
bite. But perfection is not something to be attained; it is something to
be approached. Regardless of whether or not it is impossible to eat an
elephant, it is certainly possible to begin to eat one. The process of
eating is simply an iterative process of taking one bite at a time. Taking
a single bite of anything is a trivial task.

Well put

In conclusion, my aim is not to discourage. The question here, of whether
to use Controls, or to simply output HTML, is not an ultimate issue. It
may be a pragmatic issue for the time being, depending on one's
circumstances. In other words, it is a decision to be made for the present
situation, and need not have any influence on future decisions. Each bite
is taken in the time frame of that bite. Each development decision is made
in the time frame of that project. A developer's technique evolves over
time, as the developer learns and practices the art.

So, if it seems inconvenient to use any or all of the ASP.Net suite of
tools and technologies (in this case), if one feels that it is necessary
to forego the employment of some seemingly intimidating (at the moment)
process in the interest of getting the current job done, this is what one
must decide. That decision may be for the best at any given time, and as a
matter of practical experience, it is a decision which we all must
continue to make for just about any project, for the length of our
careers.

I hardly see controls as intimidating, but clumsy, like many attempts at
making things easier, they make themselves less flexible.

 

[Kevin Spencer]

I hardly see controls as intimidating, but clumsy, like many attempts at
making things easier, they make themselves less flexible.

<snip>

Whatever your perception of ASP.Net Controls is, it is due to your
unfamiliarity with them, and with your unfamiliarity with the ASP.Net
programming paradigm. When used correctly, ASP.Net Controls do whatever you
want them to do, and very well.

Remember that ASP.Net Controls are not confined to the built-in set of
WebControls and HtmlControls that comes with the Framework, nor are they
limited to those plus User Controls. In fact, the ASP.Net platform is
designed with the idea in mind that you can and will create custom Controls
when needed. HTML elements in a web page are not necessarily unrelated to
one another, especially when they are interactive. They are more like parts
that can be combined to perform various tasks, much like the various
combinations of carpentry construction materials are combined to build
various types of buildings, and rooms in buildings.

A server-side web application takes this a step further, in that there are
also "parts" on the server that provide business logic, and "parts" that
provide a user interface in the form of an HTML document. These business
logic and UI logic parts comprise the actual application, while the HTML
document, with the sum of its parts, comprises a UI that communicates
transparently with the actual application on the server.

Remember that your original question was with regards to whether or not it
was better to employ Controls, or just "spit out HTML." Well, that is
exactly what Controls do. However, they are object-oriented, encapsulated,
and modular, which makes them superior to any procedural and/or non-modular
way of creating the various fragments of HTML markup that make up a
document.

In essence, System.Web.UI.Page is a Control that represents an HTML
document. It modelled after the HTML document object model, in that, like an
HTML document, it is a container for other Controls, just as an HTML
document is a container for other HTML elements. The ASP.Net object model
leverages the organizational and modular characteristic of the HTML document
object model to provide a similar server-side set of objects that are
self-contained and self-rendering.

Since the HTML document object model is not simply raw text, but a set of
encapsulated elements with various properties and functionality, it is best
to create server-side objects that do not treat the HTML in the page as raw
text, but as a set of encapsulated elements with various properties and
functionality. Yes, it is true that it is raw text that is interpreted by
the browser to render these elements, but in fact, even the browser simply
parses the text and builds an in-memory object hierarchy to work with. Once
the raw text has been parsed, it is ignored by the browser. ASP.Net hides
the raw text from the developer, giving the developer instead an object
model that closely resembles the resultant client-side model.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[ThatsIT.net.au]

<snip>

Whatever your perception of ASP.Net Controls is, it is due to your
unfamiliarity with them, and with your unfamiliarity with the ASP.Net
programming paradigm. When used correctly, ASP.Net Controls do whatever
you want them to do, and very well.

no they don't, I think the tasks you are doing may be very basic.

In some occasions you may not even know the amount of data, number of
fields, data types you will need to display, controls can not handle this
well and present the data formatted correctly on the fly. Some times
condition statements may be needed to decide when to display, make a
calculation or separate the data from one column to 2. Controls can not
handle this well. IOn these cases it is far more productive to use html

 

[Kevin Spencer]

no they don't, I think the tasks you are doing may be very basic.

<snip>

I've been doing ASP.Net since the first beta version came out, and I've done
just about everything with ASP.Net that can be done with it, except for
Ajax. I've built a large number of web sites with it, Controls that interact
with SWFs that interact with Web Services that I've built, HttpHandlers for
a variety of purposes, member- and role-based portals that have database
back-ends, database interfaces, Controls that render images and charts,
Controls that use XSLT to create HTML from serialized sets of custom
classes, Controls that render JavaScript, so much stuff that I don't
remember some of it.

Over the years, I've learned to use Controls more, not less, by experience
and research. I have a large personal library of custom Controls that I have
previously built, and employ in projects that come up.

That said, you don't have to believe me. The information I've provided was
for your benefit, not mine. Someday it may be useful to you, if not today.

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[ThatsIT.net.au]

<snip>

I've been doing ASP.Net since the first beta version came out, and I've
done just about everything with ASP.Net that can be done with it, except
for Ajax. I've built a large number of web sites with it, Controls that
interact with SWFs that interact with Web Services that I've built,
HttpHandlers for a variety of purposes, member- and role-based portals
that have database back-ends, database interfaces, Controls that render
images and charts, Controls that use XSLT to create HTML from serialized
sets of custom classes, Controls that render JavaScript, so much stuff
that I don't remember some of it.

Over the years, I've learned to use Controls more, not less, by experience
and research. I have a large personal library of custom Controls that I
have previously built, and employ in projects that come up.

That said, you don't have to believe me. The information I've provided was
for your benefit, not mine. Someday it may be useful to you, if not today.

I believe you are very capable, but I don't agree that controls are as
flexible as spitting out html. You did not comment on the scenarios I put
forward, remembering that the ability to do something is not the point, it
is if it is practice to do so.

"In some occasions you may not even know the amount of data, number of
fields, data types you will need to display, controls can not handle this
well and present the data formatted correctly on the fly. Some times
condition statements may be needed to decide when to display, make a
calculation or separate the data from one column to 2. Controls can not
handle this well. In these cases it is far more productive to use html"

 

[Mike Placentra II]

... You [Kevin Spencer] did not comment...
"In some occasions you may not even know the amount of data, number of
fields, data types you will need to display, controls can not handle this
well and present the data formatted correctly on the fly. Some times
condition statements may be needed to decide when to display, make a
calculation or separate the data from one column to 2. Controls can not
handle this well. In these cases it is far more productive to use html"

/ThatsIT.net.au/, I'm not convinced that you realize what a control
is. You can do (just about) anything you can do in your regular code
in a control, unless your regular code is extremely messy and it would
not worth getting your variables and data into the control. Again, I'm
not advocating the use of controls in all situations; but I feel that
you are making some control out there feel really bad about itself.

Here's a short, quick example (that I haven't tested) of how a server
control can work. It should be clear that you can do any sort of logic
with this. Of course, this does not demonstrate every possible thing a
control can do. You can even add JavaScript includes into the <head>
of the document and things like that. In fact, controls can handle
their postback, so you can put form elements in there (or paginate the
data in the below example, as is the case with GridView and several
other controls) and even do AJAX things. Please don't criticize my
failure to use a NameSpace, validate public properties, etc. This is
just a short, easy to read example.

-------------------------------------------------

Imports System.ComponentModel

<Description("Demonstrates that a control can do logic."), _
ToolboxData("<{0}:Example runat=server></{0}:Example>")> _
Public Class ExampleControl : Inherits Control
Public ShowAnonymous As Boolean = True
Public Data As DataTable
Public MaxColItems As Int32 = 50

Protected Overrides Sub Render(ByVal writer As HtmlTextWriter)
writer.Write("<div style='float:left;clear:none'>")

For i As Int32 = 0 To Data.Rows.Count
If i = MaxColItems Then
writer.Write("</div><div style='float:left;clear:none'>")
If Data.Rows(i).Item("is_anonymous") = "yep" Then
If ShowAnonymous Then
writer.Write(Data.Rows(i).Item("name"))
End If
Else
writer.Write(Data.Rows(i).Item("name"))
End If

writer.Write("<br />")
End If
Next

writer.Write("</div>")
End Sub
End Class