Code Behind vs not

[Guest]

Tom:

There are a variety of arguments against a single page model:

1. Not proper OO. This may not seem important right now, but .NET uses an
OOP model. If you break the model to simplify development, that is fine as
long as you can refactor to compensate over time. Most apps, however, are
never refactored to a proper model once they are built using kludgy or
bastardized methodologies.

2. You are moving away from explicit inheritance to implicit inheritance.
This is a common mistake, in many other ways than the issue here. Just
remember that implicit models tend to create more bugs than explicit models
and many of these bugs are logical rather than syntactical (ie, you find bad
data in your database instead of having the app "blow up" on compile or run).

3. Bad habits tend to follow you. While you are not working large
applications right now, you would, most likely, gladly get on board on a
large project if the opportunity arose. When you get to the bid, you will
either a) lose it, as you do not know proper methdologies (ie, you are "found
out") or b) you will end up with a bad design that hurts your client.

I understand the learning curve for proper OO in .NET. It is a pain. And, I
can understand the push against complex methdologies, as someone has to
maintain. Thus, making a decision to opt for a less than ideal model is a
decision one could logically make. My issue is it sounds like both you and
Alan are not only talking about coding this way today, but also never taking
the time to learn the proper way of building .NET applications. On the other
hand, MS is working to make your model work in the next version of .NET, so
you are covered.

Once again, if you are conciously making a decision for a single file per
page, then do it. You should, however, ensure you are making this decision
for the right reasons.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

This means adopting an ASP methodology for ASP.NET. Not necessarily wrong,
but less than ideal. The fortunate thing with this model is you can create a
class library of reusable functionality once you separate the common code
from the UI code, so it is certainly better than embedding all of the code in
the ASPX.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Guest]

*standing ovation*

I had completely forgotten to mention this. Kudos.

In the internals of .NET, there are quite a few other reasons for sticking
with the separation of code and UI. Of course, MS is making it less a kludge
to embed code in the next version.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Alan Silver]

Alan:

There is nothing wrong with making a decision to go to a single file over
two files. The main issue I have with it is the reasoning. "My tool does not
support" is not, IMO, a good reason to adopt an implicit model over an
explicit model.

I agree with that, and never suggested that as a reason. I was arguing
with the blanket statement that code-behind is the *only* way to do it.
I pointed out several times that any choice has to be made on the
specific situation. This includes looking at the scale and complexity of
the application and the balance of development time against the chances
of it growing so much that the current approach is not appropriate. It
does not include the tool being used (or only as a very minor factor if
everything else is equal).

I have actually done all of my ASP.NET coding so far by hand as I didn't
get on with the way WebMatrix mucked around with my code, and the beta
of VWD I tried was so painfully slow that I couldn't use it. I also find
that doing it by hand forces you to think what you are doing rather than
let the tool do it for you. When learning something new (which is what I
have been doing for the last couple of months), this is important.

I will, in all probability, end up doing code-behind for everything,
partly because I imagine once you get used to it, it is not really much
more effort than code-beside. But just as I still (when the need arises)
do quick and simple ASP files, I would reserve the possibility of doing
the same for ASP.NET if it were appropriate.

Again, my argument all the way through was with unsupported blanket
statements that there is only one way to do it, and that any other way
(including every page ever written in Classic ASP and PHP it would seem)
is simply rubbish, poor coding and unmaintainable. I find such comments
childish and inaccurate.

In Dreamweaver, you are generally working design, or your are working code.
There are cases where you are doing both, but bouncing back and forth is not
the norm, except during a debug cycle (ie, why doesn't the control event fire
properly). As the overlap is not the norm, you generally do not have two
files open at the same time. This may not be true for you, but I am most
often embedded in either design (how does it look) or functionality (the
code), as they are two separate entities.

Well, as I said before, I've never used DW, my knowledge of it is from
friends who do use it. However, your point stands even with reference to
DW.

As it happens, I often (usually?) develop the UI and the code
hand-in-hand. Obviously I will have time when I'm working more in one
than the other, but I do find a lot of overlap.

I suppose it depends on personal methods of working.

I would point out though that I never really saw extra files open as a
reason against code-behind. It is a bit more painful working with extra
files, but it's not the end if the world. Sometimes skipping up and down
the same file is harder than flipping between two separate files!! They
both have their advantages and disadvantages.

Bearing the above in mind, the only "pain" with Dreamweaver is you have to
open a different file to work with code. As you should be focused on code
when you are coding, this is not a major pain ... unless you are mixing
metaphors and having design drive code or code drive design. If you are
having one drive the other, you are creating inferior applications in most
instances.

Hmm, not sure I agree with you there. Maybe if one is actually driving
the other then yes, but having them develop in parallel is IME fairly
common. Bear in mind I work alone, not as part of a team, so instead of
having a designer and a programmer, I do both. I find myself able to
work on both together, so I'm not necessarily allowing one to drive the
other, more letting them both develop together.

If you find you are constantly shifting back and forth from tags to code,
you may want to examine your development methodology, as you are likely
having the look influence functionality, or visa versa.

Anyway, thanks for the reply. It was nice to see a sensible, reasoned
point of view that had some logic behind it (logic-behind as opposed to
logic-beside!!).

ta ra

 

[Alan Silver]

There are a few rules I have learned in my years in software:

1. Little applications eventually become large applications. This is not
true with all apps, but small companies often become large companies over
time, and many legacy applications live on far longer than they should.

Often, but not always. I suppose it depends on your customers, but as I
work mainly for small companies, most of my projects never really grow
that big. The few times they have taken a significant step forward, I
have been able to convince the client that it would be more sensible to
re-engineer the code from scratch.

A modular design helps, as you can upgrade modules instead of scrapping
the whole app. This is independent of what coding model you use.

2. Too many applications are under-engineered. While over-engineering is a
mistake, under-engineering leads to memory leaks, security leaks, etc.
Microsoft, today, is suffering for under-engineering many of the products,
leading to a huge number of patches today.

True, but over-engineering is also a problem, especially for a small
company who cannot afford the time or money to have something that will
scale in case they grow. You have to make the balance - which was my
main point in the rest of this thread. Decide what is most appropriate
in the current situation.

3. Bad design eventually catches up to you.

Unless you can run very fast!!

I am not saying that making a decision for a single page is bad, but it
should be a concious decision made after examining the issue completely. If
you are making this decision to fit a tool, it is, IMO, an unwise decision.

Agreed 100% as commented in my earlier reply.

Ta ra
alan

 

[fd123456]

Hey, that guy, Aquila Deus... He's Sawyer, from "Lost"!!!!

(hard to understand why he tries to showcase code-behind with a site
that could be done in pure html with three javascript rollovers????)

Michel

 

[Alan Silver]

Tom:

II know this wasn't addressed to me, but I hope you don't mind if I
comment as I'm very interested in what you say.

There are a variety of arguments against a single page model:

Please can you define what you mean by that as I'm not sure I understand
your comments below. This thread has wandered between code-behind vs
code-beside (which is a kind if one-page approach) to the idea of
whether separate web pages should share code or if common functionality
should be placed in one code.

Which did you mean?

1. Not proper OO. This may not seem important right now, but .NET uses an
OOP model. If you break the model to simplify development, that is fine as
long as you can refactor to compensate over time. Most apps, however, are
never refactored to a proper model once they are built using kludgy or
bastardized methodologies.

Why is it not proper OO? The way I understand it, code-beside just
houses the scripting bits in the top of the same physical file as the
HTML. The two are still completely separate. The addition of one small
Ctrl-Z between them would result in code-behind.

OK, it's not quite *that* simple, but I hope you see what I mean. The
only thing I can think of now is that the sample code-beside you showed
in another reply had the script inside the HTML, which is not the way
I've seen code-beside. In the case you showed, you had the code and HTML
mixed and I can see that that breaks OO, but in the "normal" (IME)
code-beside model, the two are separate and I'm not sure why it breaks
OO.

2. You are moving away from explicit inheritance to implicit inheritance.
This is a common mistake, in many other ways than the issue here. Just
remember that implicit models tend to create more bugs than explicit models
and many of these bugs are logical rather than syntactical (ie, you find bad
data in your database instead of having the app "blow up" on compile or run).

Again, I'm not sure what you mean here, please could you explain a bit
more.

3. Bad habits tend to follow you. While you are not working large
applications right now, you would, most likely, gladly get on board on a
large project if the opportunity arose. When you get to the bid, you will
either a) lose it, as you do not know proper methdologies (ie, you are "found
out") or b) you will end up with a bad design that hurts your client.

Truth is that I probably wouldn't accept a large project. I like working
on my own. I am my own boss, I get to decide how the project should run,
I design and code to my own standards, and so on. There are
disadvantages, but on the whole I am much happier working like this.
I've been part of a team and I didn't like it. I like to be in control
of the whole thing and you can't do that with a large project.

I understand the learning curve for proper OO in .NET. It is a pain. And, I
can understand the push against complex methdologies, as someone has to
maintain. Thus, making a decision to opt for a less than ideal model is a
decision one could logically make. My issue is it sounds like both you and
Alan are not only talking about coding this way today, but also never taking
the time to learn the proper way of building .NET applications. On the other
hand, MS is working to make your model work in the next version of .NET, so
you are covered.

In fairness, I should point out that I have a reasonable background in
OO from doing a fair bit of Java some years ago. It's a bit rusty, but
it's coming back quickly.

I can't speak for Tom, but I'm certainly not intending to stick with the
simplest way forever. My general working methodology is to seek out best
practices and pursue them. I actively look out for good design practices
as I can't afford to waste time doing it wrong. Being a sole developer,
I have a lot more on my plate than someone who can hand over tasks to
other people.

One reason I pursued this thread so much was precisely to investigate
the best practices. I just got side-tracked by someone who couldn't see
that anything other than his/her personal opinion had any validity at
all. I find that sort of mind set very hard to accept. I come here
looking for new ideas and better ways of doing things. I have learnt
enough in the past couple of decades programming to know that there is
almost never one single "best" way to do it. I'm always looking for new
ideas, but equally I'm annoyed by the "my way is the only way" attitude.

Once again, if you are conciously making a decision for a single file per
page, then do it. You should, however, ensure you are making this decision
for the right reasons.

Well, I hope I made it clear several times that my suggestion of one
file per page was NOT a rule, it was an option to be considered along
with any other option. If it turned out to be the best option for a
situation, then use it, if not, then don't. I would never make a blanket
rule like this for all situations. That was precisely what annoyed me
about the line of argument offered elsewhere in the thread.

Thanks for your informative comments. Please post back with more info
about those first two points as I'm very interested to know more about
what you meant.

Ta ra

alan

 

[Alan Silver]

Hey, that guy, Aquila Deus... He's Sawyer, from "Lost"!!!!

OK, yah got me there. I guess this is a reference to a TV show, right?
I'm amongst that tiny (but very happy) minority that don't own a box at
all, so I have no idea who Sawyer is, or what Lost is!!

Go on, enlighten me, then I will be able to appreciate your comment
more!!

(hard to understand why he tries to showcase code-behind with a site
that could be done in pure html with three javascript rollovers????)

I was trying to avoid a personal critique of the site ;-)

Ta ra
alan

 

[Kevin Spencer]

It's just another junk reality tv show. You're not missing anything. ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[Alan Silver]

It's just another junk reality tv show. You're not missing anything. ;-)

Bit like his comments in this thread - no wait, I didn't really say
that, it was someone else!!

Thanks for the reply <g>

 

[tshad]

Tom:

There are a variety of arguments against a single page model:

1. Not proper OO. This may not seem important right now, but .NET uses an
OOP model. If you break the model to simplify development, that is fine as
long as you can refactor to compensate over time. Most apps, however, are
never refactored to a proper model once they are built using kludgy or
bastardized methodologies.

2. You are moving away from explicit inheritance to implicit inheritance.
This is a common mistake, in many other ways than the issue here. Just
remember that implicit models tend to create more bugs than explicit
models
and many of these bugs are logical rather than syntactical (ie, you find
bad
data in your database instead of having the app "blow up" on compile or
run).

3. Bad habits tend to follow you. While you are not working large
applications right now, you would, most likely, gladly get on board on a
large project if the opportunity arose. When you get to the bid, you will
either a) lose it, as you do not know proper methdologies (ie, you are
"found
out") or b) you will end up with a bad design that hurts your client.

I understand the learning curve for proper OO in .NET. It is a pain. And,
I
can understand the push against complex methdologies, as someone has to
maintain. Thus, making a decision to opt for a less than ideal model is a
decision one could logically make. My issue is it sounds like both you and
Alan are not only talking about coding this way today, but also never
taking
the time to learn the proper way of building .NET applications. On the
other
hand, MS is working to make your model work in the next version of .NET,
so
you are covered.

Once again, if you are conciously making a decision for a single file per
page, then do it. You should, however, ensure you are making this decision
for the right reasons.

Which is exactly what I said below (I can see the advantages of both styles.
But you can't make a choice until you understand both styles).

As I said, I can see the value in both. I am in the process of moving to
the code-behind model for some of my pages, but will probably still write
single pages also.

I am in the process of trying to figure out how to make the 2 page scenario
work as my boss is going to do the design (using DW) while I do the coding.

He will design the page using mainly html and I will turn the html tables
into datagrids and lists. The problem is that as he wants to make changes,
this becomes a problem since he knows nothing about asp.net or css. And of
course, if he decides to move textboxes out of datalists to somewhere else
on the page, this would break the code.

I am interested in looking at Kevins Composite controls. I haven't made
many of my own controls yet, so need to get better handle on how to use
them.

Tom

 

[Kevin Spencer]

Hi Tom,

I have a few tutorials about building Server Controls on my web site:
http://www.takempis.com.

And of course, the .Net SDK has lots of articles, tutorials, and sample code
on the topic.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Neither a follower nor a lender be.

 

[tshad]

II know this wasn't addressed to me, but I hope you don't mind if I
comment as I'm very interested in what you say.

Of course not.

Please can you define what you mean by that as I'm not sure I understand
your comments below. This thread has wandered between code-behind vs
code-beside (which is a kind if one-page approach) to the idea of whether
separate web pages should share code or if common functionality should be
placed in one code.

Which did you mean?


Why is it not proper OO? The way I understand it, code-beside just houses
the scripting bits in the top of the same physical file as the HTML. The
two are still completely separate. The addition of one small Ctrl-Z
between them would result in code-behind.

OK, it's not quite *that* simple, but I hope you see what I mean. The only
thing I can think of now is that the sample code-beside you showed in
another reply had the script inside the HTML, which is not the way I've
seen code-beside. In the case you showed, you had the code and HTML mixed
and I can see that that breaks OO, but in the "normal" (IME) code-beside
model, the two are separate and I'm not sure why it breaks OO.

I agree here. I think we are mixing code-behind vs code-beside (inside) and
OO. As you say the only difference, I can see, is a copy/paste and some
extra code in both files to reference each other.

Reusable code is another matter. We used to call them Libraries of
subroutines (DLL). It is all the same, just more sophisticated. We get
into the terms inheritance and polymorphism - which is just one subroutine
calling another subroutine which calls another and sharing data. But it is
now a little more sophisticated because we have put rules and syntax onto
it - which is a good thing.

But if I write a page that handles a datagrid inside of a datalist inside of
a repeater, the code is going to be specific to this situation. We may have
built a database class to handle most of our database handling and we use
this in our page, but that would be the same whether we were in the same
page or not. I doubt I would be able to reuse code-behind code for another
page as it would be specific to this scenario. If there were common
elements that would be used, than I might strip that out and put that in a
separate class that other pages could access, but again this has nothing to
do with code-behind/beside.

Again, I'm not sure what you mean here, please could you explain a bit
more.

I wasn't sure either. Here, again, I think he may have been talking about
setting up general routines (objects,classes,libraries) to handle common
tasks, such that if a database changes, you only need to make changes in one
place and less chance of making a mistake than if you need to make the
change in 20 pages. Of course, I could be way off here.I think you are mixing "Bad Habits" with different methodology. You can
have bad habits with OOP, also.

Truth is that I probably wouldn't accept a large project. I like working
on my own. I am my own boss, I get to decide how the project should run, I
design and code to my own standards, and so on. There are disadvantages,
but on the whole I am much happier working like this. I've been part of a
team and I didn't like it. I like to be in control of the whole thing and
you can't do that with a large project.


In fairness, I should point out that I have a reasonable background in OO
from doing a fair bit of Java some years ago. It's a bit rusty, but it's
coming back quickly.

I can't speak for Tom, but I'm certainly not intending to stick with the
simplest way forever. My general working methodology is to seek out best
practices and pursue them. I actively look out for good design practices
as I can't afford to waste time doing it wrong. Being a sole developer, I
have a lot more on my plate than someone who can hand over tasks to other
people.

I am not sticking with either. I will probably use both. I may find that I
like code-behind better in some situations (if not most), but that doesn't
negate the pluses of the other way.

One reason I pursued this thread so much was precisely to investigate the
best practices. I just got side-tracked by someone who couldn't see that
anything other than his/her personal opinion had any validity at all. I
find that sort of mind set very hard to accept. I come here looking for
new ideas and better ways of doing things. I have learnt enough in the
past couple of decades programming to know that there is almost never one
single "best" way to do it. I'm always looking for new ideas, but equally
I'm annoyed by the "my way is the only way" attitude.

I agree and it does diservice to the person you are talking to. If you tell
someone (who doesn't know any better) that there is only one *proper* way of
programming - that person will assume that is the case (which it isn't). It
should be couched as this is a *good* way and here are some of the reasons
why.

Well, I hope I made it clear several times that my suggestion of one file
per page was NOT a rule, it was an option to be considered along with any
other option. If it turned out to be the best option for a situation, then
use it, if not, then don't. I would never make a blanket rule like this
for all situations. That was precisely what annoyed me about the line of
argument offered elsewhere in the thread.

Here, here. This was the reason I started this thread was to get differing
opinions on different styles.

I, like Alan, have worked for myself (and by myself) for a long time. The
problem is that I use what I know, with little chance to see other styles.
This makes it hard to make choices on directions (you can't make a choice if
you only know one way).

I also don't have time to spend learning a complete paradigm (OOP, xml,soap
etc). I learn as I go and try new techniques as they come up, which is one
of the reasons I stay in this field. It always changes. Always something
new to play with.

Tom

 

[tshad]

Alan:

There is nothing wrong with making a decision to go to a single file over
two files. The main issue I have with it is the reasoning. "My tool does
not
support" is not, IMO, a good reason to adopt an implicit model over an
explicit model.

In Dreamweaver, you are generally working design, or your are working
code.
There are cases where you are doing both, but bouncing back and forth is
not
the norm, except during a debug cycle (ie, why doesn't the control event
fire
properly). As the overlap is not the norm, you generally do not have two
files open at the same time. This may not be true for you, but I am most
often embedded in either design (how does it look) or functionality (the
code), as they are two separate entities.

It may not be the norm. But I tend to build pages in stages (aahh - a
little poetry to brighten the day). Work on some of the design, write some
code to work with it. Add some more design and then some code.

This is the same way you typically build objects. You don't build all the
object with out testing it - especially when they build on each other. You
build one piece - make sure it works, go to the next piece etc.

Bearing the above in mind, the only "pain" with Dreamweaver is you have to
open a different file to work with code. As you should be focused on code
when you are coding, this is not a major pain ... unless you are mixing
metaphors and having design drive code or code drive design. If you are
having one drive the other, you are creating inferior applications in most
instances.

I have more experiance with DW than VS at the moment, but I don't see a lot
of difference in multiple pages. You have the same thing in VS. You can
( or not - same in DW) have one or both pages open at the same time. You
still have to jump to the code-behind page to write the code and back to the
aspx page to do the design. The differences are going to be the little
proprietary code they add to make their stuff work their way (either DW or
VS).

If you find you are constantly shifting back and forth from tags to code,
you may want to examine your development methodology, as you are likely
having the look influence functionality, or visa versa.

Again, I see the same thing in VS.

Tom

 

[tshad]

I agree with that, and never suggested that as a reason. I was arguing
with the blanket statement that code-behind is the *only* way to do it. I
pointed out several times that any choice has to be made on the specific
situation. This includes looking at the scale and complexity of the
application and the balance of development time against the chances of it
growing so much that the current approach is not appropriate. It does not
include the tool being used (or only as a very minor factor if everything
else is equal).

I have actually done all of my ASP.NET coding so far by hand as I didn't
get on with the way WebMatrix mucked around with my code, and the beta of
VWD I tried was so painfully slow that I couldn't use it. I also find that
doing it by hand forces you to think what you are doing rather than let
the tool do it for you. When learning something new (which is what I have
been doing for the last couple of months), this is important.

I agree here.

What if the code you are given is really cool and you start to build a
complicated page and find that - oops - there's a gotcha that you didn't
know about and now cannot finish what you are working on.

I had this problem with radio buttons in a grid. While you can use them and
they display fine and you can choose them, you don't find out until you get
under way that they are really worthless. When you go back to work with the
control on postback, you will find all the choices gone. In my case, I went
to a 3rd party control that solved the problem and even that I had to play
around with to make it work.

Had not been doing it by hand, I wouldn't have been able to make it work.

Tom

 

[tshad]

This means adopting an ASP methodology for ASP.NET. Not necessarily wrong,
but less than ideal. The fortunate thing with this model is you can create
a
class library of reusable functionality once you separate the common code
from the UI code, so it is certainly better than embedding all of the code
in
the ASPX.

I couldn't disagree with you more here.

Putting it in a single file is hardly the same as ASP. ASP is threaded
throughout the page. ASP is identical to Code-behind in that it completely
separates the code from the design (logically on the same page as opposed to
code behind which does it physically).

Are you saying you cannot create a class library of reusable functionality
unless you go to Code-behind?

I don't think so.

Again, 2 different issues.

Tom

Tom

 

[tshad]

*standing ovation*

I had completely forgotten to mention this. Kudos.

In the internals of .NET, there are quite a few other reasons for sticking
with the separation of code and UI. Of course, MS is making it less a
kludge
to embed code in the next version.

Again, we are talking next version.

---

Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

Definately a plus.

So until ASP.NET hit the seem - nobody ever learned to program ???

A little disingenuous here.

Tom

 

[tshad]

Then please tell me in what kind of situation putting busniess logic
code in aspx is better than putting in code-behind? "Hello World"?


But Classic is indeed less maintainable. So why use it at all?

Not what you said. You said *unmaintainable*.

 

[tshad]

Tom:

It is not wise to code for a tool. If you decide to keep all of your code
in
the ASPX files, that is fine, but do not use "I use Dreamweaver and it is
harder" as your primary motivation.

I agree and I'm not.

As you will see, keeping code in one file
makes more sense as you move into the 2.0 Framework, so it is not
necessarily
a bad decision.

That may be the time to move to it then.

I never said it was a bad decision either way. I was just trying to find
out the pluses and minuses (which I have gotten from most of the people
here).

Just make sure you are making the decision for the right
reason.
Agreed.

Here is an example of an ASPX with no CodeBehind:
<%@ Page language="c#" AutoEventWireup="false" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<title>No code behind</title>
<script language="C#" runat="server">
private void btnFill_Click(object sender, System.EventArgs e)
{
txtFill.Text = btnFill.Text;
}
</script>
</HEAD>
<body>
<form id="Form1" method="post" runat="server">
<h1>No code behind page</h1>
<P><asp:Button id=btnFill runat="server"
Text="Click me to fill text box"
OnClick="btnFill_Click"></asp:Button>
<asp:TextBox id=txtFill runat="server" /></P>
</form>
</body>
</HTML>

When you divorce ASPX, you have a page that is not inheriting from a base
class you create, but is handled as inheriting directly from the Page
class.

Take your situation here.

Let's suppose this is a page you need to create. What would be the point of
creating separate pages? Just so you can create a class? To what purpose.

Classes are not a panacea. To create Classes just to create a class is a
waste of resources in my opinion.

I think Classes are great but to create a class here would be overkill -
IMHO.

The issue here is two-fold:

1. You are moving from an explicit model to an implicit model. What this
ultimately means is you have less control over your code. Fortunately,
Microsoft has lessened the impact in this case, but you still have some
items
potentially hidden from you when you moved to implied code.

2. You are creating a web site that must be maintained by someone who
understands code. When you have tags and code together, you cannot simply
send the files to a graphic artist and let him use any tool to design the
look and feel, as some tools will get rid of code blocks they do not
understand. This is not as big of a problem today, as most tools are
designed
to avoid things they do not understand.

So, there is no problem.

And having a graphic artist deal with a page that is full of html and
asp.net objects and user controls would be no problem?

A bit about internals: Underneath the hood, your tagged page (the .aspx
part) inherits from your code behind file (the .aspx.cs or .aspx.vb,
etc.).
You can remove both the CodeBehind= and the Inherits= from the @ directive
and then place your server side code in your files. The negative here is
you
cannot prebuild your IL, so you take a slightly higher hit when you first
instantiate your file, as you are both IL compiling and JIT compiling. In
the
2.0 Framework, this is less destructive, as there is a .axd file that can
compile everything in your site. If you have a "code walker" that compiles
pages (wise even with the CodeBehind implementation).

A definite drawback, but as you say in 2.0 this is less of an issue and
should have been there to begin with - I would think.

The main benefit, for a coder, with placing code in a separate file is it
gives you the ability to focus solely on the code. In Visual Studio 2005,
the
code gets separated even when located in the ASPX file, but this is due to
a
parsing trick rather than true separation. In VS.NET 200x, you end up with
tags and code mixed, as you do with Dreamweaver.

Tags and code are not mixed. They are separated. You just have to go a
little further down the page to get to the HTML.

I would not do it, personally, but I have seen too many people make
mistakes
in the ASP world that were migrated to the ASP.NET world. Ouch!!!

You really can't compare the two. ASP is a completely different animal.
And you can make mistakes in the ASP.NET world without ever have seen ASP.

Tom

 

[tshad]

Hi Tom,

I have a few tutorials about building Server Controls on my web site:
http://www.takempis.com.

Looks good. I will look at it this week. Will probably have a question or
two.

And of course, the .Net SDK has lots of articles, tutorials, and sample
code on the topic.

The problem is finding and understanding it. I will look there too.

Thanks,

Tom