Code Behind vs not

> I couldn't disagree with you more here.

Oh, I'll bet you could if you really tried!

--
;-),

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:e%****************@TK2MSFTNGP09.phx.gbl...

"Cowboy (Gregory A. Beamer) - MVP" <No************@comcast.netNoSpamM>
wrote in message
news:43**********************************@microsof t.com...
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

---

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

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

"Soviut" wrote:
My recommendation is that if your application isn't very complicated, to
simply put all your code behind into a single file. Multiple classes
can
exist within the same codebehind file and it makes for one central
location
where you can go to modify all logic for your entire application.

I've developed many small apps in dreamweaver using this method and find
it
quite streamlined. Less files to edit, less files to upload, etc.

"tshad" wrote:

> I am just trying to decide whether to split my code and uses code
> behind. I
> did it with one of my pages and found it was quite a bit of trouble.
>
> I know that most people (and books and articles) like it because you
> can
> split the code from the design. That is logical. But if you are the
> only
> one working on the code, it seem a little overkill.
>
> I use Dreamweaver to do my design and find it a bit of a hassle to
> have
> multiple files open for each of my pages as I am working on them. I
> typically have 3 or 4 pages open at one time that I am working on
> which
> translates into 6-8 files open.
>
> If I add an object to my design page I need to go the codebehind page
> to
> define it there. If I was working with multiple people on a page, I
> would
> need to run over to the person working on the codebehind and tell him
> to add
> the new object to his page.
>
> Things that are assumed on the .aspx page are not assumed on the
> codebehind
> and have to be explicitly defined.
>
> None of this is really talked about when codebehind is mentioned.
> Normally,
> you are told that it is better. Is this the case in all situations?
>
> Just trying to get other opinions on this, as I have already have
> about 30
> pages designed and am trying to decide if I should split the files or
> not.
>
> Thanks,
>
> Tom
>
>
>

Nov 19 '05 #104

Hi Tom,

If you don't have the downloadable .Net SDK installed, here's a link to the
online version Section Head for Developing ASP.Net Server Controls:

http://msdn.microsoft.com/library/de...mscontrols.asp

--
HTH,

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Oa*************@TK2MSFTNGP12.phx.gbl...

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...
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

--
HTH,

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

"Cowboy (Gregory A. Beamer) - MVP" <No************@comcast.netNoSpamM>
wrote in message
news:2E**********************************@microsof t.com...
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

---

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

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

"tshad" wrote:

> "Alan Silver" <al*********@nospam.thanx> wrote in message
> news:KE**************@nospamthankyou.spam...
> > >If you ever plan for extensibility, code-maintenance, and
> > >optimization,
> > >separating various operations into classes is essential. If you're
> > >just
> > >working on a simple and small app, it is less important. The larger
> > >and
> > >more complex your apps are, the more you will benefit from the use
> > >of
> > >good object-oriented principles, which includes abstraction,
> > >ploymorphism, and encapsulation, as well as inheritance.
> >
> > This is precisely the point I was making. Believe it or not, many of
> > us
> > make our living on small applications that are highly unlikely to
> > become
> > enterprise-scale applications. I often work on small apps and find
> > that
> > many "best practice" techniques are overkill. Sure, when working on
> > big
> > apps they are important, but sometimes they can just get in the way
> > of
> > getting the job done.
> >
> > As I said before, you have to judge each case on its own merits.
> > There are
> > times when you will want one method, and times when you will want
> > another.
> > Blanket statements claiming that code-behind (or anything else for
> > that
> > matter) is the only correct way to do it are misleading and
> > incorrect.
> >
> These were the points I was trying to make and am glad to see someone
> else
> thinking the same way I do.
>
> I also feel that you need to look at the situations. Rarely is there
> only
> *one* way to do anything. I just wanted to see the pluses and minus
> of both
> styles.
>
> Kevin really made the point.
>
> "People who don't like it generally are either working on very small
> projects, and have never worked on large ones, or simply don't want to
> work
> to learn OOP principles and application of them".
>
> I think he slightly misses the point, as you were mentioning, that it
> is
> more work on a small project. It is not necessarily that they don't
> like
> it, it is just less work. If it is a larger project, it may be better
> in
> most cases to write code-behind. But the biggest advantage, that I
> have
> been able to gleen from this, is that multiple people can work on the
> same
> application at the same time. But if you are the only person, this
> advantage is lost.
>
> Just because you *can* do something, doesn't mean you *should* do
> something.
>
> OOP is a good thing. But it isn't the only thing. I do build my own
> classes, but I am not going to build a whole class for 2 lines of
> code.
>
> I can see the advantages of both styles. But you can't make a choice
> until
> you understand both styles.
>
> Tom
>
>
>

Nov 19 '05 #105

tshad

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:OM**************@tk2msftngp13.phx.gbl...

Hi Tom,

If you don't have the downloadable .Net SDK installed, here's a link to
the online version Section Head for Developing ASP.Net Server Controls:

http://msdn.microsoft.com/library/de...mscontrols.asp
Hi Kevin,

Looks like a lot of reading for me in foreseeable future.

Thanks,

Tom
--
HTH,

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Oa*************@TK2MSFTNGP12.phx.gbl...
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ua**************@TK2MSFTNGP14.phx.gbl...
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

--
HTH,

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

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

"Cowboy (Gregory A. Beamer) - MVP" <No************@comcast.netNoSpamM>
wrote in message
news:2E**********************************@microsof t.com...
> 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

> ---
>
> Gregory A. Beamer
> MVP; MCP: +I, SE, SD, DBA
>
> ***************************
> Think Outside the Box!
> ***************************
>
> "tshad" wrote:
>
>> "Alan Silver" <al*********@nospam.thanx> wrote in message
>> news:KE**************@nospamthankyou.spam...
>> > >If you ever plan for extensibility, code-maintenance, and
>> > >optimization,
>> > >separating various operations into classes is essential. If you're
>> > >just
>> > >working on a simple and small app, it is less important. The
>> > >larger and
>> > >more complex your apps are, the more you will benefit from the use
>> > >of
>> > >good object-oriented principles, which includes abstraction,
>> > >ploymorphism, and encapsulation, as well as inheritance.
>> >
>> > This is precisely the point I was making. Believe it or not, many
>> > of us
>> > make our living on small applications that are highly unlikely to
>> > become
>> > enterprise-scale applications. I often work on small apps and find
>> > that
>> > many "best practice" techniques are overkill. Sure, when working on
>> > big
>> > apps they are important, but sometimes they can just get in the way
>> > of
>> > getting the job done.
>> >
>> > As I said before, you have to judge each case on its own merits.
>> > There are
>> > times when you will want one method, and times when you will want
>> > another.
>> > Blanket statements claiming that code-behind (or anything else for
>> > that
>> > matter) is the only correct way to do it are misleading and
>> > incorrect.
>> >
>> These were the points I was trying to make and am glad to see someone
>> else
>> thinking the same way I do.
>>
>> I also feel that you need to look at the situations. Rarely is there
>> only
>> *one* way to do anything. I just wanted to see the pluses and minus
>> of both
>> styles.
>>
>> Kevin really made the point.
>>
>> "People who don't like it generally are either working on very small
>> projects, and have never worked on large ones, or simply don't want
>> to work
>> to learn OOP principles and application of them".
>>
>> I think he slightly misses the point, as you were mentioning, that it
>> is
>> more work on a small project. It is not necessarily that they don't
>> like
>> it, it is just less work. If it is a larger project, it may be
>> better in
>> most cases to write code-behind. But the biggest advantage, that I
>> have
>> been able to gleen from this, is that multiple people can work on the
>> same
>> application at the same time. But if you are the only person, this
>> advantage is lost.
>>
>> Just because you *can* do something, doesn't mean you *should* do
>> something.
>>
>> OOP is a good thing. But it isn't the only thing. I do build my own
>> classes, but I am not going to build a whole class for 2 lines of
>> code.
>>
>> I can see the advantages of both styles. But you can't make a choice
>> until
>> you understand both styles.
>>
>> Tom
>>
>>
>>

Nov 19 '05 #106

Aquila Deus

fd123456 wrote:

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????)

I didn't, your silly kid. The site I gave is a showcase for XSLT. If
you read it carefully, you would find it doesn't even use any
server-side scripting.

--
hmmmm... dumb...

Nov 19 '05 #107

>As you will see, keeping code in one file makes more sense as you move

into the 2.0 Framework

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to
say that code-behind isn't all it's cracked up to be, and that
code-beside is functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if
I'm right, as a couple of the comments he made didn't quite fit with how
I understand code-beside (and also because the book so far is heavily
weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #108

When I started programming I read a lot of books. After a number of years, I
was approached by Wrox to co-author several books. After working on several
books, and being a technical editor for several others, I can assure you
that book authors are just developers like you and me, and as prone to
opinion as anyone else. Therefore, take any book you read with a grain of
salt. Eat the meat, and spit out the bones.

--
HTH,

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:iT**************@nospamthankyou.spam...

As you will see, keeping code in one file makes more sense as you move
into the 2.0 Framework

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to say
that code-behind isn't all it's cracked up to be, and that code-beside is
functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if I'm
right, as a couple of the comments he made didn't quite fit with how I
understand code-beside (and also because the book so far is heavily
weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #109

re:

I started reading ASP.NET 2.0 by Dino Espirito

Snippet sent to Dino *Esposito*,
who'll have a hearty chuckle, I'm sure... ;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:iT**************@nospamthankyou.spam...

As you will see, keeping code in one file makes more sense as you move
into the 2.0 Framework

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to say
that code-behind isn't all it's cracked up to be, and that code-beside is
functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if I'm
right, as a couple of the comments he made didn't quite fit with how I
understand code-beside (and also because the book so far is heavily
weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #110

>re:

I started reading ASP.NET 2.0 by Dino Espirito
Snippet sent to Dino *Esposito*,
who'll have a hearty chuckle, I'm sure... ;-)

As I typed it (from memory I should point out), I wondered about adding
a "spelling?" in brackets after the name and decided against it!! Looks
like I should have.
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:iT**************@nospamthankyou.spam...
>As you will see, keeping code in one file makes more sense as you move
>into the 2.0 Framework

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to say
that code-behind isn't all it's cracked up to be, and that code-beside is
functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if I'm
right, as a couple of the comments he made didn't quite fit with how I
understand code-beside (and also because the book so far is heavily
weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #111

>When I started programming I read a lot of books. After a number of years, I

was approached by Wrox to co-author several books. After working on several
books, and being a technical editor for several others, I can assure you
that book authors are just developers like you and me, and as prone to
opinion as anyone else. Therefore, take any book you read with a grain of
salt. Eat the meat, and spit out the bones.

OK, but when someone of his experience and standing makes a statement
that seems to be contrary to the general feeling around here, it's worth
asking about.

At least it shows that the discussion has merits on both sides and is
not as clear cut as some would like to have us believe.

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #112

> OK, but when someone of his experience and standing makes a statement that

seems to be contrary to the general feeling around here, it's worth asking
about.
That is logical.
At least it shows that the discussion has merits on both sides and is not
as clear cut as some would like to have us believe.

That is an assumption. It doesn't necessarily show anything. There are many
reasons why the book may have stated what it stated. For example, when .Net
first came out, Visual Studio.Net wasn't ready for prime time. A number of
publishers decided to get some early money by publishing books prior to the
release of VS.Net. As a result, most of those books covered hand-coding and
Code-Beside. Does this mean that hand-coding and Code-Beside are desirable?
No, it means that hand-coding and Code-Beside were all that was available at
the time. Another reason for an author sticking to hand-coding and
Code-Beside is that the author is writing for a large audience about a
programming technololgy. Some of their audience has Visual Studio.Net. Many
do not (VS.Net is expensive). How useful is a book about a programming
technology when you don't have the tools it references? How necessary is it
to talk about using Visual Studio.Net when it is not necessary to do so,
because the compiler tools are available with the .Net platform?

--
HTH,

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:sq**************@nospamthankyou.spam...

When I started programming I read a lot of books. After a number of
years, I
was approached by Wrox to co-author several books. After working on
several
books, and being a technical editor for several others, I can assure you
that book authors are just developers like you and me, and as prone to
opinion as anyone else. Therefore, take any book you read with a grain of
salt. Eat the meat, and spit out the bones.

OK, but when someone of his experience and standing makes a statement that
seems to be contrary to the general feeling around here, it's worth asking
about.

At least it shows that the discussion has merits on both sides and is not
as clear cut as some would like to have us believe.

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #113

>> At least it shows that the discussion has merits on both sides and is not

as clear cut as some would like to have us believe.

That is an assumption. It doesn't necessarily show anything. There are many
reasons why the book may have stated what it stated. For example, when .Net
first came out, Visual Studio.Net wasn't ready for prime time. A number of
publishers decided to get some early money by publishing books prior to the
release of VS.Net. As a result, most of those books covered hand-coding and
Code-Beside. Does this mean that hand-coding and Code-Beside are desirable?
No, it means that hand-coding and Code-Beside were all that was available at
the time. Another reason for an author sticking to hand-coding and
Code-Beside is that the author is writing for a large audience about a
programming technololgy. Some of their audience has Visual Studio.Net. Many
do not (VS.Net is expensive). How useful is a book about a programming
technology when you don't have the tools it references? How necessary is it
to talk about using Visual Studio.Net when it is not necessary to do so,
because the compiler tools are available with the .Net platform?

OK, the only comment I have here is that the book seems very centred
around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in
VS.NET 2005. He has quite a go at the inadequacies of VS.NET 2003, so
I'm not sure if your comments are appropriate in this case.

Anyway, thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #114

fd123456

Sorry about the obscure reference, funny only if you watch Lost (NOT
reality-tv, by the way, but an excellent series). Sawyer is just a
character that embodies people who love to be hated. I was under the
impression that it's what Aquila was after.

I'll never try to be funny in the newsgroups again. I'll never try to
be funny in the newsgroups again. I'll never try...

Michel
Alan Silver <al*********@nospam.thanx> wrote in message news:<1I**************@nospamthankyou.spam>...

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>

Nov 19 '05 #115

> OK, the only comment I have here is that the book seems very centred

around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in VS.NET
2005. He has quite a go at the inadequacies of VS.NET 2003, so I'm not
sure if your comments are appropriate in this case.

Of course my comment was appropriate! ;-) All I asserted was, you can't draw
any definite conclusions about the relative merits of either side of the
debate from the book. One would have to make guesses about the intentions of
the author in order to do that. The only fact is, it is a book about
programming with ASP.Net 2.0, which endeavors to teach the reader how to
write ASP.Net 2.0 applications.

--
HTH,

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

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:dY**************@nospamthankyou.spam...

At least it shows that the discussion has merits on both sides and is
not
as clear cut as some would like to have us believe.

That is an assumption. It doesn't necessarily show anything. There are
many
reasons why the book may have stated what it stated. For example, when
.Net
first came out, Visual Studio.Net wasn't ready for prime time. A number of
publishers decided to get some early money by publishing books prior to
the
release of VS.Net. As a result, most of those books covered hand-coding
and
Code-Beside. Does this mean that hand-coding and Code-Beside are
desirable?
No, it means that hand-coding and Code-Beside were all that was available
at
the time. Another reason for an author sticking to hand-coding and
Code-Beside is that the author is writing for a large audience about a
programming technololgy. Some of their audience has Visual Studio.Net.
Many
do not (VS.Net is expensive). How useful is a book about a programming
technology when you don't have the tools it references? How necessary is
it
to talk about using Visual Studio.Net when it is not necessary to do so,
because the compiler tools are available with the .Net platform?

OK, the only comment I have here is that the book seems very centred
around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in VS.NET
2005. He has quite a go at the inadequacies of VS.NET 2003, so I'm not
sure if your comments are appropriate in this case.

Anyway, thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #116

My aplogies, Michel. I have never watched it, and made an assumption. I am
truly ashamed that I did such a thing!

Please continue to try and be funny! I know it isn't easy. I try almost
every day, to lighten things up, but it's amazing how often my efforts are
misunderstood.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"fd123456" <fd******@hotmail.com> wrote in message
news:c8**************************@posting.google.c om...

Sorry about the obscure reference, funny only if you watch Lost (NOT
reality-tv, by the way, but an excellent series). Sawyer is just a
character that embodies people who love to be hated. I was under the
impression that it's what Aquila was after.

I'll never try to be funny in the newsgroups again. I'll never try to
be funny in the newsgroups again. I'll never try...

Michel
Alan Silver <al*********@nospam.thanx> wrote in message
news:<1I**************@nospamthankyou.spam>...
>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>

Nov 19 '05 #117

>I'll never try to be funny in the newsgroups again. I'll never try to

be funny in the newsgroups again. I'll never try...

Oh go on, we need the light relief around here ;-)

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #118

>> OK, the only comment I have here is that the book seems very centred

around VS.NET, which is a downer for me as I don't have it. He seems to
champion code-beside, partly because it can be done properly now in VS.NET
2005. He has quite a go at the inadequacies of VS.NET 2003, so I'm not
sure if your comments are appropriate in this case.

Of course my comment was appropriate! ;-) All I asserted was, you can't draw
any definite conclusions about the relative merits of either side of the
debate from the book. One would have to make guesses about the intentions of
the author in order to do that. The only fact is, it is a book about
programming with ASP.Net 2.0, which endeavors to teach the reader how to
write ASP.Net 2.0 applications.

OK, point taken. I think we have flogged this one for all it's worth.
Let's get back to the poor jokes, I think we were on safer ground
there!!

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #119

For the record, I am not, as some are, arguing that one should not move to a
model where all of the code and tags are in a single page, but you that one
should realize the consequences of the decision.

Comments inline:

"Alan Silver" wrote:

>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 <SNIPPED>

I mean single file per page. Apologies for the confusion.

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.

Perhaps not the best choice of words, but the core concept behind my
statement is embedding everything in your tagged documents leads to an
obfuscation of your object model. This is not necessarily a bad thing, but
there is no easy way to explicitly derive from Page without a CodeBehind
file. In addition, you are hard pressed to create your own page hierarchy.

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.

Whether you embed all of your code in a single file or use two (ASPX +
CodeBehind), you are working with an object model. In the CodeBehind, the
inheritance is explicit:

public class WebForm1 : System.Web.UI.Page
{
}

When you work with a tagged page (ASPX) alone, you lose the explicitness of
the inheritance and allow the HTTP Runtime to supply inheritance for you. In
most situations, this is not a problem, but it is a factor.

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.

And that is a decision you have to make. I just suggest that the decision is
made after weighing the factors. I have worked with .NET for about 5 years
now (PDC 2000 beta version) and have seen what can happen when one bucks the
system (not in this respect, however). From seeing plenty of bad ASP.NET, I
am leery of kludging the system.

I do disagree with some who are being far too hardcore, as one can make a
logical decision to move away from the "proper" model. I do not advise it,
but I am not about to blast someone for making a decision that makes sense to
him/her. I would just make sure the decision was one made after weighing the
risks and the rewards.
---

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

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

Nov 19 '05 #120

I prefer the code separation. I am not particularly fond of MS's decision to
marry the two in 2.0, but I can understand the reasoning. At least in 2.0,
you will benefit from the full class model when you decide to go with a
single page model.

It is best to go one way or another, although you can mix and merge easily
enough in .NET. It leads to better consistency and more maintainable
applications.

NOTE: Code separation also makes it easier to spot repetitive code, which
makes refactoring easier. It is easier to move common functionality to a set
of reusable classes or even libraries. Dreamweaver, unfortunately, is not the
best tool for this (great design tool, IMO, but not the best coding tool).

---

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

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

"tshad" wrote:
<SNIPPED FOR BREVITY>

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

Nov 19 '05 #121

Over-engineering can certainly be a problem. Many people, however, think over
is more common than under, when the opposite is generally true (as seen by
the many ASP.NET error pages you hit on the web :-0).

It sounds like you have thought the whole thing through. I would still argue
for the two file methodology (ie, CodeBehind), but you can always move to
that model later, if it makes sense to you. Refactoring is a part of life.
---

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

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

"Alan Silver" wrote:

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
Fortunately, Microosoft is going to compensate for those who like a single
file in the next version of Visual Studio, so the decision is less "defined".
---

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

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

"Alan Silver" wrote:
>If you ever plan for extensibility, code-maintenance, and optimization,
>separating various operations into classes is essential. If you're just
>working on a simple and small app, it is less important. The larger and
>more complex your apps are, the more you will benefit from the use of
>good object-oriented principles, which includes abstraction,
>ploymorphism, and encapsulation, as well as inheritance.

This is precisely the point I was making. Believe it or not, many of us
make our living on small applications that are highly unlikely to become
enterprise-scale applications. I often work on small apps and find that
many "best practice" techniques are overkill. Sure, when working on big
apps they are important, but sometimes they can just get in the way of
getting the job done.

As I said before, you have to judge each case on its own merits. There
are times when you will want one method, and times when you will want
another. Blanket statements claiming that code-behind (or anything else
for that matter) is the only correct way to do it are misleading and
incorrect.

Thanks for your reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #122

I will agree that classes are not a panacea (but, there no true silver
bullets in programming -- maybe "no" is too strong). In the case of the page
I showed, I see no advantage of creating an underlying class, except to be
more explicit. As there is little value in explicit for a page that simple,
one could argue either way.

With more complex pages, however, and esp. when using Visual Studio .NET,
you gain a lot by using the CodeBehind model. As some of the advantages are
tool based, you would not see them in Dreamweaver.

For me, my fondness of explicit code is my primary driving force to follow
the CodeBehind model. That may not be as important to everyone in the
discussion.
---

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

***************************
Think Outside the Box!
***************************
"tshad" wrote:

"Cowboy (Gregory A. Beamer) - MVP" <No************@comcast.netNoSpamM> wrote
in message news:69**********************************@microsof t.com...
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

---

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

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

"tshad" wrote:
I am just trying to decide whether to split my code and uses code behind.
I
did it with one of my pages and found it was quite a bit of trouble.

I know that most people (and books and articles) like it because you can
split the code from the design. That is logical. But if you are the
only
one working on the code, it seem a little overkill.

I use Dreamweaver to do my design and find it a bit of a hassle to have
multiple files open for each of my pages as I am working on them. I
typically have 3 or 4 pages open at one time that I am working on which
translates into 6-8 files open.

If I add an object to my design page I need to go the codebehind page to
define it there. If I was working with multiple people on a page, I
would
need to run over to the person working on the codebehind and tell him to
add
the new object to his page.

Things that are assumed on the .aspx page are not assumed on the
codebehind
and have to be explicitly defined.

None of this is really talked about when codebehind is mentioned.
Normally,
you are told that it is better. Is this the case in all situations?

Just trying to get other opinions on this, as I have already have about
30
pages designed and am trying to decide if I should split the files or
not.

Thanks,

Tom

Nov 19 '05 #123

CodeBehind looks like this (UML like model)

----------------------------
| System.Web.UI.Page |
----------------------------
^
|
----------------------------
| YourPage.Aspx.cs |
----------------------------
^
|
----------------------------
| YourPage.Aspx |
----------------------------

2.0 is more like this

----------------------------
| System.Web.UI.Page |
----------------------------
^
|
----------------------------------
| YourPage.Aspx.cs - partial |
| YourPage.Aspx - partial |
----------------------------------

Both are required to create a single class, instead of inheriting from the
CodeBehind. Functionally, it works the same way, but it simplifies the
runtime significantly and makes it easier for the person using ASPX alone to
code a class that is more easily recognized as a class. There are some
minuses, under the hood, to the model, as well, but that is a topic for a
more involved thread.

The CodeBeside model allows you to separate your information as you see fit.
While I would not do it, it is possible to do the following:

MyPage.aspx - tags
MyPage.aspx.cs - events from the tags
MyPage.helperFunctions.cs - internal methods used by the events.
....
ad nauseum

All of the partial classes can be compiled together and still only end up
with one class and therefore only one object in memory (for your code, as the
Page object, etc., will still be loaded).

Not sure if that makes sense. For the short answer: CodeBeside is better OO
(more efficient as well as a better object model).

---

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

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

"Alan Silver" wrote:

As you will see, keeping code in one file makes more sense as you move
into the 2.0 Framework

I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0 by
Dino Espirito last night. Right at the start of the book he appears to
say that code-behind isn't all it's cracked up to be, and that
code-beside is functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was
arguing reasonably strongly in favour of code-beside. I'm not sure if
I'm right, as a couple of the comments he made didn't quite fit with how
I understand code-beside (and also because the book so far is heavily
weighted towards VS.NET users, which I'm not yet), but maybe if someone
here has the book they could clarify this.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #124

Aquila Deus

Alan Silver wrote:

As you will see, keeping code in one file makes more sense as you moveinto the 2.0 Framework
I'm a little confused (nothing new there!!). Purely by co-incidence
(having just finished one SP.NET book), I started reading ASP.NET 2.0

by Dino Espirito last night. Right at the start of the book he appears to say that code-behind isn't all it's cracked up to be, and that
code-beside is functionally equivalent.

Maybe I didn't understand what he meant, but it sure looked like he was arguing reasonably strongly in favour of code-beside. I'm not sure if I'm right, as a couple of the comments he made didn't quite fit with how I understand code-beside (and also because the book so far is heavily weighted towards VS.NET users, which I'm not yet), but maybe if someone here has the book they could clarify this.

Obviously he doesn't like MVC, that's too bad!

Nov 19 '05 #125

>Not sure if that makes sense.

Not too much!! I must confess to being more than a little confused with
this whole subject now. I'm really not quite sure how the whole class
thing works in ASP.NET. I get the idea of classes you create explicitly
in your code, and classes in the .NET framework that you use, but I
haven't worked out quite what the idea of the page itself being a class
really means.

Perhaps I'm trying to run before I can walk. I think I have a pretty
good grasp of most of the concepts behind ASP.NET, but this one is still
beyond me.

Any simple explanations would be welcome!!

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #126

>Over-engineering can certainly be a problem. Many people, however, think over

is more common than under, when the opposite is generally true (as seen by
the many ASP.NET error pages you hit on the web :-0).
Oh, and I thought it was just me that noticed those!!

What amazes me is the lack of error checking. It's so easy to catch an
error and just display something else instead of an ASP error message
half way through a crashed page.
It sounds like you have thought the whole thing through. I would still argue
for the two file methodology (ie, CodeBehind), but you can always move to
that model later, if it makes sense to you. Refactoring is a part of life.
I'm trying to think it through!! Getting confused, but trying.

At the moment I am coding completely by hand, partly because I feel I
will learn more that way, and partly because I see little point in
buying VS.NET (not cheap) at a stage when a radically new version is on
the horizon. Maybe when I get VS.NET 2005, I will revisit the concept.
Right now it seems like more effort than it's worth.

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

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

"Alan Silver" wrote:
>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
>Fortunately, Microosoft is going to compensate for those who like a single
>file in the next version of Visual Studio, so the decision is less
>"defined".
>
>
>---
>
>Gregory A. Beamer
>MVP; MCP: +I, SE, SD, DBA
>
>***************************
>Think Outside the Box!
>***************************
>
>"Alan Silver" wrote:
>
>> >If you ever plan for extensibility, code-maintenance, and optimization,
>> >separating various operations into classes is essential. If you're just
>> >working on a simple and small app, it is less important. The larger and
>> >more complex your apps are, the more you will benefit from the use of
>> >good object-oriented principles, which includes abstraction,
>> >ploymorphism, and encapsulation, as well as inheritance.
>>
>> This is precisely the point I was making. Believe it or not, many of us
>> make our living on small applications that are highly unlikely to become
>> enterprise-scale applications. I often work on small apps and find that
>> many "best practice" techniques are overkill. Sure, when working on big
>> apps they are important, but sometimes they can just get in the way of
>> getting the job done.
>>
>> As I said before, you have to judge each case on its own merits. There
>> are times when you will want one method, and times when you will want
>> another. Blanket statements claiming that code-behind (or anything else
>> for that matter) is the only correct way to do it are misleading and
>> incorrect.
>>
>> Thanks for your reply.
>>
>> --
>> Alan Silver
>> (anything added below this line is nothing to do with me)
>>

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #127

>> >Code separation also makes it easier to spot repetitive code, which

makes refactoring easier. It is easier to move common functionality to a
set of reusable classes or even libraries.
Isn't that just an application of common sense? Surely anyone with an
ounce of sense will be able to spot when he/she is rewriting code? I'm not
talking about poor programmers, whatever tool or methodology you give
them, they will find interesting ways to misuse it, I'm talking about
people who are genuinely interested in coding efficiently. That sort of
person would move common code into modules in any framework, even good(?)
old CGI!! Code-behind isn't going to make much difference there, except in
the specialised cases mentioned earlier, like multiple language versions
of the same page.

This seems to be the biggest problem here. Mixing and matching questions.

Yup, I spotted that. I think it's help up this thread quite a few times.
This is not a code-behind question. Code separation is done in code-inside
also. It is not any easier to spot repetitive code in code-behind than in
code-inside. This might be the case were we comparing asp.net and asp.

Well, even in classic ASP you could easily move common functions out to
an include file, but I agree it's much neater in ASP.NET.

Which brings us back to the same question again, what *is* the advantage
of code-behind?

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #128

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:L3**************@nospamthankyou.spam...

As far as I can figure out, the page is a class whether it is one page or
two. You just have to explicitely tell it that it is derived from the
page class in code behind. This is done for you.

I don't see the advantage here.
Oh, so it's not just me!! I do feel better ;-)
As I mentioned, a couple of posts down, I had read the same book you did
and found even MS is taking the single page approach as default - as is
their examples code.

This is, again, not to say that Single page (in-line) is the best
approach. But a good approach in some situations.

I think it is a good idea to look at both approaches and use what is
appropriate for the situation.

Ah, but if there isn't any advantage to explicitly creating the page as a
class, then what is the advantage of code-behind at all?

I'm not saying there aren't any advantages, just that I have yet to work
out what they are ;-)

I agree.

The problem here as the discussion keeps leaving the code-behind/code-inside
question which makes it difficult to see the advantages.

One advantage is that you can work on the same page (set of pages) with 2
people (1 design and 1 code). I don't really see this unless you go through
a lot of setting up a way to translating the asp.net objects into something
a designer understands (skins, I guess or special objects), but now you have
added a layer of complexity that the designer has to learn anyway.

I see this as a bit awkward also, since you can't just create objects on a
page without letting the other person know about it or the pages won't work
(you will get errors saying objects don't exist). This would be a problem
regardless of which style you use. You still have to coordinate when each
person can modify a page.

Tom
ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #129

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:Fn**************@nospamthankyou.spam...

>Code separation also makes it easier to spot repetitive code, which
makes refactoring easier. It is easier to move common functionality to a
set of reusable classes or even libraries.

Isn't that just an application of common sense? Surely anyone with an
ounce of sense will be able to spot when he/she is rewriting code? I'm
not
talking about poor programmers, whatever tool or methodology you give
them, they will find interesting ways to misuse it, I'm talking about
people who are genuinely interested in coding efficiently. That sort of
person would move common code into modules in any framework, even
good(?)
old CGI!! Code-behind isn't going to make much difference there, except
in
the specialised cases mentioned earlier, like multiple language versions
of the same page.
This seems to be the biggest problem here. Mixing and matching questions.

Yup, I spotted that. I think it's help up this thread quite a few times.
This is not a code-behind question. Code separation is done in
code-inside
also. It is not any easier to spot repetitive code in code-behind than in
code-inside. This might be the case were we comparing asp.net and asp.

Well, even in classic ASP you could easily move common functions out to an
include file, but I agree it's much neater in ASP.NET.

Which brings us back to the same question again, what *is* the advantage
of code-behind?

The advantage is you have to do it in VS 2003 :)

Tom --
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #130

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JX**************@nospamthankyou.spam...

Actually, one reason to use VS might be to create a general purpose class
to put those routines that are used on many pages.
Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

Tom
--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #131

>> >Actually, one reason to use VS might be to create a general purpose class

>to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

No, the SDK comes with compilers, vbc for VB.NET and csc for C#.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #132

>> Which brings us back to the same question again, what *is* the advantage

of code-behind?

The advantage is you have to do it in VS 2003 :)

;-)

Do know what, let's you and I go off and write all our code-beside pages
and wait for everyone else to start using VS.NET 2005. Then they'll come
round to our way of thinking and we can claim we were right all along!!

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #133

>One advantage is that you can work on the same page (set of pages) with

2 people (1 design and 1 code).

With the caveats you mention, this *is* an advantage for those in that
situation. It's not an inherent advantage of code-behind, it's a
practical benefit.

The discussions here have centred round inherent benefits in terms of OO
and other issues not related to something so practical as you mention.
I'm still hoping one of the experts will come and explain the advantages
from that point of view.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #134

vbc /t:library /out:..\bin\Your.dll Your.vb /r:system.dll /r:system.data.dll
/r:system.xml.dll

csc /t:library /out:..\bin\Your.dll Your.cs /r:system.dll /r:system.data.dll
/r:system.xml.dll

jsc /t:library /out:..\bin\Your.dll Your.jsl /r:system.dll
/r:system.data.dll /r:system.xml.dll

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JX**************@nospamthankyou.spam...
>Actually, one reason to use VS might be to create a general purpose
>class to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

Tom

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #135

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:bA**************@nospamthankyou.spam...

Which brings us back to the same question again, what *is* the advantage
of code-behind?
The advantage is you have to do it in VS 2003 :)

;-)

Do know what, let's you and I go off and write all our code-beside pages
and wait for everyone else to start using VS.NET 2005. Then they'll come
round to our way of thinking and we can claim we were right all along!!

Sounds good to me :)

Tom
--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #136

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:fA**************@nospamthankyou.spam...

>Actually, one reason to use VS might be to create a general purpose
>class
>to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.
But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

No, the SDK comes with compilers, vbc for VB.NET and csc for C#.

So if I want to compile my Global.asax.vb or another class file, I can use
vbc?

Do you know what the compiler options I would need for that?

Thanks,

Tom
--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #137

tshad

"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

vbc /t:library /out:..\bin\Your.dll Your.vb /r:system.dll
/r:system.data.dll /r:system.xml.dll

csc /t:library /out:..\bin\Your.dll Your.cs /r:system.dll
/r:system.data.dll /r:system.xml.dll

jsc /t:library /out:..\bin\Your.dll Your.jsl /r:system.dll
/r:system.data.dll /r:system.xml.dll
Do I need to reference a path for the system.data.dll and system.xml.dll or
does it know where it is? Can I use relative address for the files?

Would my Global.asax.vb compile line to create the dll that Asp.net would
look for be:

vbc /t:library /out:../bin/Global.dll Global.asax.vb /r:system.dll
/r:system.data.dll

Also, if I took my test Global.asax that I run out of my root folder:
************************************************** ***********
<%@ Application Language="VB" %>

<script runat="server">

Sub Session_Start(sender as Object,e as EventArgs)

dim LoggedIn as Boolean

Session("LoggedIn") = false
end sub
</script>
************************************************** ************

How would I change this so the compiler would handle it correctly?

Thanks,

Tom

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JX**************@nospamthankyou.spam...
>Actually, one reason to use VS might be to create a general purpose
>class to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

Tom

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #138

>> Do know what, let's you and I go off and write all our code-beside pages

and wait for everyone else to start using VS.NET 2005. Then they'll come
round to our way of thinking and we can claim we were right all along!!

Sounds good to me :)

Tell you what, you come round to me. I have a new box of herbal tea bags
and some home made biccies <g>

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #139

I understand about what classes are, my confusion is in why

having a page as an explicitly declared class is an advantage.
Whoa, Alan, you lost me there. Did you notice that I said "everything in
..Net is a class"? It doesn't matter whether you "explicitly declare" it as
such (whatever that means). It is what it is.
As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the data
and methods into one object. My question is, given that the page is really
the top level object that you see in ASP.NET, what advantage do you have
if you explicitly create that class, or the runtime creates it implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

You end up with a class that you don't really use? What do you think is
creating the Response? Your Page class. And System.Web.UI.Page is hardly a
"top-level" class (whatever that means). It is simply a class, like any
other, and it implements IHttpHandler, just like any other IHttpHandler.

Why do you have to write it as a class? Well, remember that "in .Net
everything is a class." What are you going to type all your code into? A
class declaration. Why does System.Web.UI.Page exist? As a base class from
which you can derive as many ASPX page classes as your apps need. Do you
have to use it? No. You can use any IHttpHandler, even one you create
yourself. Why do you inherit it? Bacause you don't want to have to ype in
all the underlying code in the class every time you create a new Page.
That's what Inheritance is for.

Note: If you think your class is just the code that you add to your template
or Code-behind, you're much mistaken. The base System.Web.UI.Page class has
a whole slew of properties, fields, and methods that all exist because you
simply inherit it. They don't show up in your template; they are part of the
base class. You just type in "Inherits System.Web.UI.Page" and -BAM!- it IS
a System.Web.UI.Page that you can now extend without even apparently
realizing it.

ASP Classic, on the other hand, is not OOP, and you can't simply inherit a
bunch of functionality and build on it. Every ASP page is unique. You code
it from the ground up. If you have common functionality, the only way to
include it is using server-side includes. Server-side includes are
procedural as well, and BTW, when you use server-side includes, every page
has its own instance of the include when it runs. The included code is added
to the page code just prior to compilation. This sort of issue was why OOP
was created.

Does that help?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:VG**************@nospamthankyou.spam...

Hi Alan,

Hello,

Thanks for the reply, but I think maybe I didn't make myself clear enough.
I understand about what classes are, my confusion is in why having a page
as an explicitly declared class is an advantage.

As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the data
and methods into one object. My question is, given that the page is really
the top level object that you see in ASP.NET, what advantage do you have
if you explicitly create that class, or the runtime creates it implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

I hope this clarifies my question. Thanks for the speedy response.
this whole subject now. I'm really not quite sure how the whole class
thing works in ASP.NET. I get the idea of classes you create explicitly
in
your code, and classes in the .NET framework that you use, but I haven't
worked out quite what the idea of the page itself being a class really
means.

A class is a data type that contains both process and data. It helps if
you
understand data types. The reason for data types is that in the computer,
it's all just bits. The hard drive is just a long "array" (if you will) of
bits. Memory is just streams (or, rather A stream) of bits. Now, for
example, and integer is 32 bits in length. This tells the computer to read
32 bits and the binary number resulting from that is an integer. A string
is
an array of 16-bit Unicode characters terminated with a null 0 byte. The
length of the string tells the computer how many bits to read. If the
string
is 8 characters long, the computer reads 16 bytes, and reads each
character
by reading the 16 bits (2 bytes) of that array of bytes which is
positioned
where the character is.

No doubt you're familiar with numbers and strings. But there are also
aggregate types (in fact, string is an aggregate of characters, and any
array is an aggregate). An aggregate type is a type that combines more
than
one element of data into a single data type. For example, a Point is
composed of 2 integers (x and y). A Point is what is referred to as a
structure. A structure is an aggregate data type that contains more than
one
type of data, or more than one data member. A structure can also contain
process (functions and subs). The size of the structure is the combined
size
of all the data it holds. So, a structure is the first data type that
contains both process and data.

From structures, classes were derived. Classes are OOP, and have the
qualities of Abstraction, Encapsulation, Polymorphism, and Inheritance.
Other than that, they are much like structures.

Now, in .Net, everything is a class. A System.Web.UI.Page, for example,
consists of all the data and process needed to process an HTTP request and
return a response to the client browser. The code you write, template
and/or
CodeBehind, is compiled into a class either at run-time, or, if you have a
compiler, it can be compiled at design-time. Note, however, that the class
is what actually does the work, NOT the page you see in Visual Studio. A
file is a static document. Only executable code can execute.

At run-time, the Page class reads the template, converts all the objects
in
it into instances of classes, and uses those classes to return the
response
to the client.

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #140

> I understand about what classes are, my confusion is in why

having a page as an explicitly declared class is an advantage.
Whoa, Alan, you lost me there. Did you notice that I said "everything in
.Net is a class"? It doesn't matter whether you "explicitly declare" it as
such (whatever that means). It is what it is.

Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't
see what advantage it had to me being a class.

The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.

Meaning, that if it is created implicitly, then I don't see (yet) why
that should bother me.

As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the data
and methods into one object. My question is, given that the page is really
the top level object that you see in ASP.NET, what advantage do you have
if you explicitly create that class, or the runtime creates it implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

You end up with a class that you don't really use? What do you think is
creating the Response? Your Page class. And System.Web.UI.Page is hardly a
"top-level" class (whatever that means). It is simply a class, like any
other, and it implements IHttpHandler, just like any other IHttpHandler.

But *I* don't use it. Sure it's there, but as long as I have access to
the Response (etc) object, I don't care if that is because my page is a
class and has Response as a member, or if Response just happened to be a
global object that I could access from anywhere.
Why do you have to write it as a class? Well, remember that "in .Net
everything is a class." What are you going to type all your code into? A
class declaration. Why does System.Web.UI.Page exist? As a base class from
which you can derive as many ASPX page classes as your apps need. Do you
have to use it? No. You can use any IHttpHandler, even one you create
yourself. Why do you inherit it? Bacause you don't want to have to ype in
all the underlying code in the class every time you create a new Page.
That's what Inheritance is for.
I understand this, but you are explaining the advantages of the Page
being a class. I don't have a problem with that. What I'm trying to
understand is the benefit of having that class created by me having my
code in a separate file from the tags, as opposed to having it created
implicitly.
Note: If you think your class is just the code that you add to your template
or Code-behind, you're much mistaken. The base System.Web.UI.Page class has
a whole slew of properties, fields, and methods that all exist because you
simply inherit it. They don't show up in your template; they are part of the
base class. You just type in "Inherits System.Web.UI.Page" and -BAM!- it IS
a System.Web.UI.Page that you can now extend without even apparently
realizing it.
Ditto
ASP Classic, on the other hand, is not OOP, and you can't simply inherit a
bunch of functionality and build on it. Every ASP page is unique. You code
it from the ground up. If you have common functionality, the only way to
include it is using server-side includes. Server-side includes are
procedural as well, and BTW, when you use server-side includes, every page
has its own instance of the include when it runs. The included code is added
to the page code just prior to compilation. This sort of issue was why OOP
was created.
Again, I understand this, but it's not the question I was asking.
Does that help?

No, unfortunately.

Looking back through the last couple of posts in this bit of the thread,
I can't actually see where I picked up the explicit vs implicit idea, I
thought it was from your explanation, but I'm not sure now.

Either way, I'm left with the question of what benefit is there to
code-behind? So my page is compiled to a class, and what of it? How is
that affected by where the code lives?

Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #141

re:

Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is?
You need to add to your DEVPATH environment
variable the path to your compiler executables.

They are located at %windir%\Microsoft.NET\Framework\
netVersionNumber\

For .Net 1.1, that would be

%windir%\Microsoft.NET\Framework\v1.1.4322

re:Can I use relative address for the files?
Sure.

...\...\file.vb would work.

re: Would my Global.asax.vb compile line to create the dll that Asp.net would
look for be
There's a difference between JIT-compilation
and assembly compilation.

To do what you ask you'd need to pre-compile
your application, if you're not using VS.NET.

Wait until ASP.NET 2.0 is available.

Otherwise, just use an inline global.asax file,
instead of a code-behind global.asax.cs or .vb

re: How would I change this so the compiler would handle it correctly?
You don't need to change anything.
That's an inline global.asax.

It will be compiled on application start.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

vbc /t:library /out:..\bin\Your.dll Your.vb /r:system.dll
/r:system.data.dll /r:system.xml.dll

csc /t:library /out:..\bin\Your.dll Your.cs /r:system.dll
/r:system.data.dll /r:system.xml.dll

jsc /t:library /out:..\bin\Your.dll Your.jsl /r:system.dll
/r:system.data.dll /r:system.xml.dll

Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is? Can I use relative address for the files?

Would my Global.asax.vb compile line to create the dll that Asp.net would
look for be:

vbc /t:library /out:../bin/Global.dll Global.asax.vb /r:system.dll
/r:system.data.dll

Also, if I took my test Global.asax that I run out of my root folder:
************************************************** ***********
<%@ Application Language="VB" %>

<script runat="server">

Sub Session_Start(sender as Object,e as EventArgs)

dim LoggedIn as Boolean

Session("LoggedIn") = false
end sub
</script>
************************************************** ************

How would I change this so the compiler would handle it correctly?

Thanks,

Tom

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JX**************@nospamthankyou.spam...
>Actually, one reason to use VS might be to create a general purpose
>class to put those routines that are used on many pages.

Why do you need VS for that? Just create a class and put the DLL in the
bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get the
compiler?

Tom

Nov 19 '05 #142

> Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't see

what advantage it had to me being a class.
What advantage does grass being green grant you? None. It is what it is. So
is a Page.

OOP gives you all kinds of advantages over procedural programming. ASP.Net
is OOP. So, the advantage is not in the Page but in the Platform.
The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.
I'm afraid you're mistaken there. I'm not talking about the relative merits
of "Code-Behind vs. Code-Beside" - I stated long ago that this is not
important or even relevant (at least to me). In fact, I'm just explaining
the Page class, as per your question earlier today. In either case, you
create a class. If you use "Code-Beside" your page class is entirely in one
file. It is a single class definition which inherits System.Web.UI.Page.
When you use "Code-Behind" the page class is in more than one file, in fact,
consisting of 2 class definitions, the CodeBehind, which inherits
System.Web.UI.Page, and the Template class which inherits the CodeBehind
class. If you can understand this concept, you should be able to understand
why I don't have an opinion between "Code-Beside" and "Code-Behind." It's
not an important point. The important thing is to understand OOP and the
ASP.net object model.
But *I* don't use it. Sure it's there, but as long as I have access to the
Response (etc) object, I don't care if that is because my page is a class
and has Response as a member, or if Response just happened to be a global
object that I could access from anywhere.
If you run your app, you use it. It wouldn't run without it. Try creating a
Page without inheriting System.Web.UI.Page and see how far your app gets.
The only difference between the code you write and the code that exists by
virtue of inheriting System.Web.UI.Page, is that you don't have to write it.
It's every bit as necessary as any code you do write.
What I'm trying to understand is the benefit of having that class created
by me having my code in a separate file from the tags, as opposed to
having it created implicitly.
Again, I'm not about to wade into that morass! I'll leave that to the
Lilliputians to argue.
Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

I understand completely. OOP is a bit hard to get your head around at first,
kind of like Calculus. But once you "get it" it all snaps neatly into place.
In the meantime, I'll be happy to help you in the process of "getting it."
:)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:eD**************@nospamthankyou.spam...

I understand about what classes are, my confusion is in why
having a page as an explicitly declared class is an advantage.

Whoa, Alan, you lost me there. Did you notice that I said "everything in
.Net is a class"? It doesn't matter whether you "explicitly declare" it as
such (whatever that means). It is what it is.

Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't see
what advantage it had to me being a class.

The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.

Meaning, that if it is created implicitly, then I don't see (yet) why that
should bother me.
As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the
data
and methods into one object. My question is, given that the page is
really
the top level object that you see in ASP.NET, what advantage do you have
if you explicitly create that class, or the runtime creates it
implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

You end up with a class that you don't really use? What do you think is
creating the Response? Your Page class. And System.Web.UI.Page is hardly a
"top-level" class (whatever that means). It is simply a class, like any
other, and it implements IHttpHandler, just like any other IHttpHandler.

But *I* don't use it. Sure it's there, but as long as I have access to the
Response (etc) object, I don't care if that is because my page is a class
and has Response as a member, or if Response just happened to be a global
object that I could access from anywhere.
Why do you have to write it as a class? Well, remember that "in .Net
everything is a class." What are you going to type all your code into? A
class declaration. Why does System.Web.UI.Page exist? As a base class from
which you can derive as many ASPX page classes as your apps need. Do you
have to use it? No. You can use any IHttpHandler, even one you create
yourself. Why do you inherit it? Bacause you don't want to have to ype in
all the underlying code in the class every time you create a new Page.
That's what Inheritance is for.

I understand this, but you are explaining the advantages of the Page being
a class. I don't have a problem with that. What I'm trying to understand
is the benefit of having that class created by me having my code in a
separate file from the tags, as opposed to having it created implicitly.
Note: If you think your class is just the code that you add to your
template
or Code-behind, you're much mistaken. The base System.Web.UI.Page class
has
a whole slew of properties, fields, and methods that all exist because you
simply inherit it. They don't show up in your template; they are part of
the
base class. You just type in "Inherits System.Web.UI.Page" and -BAM!- it
IS
a System.Web.UI.Page that you can now extend without even apparently
realizing it.

Ditto
ASP Classic, on the other hand, is not OOP, and you can't simply inherit a
bunch of functionality and build on it. Every ASP page is unique. You code
it from the ground up. If you have common functionality, the only way to
include it is using server-side includes. Server-side includes are
procedural as well, and BTW, when you use server-side includes, every page
has its own instance of the include when it runs. The included code is
added
to the page code just prior to compilation. This sort of issue was why OOP
was created.

Again, I understand this, but it's not the question I was asking.
Does that help?

No, unfortunately.

Looking back through the last couple of posts in this bit of the thread, I
can't actually see where I picked up the explicit vs implicit idea, I
thought it was from your explanation, but I'm not sure now.

Either way, I'm left with the question of what benefit is there to
code-behind? So my page is compiled to a class, and what of it? How is
that affected by where the code lives?

Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #143

This thread is beginning to look like the endless
"Which is better, VB or C#" threads.

;-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:eD**************@nospamthankyou.spam...

Nov 19 '05 #144

tshad

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:eD**************@nospamthankyou.spam...

I understand about what classes are, my confusion is in why
having a page as an explicitly declared class is an advantage.
Whoa, Alan, you lost me there. Did you notice that I said "everything in
.Net is a class"? It doesn't matter whether you "explicitly declare" it as
such (whatever that means). It is what it is.

Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't see
what advantage it had to me being a class.

The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.

Meaning, that if it is created implicitly, then I don't see (yet) why that
should bother me.
As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the
data
and methods into one object. My question is, given that the page is
really
the top level object that you see in ASP.NET, what advantage do you have
if you explicitly create that class, or the runtime creates it
implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

You end up with a class that you don't really use? What do you think is
creating the Response? Your Page class. And System.Web.UI.Page is hardly a
"top-level" class (whatever that means). It is simply a class, like any
other, and it implements IHttpHandler, just like any other IHttpHandler.

But *I* don't use it. Sure it's there, but as long as I have access to the
Response (etc) object, I don't care if that is because my page is a class
and has Response as a member, or if Response just happened to be a global
object that I could access from anywhere.
Why do you have to write it as a class? Well, remember that "in .Net
everything is a class." What are you going to type all your code into? A
class declaration. Why does System.Web.UI.Page exist? As a base class from
which you can derive as many ASPX page classes as your apps need. Do you
have to use it? No. You can use any IHttpHandler, even one you create
yourself. Why do you inherit it? Bacause you don't want to have to ype in
all the underlying code in the class every time you create a new Page.
That's what Inheritance is for.

I understand this, but you are explaining the advantages of the Page being
a class. I don't have a problem with that. What I'm trying to understand
is the benefit of having that class created by me having my code in a
separate file from the tags, as opposed to having it created implicitly.
Note: If you think your class is just the code that you add to your
template
or Code-behind, you're much mistaken. The base System.Web.UI.Page class
has
a whole slew of properties, fields, and methods that all exist because you
simply inherit it. They don't show up in your template; they are part of
the
base class. You just type in "Inherits System.Web.UI.Page" and -BAM!- it
IS
a System.Web.UI.Page that you can now extend without even apparently
realizing it.

Ditto
ASP Classic, on the other hand, is not OOP, and you can't simply inherit a
bunch of functionality and build on it. Every ASP page is unique. You code
it from the ground up. If you have common functionality, the only way to
include it is using server-side includes. Server-side includes are
procedural as well, and BTW, when you use server-side includes, every page
has its own instance of the include when it runs. The included code is
added
to the page code just prior to compilation. This sort of issue was why OOP
was created.

Again, I understand this, but it's not the question I was asking.
Does that help?

No, unfortunately.

Looking back through the last couple of posts in this bit of the thread, I
can't actually see where I picked up the explicit vs implicit idea, I
thought it was from your explanation, but I'm not sure now.

I think Gregory was the one that brought it up.
Either way, I'm left with the question of what benefit is there to
code-behind? So my page is compiled to a class, and what of it? How is
that affected by where the code lives?

Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #145

tshad

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uP**************@TK2MSFTNGP12.phx.gbl...

Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't see
what advantage it had to me being a class.
What advantage does grass being green grant you? None. It is what it is.
So is a Page.

OOP gives you all kinds of advantages over procedural programming. ASP.Net
is OOP. So, the advantage is not in the Page but in the Platform.

Right. But as Alan was saying, you also have the Page in Code-inside (you
just don't have to define it - it is already done). So that is not the
advantage to it being behind vs inside.

We understand the advantage of OOP over. We all agree (I think) that that
is the way to go. That is not the question here.

The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.
I'm afraid you're mistaken there. I'm not talking about the relative
merits of "Code-Behind vs. Code-Beside"

But that was the question.
- I stated long ago that this is not important or even relevant (at least
to me). In fact, I'm just explaining the Page class, as per your question
earlier today. In either case, you create a class. If you use
"Code-Beside" your page class is entirely in one file. It is a single
class definition which inherits System.Web.UI.Page. When you use
"Code-Behind" the page class is in more than one file, in fact, consisting
of 2 class definitions, the CodeBehind, which inherits System.Web.UI.Page,
and the Template class which inherits the CodeBehind class. If you can
understand this concept, you should be able to understand why I don't have
an opinion between "Code-Beside" and "Code-Behind." It's not an important
point. The important thing is to understand OOP and the ASP.net object
model.
Agreed here.

And this was our point. Some were saying that it is poor programming to use
code-inside(beside whatever). I think "they" miss the concept. Our whole
question (mine and Alans) was based on what we would gain going from our
current 1 file/page setup to the 2 file/page setup. We were (and still are)
trying to find a good coherent reason to move to the new model. Especially
knowing that apparently code-beside (2005) is going to be slightly different
that the current code-behind model.

But *I* don't use it. Sure it's there, but as long as I have access to
the Response (etc) object, I don't care if that is because my page is a
class and has Response as a member, or if Response just happened to be a
global object that I could access from anywhere.
If you run your app, you use it. It wouldn't run without it. Try creating
a Page without inheriting System.Web.UI.Page and see how far your app
gets. The only difference between the code you write and the code that
exists by virtue of inheriting System.Web.UI.Page, is that you don't have
to write it. It's every bit as necessary as any code you do write.

I don't have it in any of my pages. But as you say it is necessary and is
already there.

What I'm trying to understand is the benefit of having that class created
by me having my code in a separate file from the tags, as opposed to
having it created implicitly.

Again, I'm not about to wade into that morass! I'll leave that to the
Lilliputians to argue.

Actually, it is an important issue. And you don't have to weigh in on it.
Especially in our case, coming from non-VS tools and thinking about going to
use VS 2003. This is a very important question as we would have to convert
all our pages to the 2 page style (not so in 2005 - whenever it comes out).
Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

I understand completely. OOP is a bit hard to get your head around at
first, kind of like Calculus. But once you "get it" it all snaps neatly
into place. In the meantime, I'll be happy to help you in the process of
"getting it." :)

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
What You Seek Is What You Get.

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:eD**************@nospamthankyou.spam...
I understand about what classes are, my confusion is in why
having a page as an explicitly declared class is an advantage.

Whoa, Alan, you lost me there. Did you notice that I said "everything in
.Net is a class"? It doesn't matter whether you "explicitly declare" it
as
such (whatever that means). It is what it is.

Yup, I noticed. I didn't say a page wasn't a class, I said I couldn't see
what advantage it had to me being a class.

The "explicit" bit was what I thought you were saying was the basic
difference between code-behind and code-beside. In the former case, you
explicitly create the page class yourself, in the latter the .NET
framework does it for you. I questioned the advantage of the former.

Meaning, that if it is created implicitly, then I don't see (yet) why
that should bother me.
As I said, I can see that writing your own classes to represent objects
(like an order object in a sales system) makes sense as you wrap the
data
and methods into one object. My question is, given that the page is
really
the top level object that you see in ASP.NET, what advantage do you
have
if you explicitly create that class, or the runtime creates it
implicitly
from your coding? Either way you end up with a class which you don't
really use. Your code is inside the class and works on objects further
down the hierarchy. Who care how the parent object was created?

You end up with a class that you don't really use? What do you think is
creating the Response? Your Page class. And System.Web.UI.Page is hardly
a
"top-level" class (whatever that means). It is simply a class, like any
other, and it implements IHttpHandler, just like any other IHttpHandler.

But *I* don't use it. Sure it's there, but as long as I have access to
the Response (etc) object, I don't care if that is because my page is a
class and has Response as a member, or if Response just happened to be a
global object that I could access from anywhere.
Why do you have to write it as a class? Well, remember that "in .Net
everything is a class." What are you going to type all your code into? A
class declaration. Why does System.Web.UI.Page exist? As a base class
from
which you can derive as many ASPX page classes as your apps need. Do you
have to use it? No. You can use any IHttpHandler, even one you create
yourself. Why do you inherit it? Bacause you don't want to have to ype in
all the underlying code in the class every time you create a new Page.
That's what Inheritance is for.

I understand this, but you are explaining the advantages of the Page
being a class. I don't have a problem with that. What I'm trying to
understand is the benefit of having that class created by me having my
code in a separate file from the tags, as opposed to having it created
implicitly.
Note: If you think your class is just the code that you add to your
template
or Code-behind, you're much mistaken. The base System.Web.UI.Page class
has
a whole slew of properties, fields, and methods that all exist because
you
simply inherit it. They don't show up in your template; they are part of
the
base class. You just type in "Inherits System.Web.UI.Page" and -BAM!- it
IS
a System.Web.UI.Page that you can now extend without even apparently
realizing it.

Ditto
ASP Classic, on the other hand, is not OOP, and you can't simply inherit
a
bunch of functionality and build on it. Every ASP page is unique. You
code
it from the ground up. If you have common functionality, the only way to
include it is using server-side includes. Server-side includes are
procedural as well, and BTW, when you use server-side includes, every
page
has its own instance of the include when it runs. The included code is
added
to the page code just prior to compilation. This sort of issue was why
OOP
was created.

Again, I understand this, but it's not the question I was asking.
Does that help?

No, unfortunately.

Looking back through the last couple of posts in this bit of the thread,
I can't actually see where I picked up the explicit vs implicit idea, I
thought it was from your explanation, but I'm not sure now.

Either way, I'm left with the question of what benefit is there to
code-behind? So my page is compiled to a class, and what of it? How is
that affected by where the code lives?

Sorry to drag this out, but I just can't seem to get a clear answer on
this. Probably due to my lack of clarity in the question. Any further
explanations would be greatly appreciated, as were past ones ;-)

Ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #146

tshad

"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:OA**************@tk2msftngp13.phx.gbl...

re:
Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is?
You need to add to your DEVPATH environment
variable the path to your compiler executables.

They are located at %windir%\Microsoft.NET\Framework\
netVersionNumber\

For .Net 1.1, that would be

%windir%\Microsoft.NET\Framework\v1.1.4322

re:
Can I use relative address for the files?

Sure.

..\...\file.vb would work.

re:
Would my Global.asax.vb compile line to create the dll that Asp.net
would look for be

There's a difference between JIT-compilation
and assembly compilation.

Are you saying I can't create a Global.dll without using VS.NET?

Tom
To do what you ask you'd need to pre-compile
your application, if you're not using VS.NET.

Wait until ASP.NET 2.0 is available.

Otherwise, just use an inline global.asax file,
instead of a code-behind global.asax.cs or .vb

re:
How would I change this so the compiler would handle it correctly?

You don't need to change anything.
That's an inline global.asax.

It will be compiled on application start.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

vbc /t:library /out:..\bin\Your.dll Your.vb /r:system.dll
/r:system.data.dll /r:system.xml.dll

csc /t:library /out:..\bin\Your.dll Your.cs /r:system.dll
/r:system.data.dll /r:system.xml.dll

jsc /t:library /out:..\bin\Your.dll Your.jsl /r:system.dll
/r:system.data.dll /r:system.xml.dll

Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is? Can I use relative address for the files?

Would my Global.asax.vb compile line to create the dll that Asp.net would
look for be:

vbc /t:library /out:../bin/Global.dll Global.asax.vb /r:system.dll
/r:system.data.dll

Also, if I took my test Global.asax that I run out of my root folder:
************************************************** ***********
<%@ Application Language="VB" %>

<script runat="server">

Sub Session_Start(sender as Object,e as EventArgs)

dim LoggedIn as Boolean

Session("LoggedIn") = false
end sub
</script>
************************************************** ************

How would I change this so the compiler would handle it correctly?

Thanks,

Tom

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:JX**************@nospamthankyou.spam...
> >Actually, one reason to use VS might be to create a general purpose
> >class to put those routines that are used on many pages.
>
> Why do you need VS for that? Just create a class and put the DLL in
> the bin directory. You can do that by hand.

But how do you compile the DLL without VS? Don't you need VS to get
the compiler?

Tom

Nov 19 '05 #147

re:

Are you saying I can't create a Global.dll without using VS.NET?
It's a question of the compilation model used.

VS.NET doesn't create a "global.dll".

It compiles global.asax.xx into something like
"App_global.asax.x08zyh4n.dll.", which it places
in the "Temporary ASP.NET Files" directory.

Try creating a "global.dll", though.
The experience will be healthy for you. :-)

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl... "Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:OA**************@tk2msftngp13.phx.gbl...
re:
Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is?

You need to add to your DEVPATH environment
variable the path to your compiler executables.

They are located at %windir%\Microsoft.NET\Framework\
netVersionNumber\

For .Net 1.1, that would be

%windir%\Microsoft.NET\Framework\v1.1.4322

re:
Can I use relative address for the files?

Sure.

..\...\file.vb would work.

re:
Would my Global.asax.vb compile line to create the dll that Asp.net
would look for be

There's a difference between JIT-compilation
and assembly compilation.

Are you saying I can't create a Global.dll without using VS.NET?

Tom
To do what you ask you'd need to pre-compile
your application, if you're not using VS.NET.

Wait until ASP.NET 2.0 is available.

Otherwise, just use an inline global.asax file,
instead of a code-behind global.asax.cs or .vb

re:
How would I change this so the compiler would handle it correctly?

You don't need to change anything.
That's an inline global.asax.

It will be compiled on application start.

Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:O1**************@TK2MSFTNGP09.phx.gbl...
"Juan T. Llibre" <no***********@nowhere.com> wrote in message
news:O3**************@TK2MSFTNGP09.phx.gbl...

vbc /t:library /out:..\bin\Your.dll Your.vb /r:system.dll
/r:system.data.dll /r:system.xml.dll

csc /t:library /out:..\bin\Your.dll Your.cs /r:system.dll
/r:system.data.dll /r:system.xml.dll

jsc /t:library /out:..\bin\Your.dll Your.jsl /r:system.dll
/r:system.data.dll /r:system.xml.dll

Do I need to reference a path for the system.data.dll and system.xml.dll
or does it know where it is? Can I use relative address for the files?

Would my Global.asax.vb compile line to create the dll that Asp.net
would look for be:

vbc /t:library /out:../bin/Global.dll Global.asax.vb /r:system.dll
/r:system.data.dll

Also, if I took my test Global.asax that I run out of my root folder:
************************************************** ***********
<%@ Application Language="VB" %>

<script runat="server">

Sub Session_Start(sender as Object,e as EventArgs)

dim LoggedIn as Boolean

Session("LoggedIn") = false
end sub
</script>
************************************************** ************

How would I change this so the compiler would handle it correctly?

Thanks,

Tom
Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"tshad" <ts**********@ftsolutions.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
>
> "Alan Silver" <al*********@nospam.thanx> wrote in message
> news:JX**************@nospamthankyou.spam...
>> >Actually, one reason to use VS might be to create a general purpose
>> >class to put those routines that are used on many pages.
>>
>> Why do you need VS for that? Just create a class and put the DLL in
>> the bin directory. You can do that by hand.
>
> But how do you compile the DLL without VS? Don't you need VS to get
> the compiler?
>
> Tom

Nov 19 '05 #148

Steve at Pixelda

Like many other problems, there is often NO correct answer, just more or less
appropriate ones. Its better to think in terms of "take advantage of
everything, and disadvantage of nothing" to solve your problem, rather than
trying to take-sides as it were.

As an example of the felxibility that Microsft have given us, I have built a
system that is both configurable and customisable, and uses all of the code
behind and in front features available to me.

My system is automated and uses the CodeDom classes to automiatically build
DLLs, based on code-behind for ASP.NET web pages (I can also output C# source
files for testing ( can be VB if requried) - but the model is totally source
code independant - see MSDN CodeDom for more details. It also outputs the
HTML part of the web page (but can also be XML and XSLT for dynamic
production). This vanilla web site can then be customsed.

Customisation is performed by including Server side scripts (either in the
HTML file or XSLT - depending on which web page production method is used)
that can be in both VB an C#. These scripts in the ASPX page are separately
compiled at run time, and execute before the code behind file. In this way,
I separate mandatory data processing in the code-behind (which cannot (and
should not) be altered), from front-end processing, which may be different
for various customers, allowing a rich interface to be developed, independant
of the code-behind.

Therefore, you can have your cake and eat it!
"Alan Silver" wrote:

Hey Alan,

I just started reading that one myself and found that he is neither in favor
nor against code-behind. He is taking the same position some of us have
taken. That is that it is not the panacea some try to make it.

That's what it seemed to me, but some round here disagree ;-)

<snip>
Also, he differentiates code-behind and code-beside is in essence the same
and in-line as one page. Code-beside is just a different implementation of
code-behind.

Which is basically what Gregory was saying. He said that code-behind
makes explicit what code-beside does implicitly (if I understood
correctly, sorry Gregory if I misquoted you). The point that I'm trying
to clear up now is what difference it makes.

<snip>
I personally am looking forward to u sing VS 2005, myself.

Me too.

ta ra

--
Alan Silver
(anything added below this line is nothing to do with me)

Nov 19 '05 #149