runat=server mistique

  • Thread starter Thread starter Jay
  • Start date Start date
J

Jay

Where is there a good article/description on why everything is runat=server.
I just can't seem to grasp why ALL tags (even table tags) are runat server
in dotnet.

Thank You
 
This attribute just tells ASP.NET to create this control server side when
the page is called, allowing to access this control programmatically.

The control is then rendered client side you may have done programmatically
server side (such as colors or whatever else).

Patrice
 
I understand what you are saying but why? What is the advantage. In
classic asp, I used to generate tags to the client from the server. What is
the difference? I just don't seem to grasp the advantage. The control
ultimately is rendered by the client so what is the difference? See, I'm an
instructor and I need to know the nuts and bolts. Thank You!
 
Hey Jay,

My guess is also that they're trying to train us early for some
hopeful/planned day when there is an option where some ASP may be handled
client-side (or some other place not yet dreamed). If not, it seems
redundant to have to explicitly indicate that controls are handled
server-side when they are already by definition are server-side.

- John
 
This way you have automatically server side objects that are modelling the
"widgets" you'll finally have client side (the basic idea is to create
server side something "similar" to the client side "document" objet).

You can then handle typed controls, get intellisense, type safety,
viewstate, value persistance, design time support and so on. This is nothing
else than a whole infrastructure whose ultimate goal is to create the
underlying HTML (or even whatever else a client such as a mobile phone could
use) in an object oriented manner rather than to spit out directly HTML code
(you can of course till do this with ASP.NET), making creating web forms
similar to creating windows forms.

Don't know the exact reason but at first sight it looks to me quite simple
and consistent to have just to check the runat=server attribute when the
page is loaded.
For plain "HTML" tags you have the choice (depends if you need of rnot to
handle the tag server side).

Patrice

--
 
Jay said:
Where is there a good article/description on why everything is runat=server.
I just can't seem to grasp why ALL tags (even table tags) are runat server
in dotnet.

Thank You
Click to expand...

The .aspx file is parsed by ASP.NET on it's first access. The parsing
engine basically creates a C# (or VB.NET) source file that gets compiled
into an assembly based on the contents of the .aspx file.

The code in that assembly basically has calls to Response.Write() for
the parts of the .aspx file that are *not* in a runat="server" tag. It
might not be actual Response.Write() calls, but something with a similar
effect.

The runat="server" tags get parsed into ASP.NET server controls that you
can manipulate in your code-behind.

It boils down to tags that do not have the runat="server" attribute are
sent to the client verbatim. Tags that do have it can be manipulated on
the server before rendering on the client.
 
I don't have any good links handy, but will try to explain in a
nutshell.

When you specify the "runat=server" attribute in an HTML tag, it
signifies to ASP.Net that a server side representation of that display
element needs to be created. In your aspx code, you'll have access to
these display elements and change their properties programatically.
There are also convenient data-binding capabilities which can be
applied to these display elements when they're managed by the server.

But not ALL tags need to run at the server. Only those which you wish
to access programatically.

Static html code for building tables that doesn't change shouldn't be
run at server, in fact, by using server controls for static html tags,
you'll only be slowing down the application.

Are you using Visual Studio .Net btw?
 
Not everything in ASP.Net is runat=server. Only Server Controls are. You can
certainly use plain vanilla HTML in your ASP.Net pages. The biggest
differences between ASP.Net and Classic ASP is the fact that ASP.Net is
object-oriented, and that ASP.Net is much more powerful than Classic ASP.

There are several reasons why object-oriented programming is better than
procedural programming, espcially with regards to web applications. If you
have ever had to maintain some of the old procedural ASP apps, you would
realize that a procedural program, when it reaches a certain size and
complexity, particularly if the developer was not that experienced, is a
bear to maintain. OOP brings organization and encapsulation (as well as the
other features of OOP) to the table.

The extra power is generally what brings the complexity into the picture.
VBScript could do almost nothing on the server. ASP.Net has the full power
of the CLR behind it, and this means that security becomes much more complex
to manage, for one thing. It's a trade-off. More power generally means more
complexity. However, with good OOP Design Practices, the complexity can be
very manageable.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Thank You all so much for all of your replys. What I have learned is that
the concept is much easier that I first thought. But what programming
concept isn't. My synopsis: The only reason to designate a tag to be
runat=server is to be able to have access to it (give it a name) in the
code-behind (period). The advantage that code-behind gives is that the
debugger is available which is was not in classic (period). End of story!

Thank you all once again for your input.

----------------------------------------------------------------------------
 
addendum: The debugger and typecasting etc.

Jay said:
Thank You all so much for all of your replys. What I have learned is that
the concept is much easier that I first thought. But what programming
concept isn't. My synopsis: The only reason to designate a tag to be
runat=server is to be able to have access to it (give it a name) in the
code-behind (period). The advantage that code-behind gives is that the
debugger is available which is was not in classic (period). End of story!

Thank you all once again for your input.

-------------------------------------------------------------------------- --
Click to expand...
 
Back
Top