Code Behind vs not

[Alan Silver]

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

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]

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.

 

[tshad]

;-)

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

 

[Juan T. Llibre]

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

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

 

[tshad]

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

 

[tshad]

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

 

[Alan Silver]

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

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>

 

[Kevin Spencer]

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]

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

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.

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

 

[Juan T. Llibre]

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.

 

[Kevin Spencer]

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.

 

[Juan T. Llibre]

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

;-)





news:[email protected]...

 

[tshad]

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.


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.


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.


Again, I understand this, but it's not the question I was asking.


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.

 

[tshad]

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.

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.

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.

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.

 

[tshad]

re:

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:

Sure.

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

re:

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

 

[Juan T. Llibre]

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.

 

[Guest]

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!

 

[Kevin Spencer]

But that was the question.

THE question?! This thread has been going on for weeks, and you are trying
to tell me there is a THE question in it?!

I was answering A question. Not THE question.

--
HTH,

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

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.

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.

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.

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

 

[Alan Silver]

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

Ah ha!! We finally hit the basic bit. I thought we were talking about
code-beside vs code-behind and couldn't work out what different it made
with regards to the Page being a class. You have clarified it
beautifully, and have also stated clearly what I have been trying to
understand for ages. I couldn't see any benefit of code-behind over
code-beside. You seem to agree that there aren't any benefits. That's
what I've been trying to work out.

I'm happy now, I feel clarified ;-)

In fact, I'm just explaining
the Page class, as per your question earlier today.

Although as it turns out, my question was entirely misguided as I
thought you were discussing You Know What.

As far as the OO aspects of Pages and other things, I did understand
them, although your explanations were still welcome. I did a fair bit of
Java some years ago, and that taught me the basics of OO.

My comments were based on a misunderstanding of the subject being
discussed.

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."

Thanks ;-)

As I said, I actually already "have it" as far as OO is concerned, I
thought there was an extra factor going on here.

As an aside, I actually like calculus. I guess that's the way my mind
works. I have a PhD in Mathematics, so I'm a bit biased!!

Thanks for the clarification, I will carry on using code-beside in the
safe knowledge that I am not completely stupid ;-)

 

[Alan Silver]

This thread is beginning to look like the endless

"Which is better, VB or C#" threads.

Oh Perl definitely

;-)

;-)