TRICK: methods in ASPX pages with <%%> code blocks

John Rivers · Aug 23, 2005

Hello,

What good reason there is for not allowing methods in ASPX pages I
can't imagine, but here is how to get around that limitation:

(START)
<body MS_POSITIONING="FlowLayout">

<form id="Form1" method="post" runat="server">
<%
MyMethod(__output);
%>
</form>
</body>
</html>
<%
}
void MyMethod(System.Web.UI.HtmlTextWriter __output) {
%><input type="text" name="Name" value="some html"/><%
%>
(END)

how this works:

ASP.NET takes your ASPX code and inserts it into a hidden Render
method that takes HtmlTextWriter as an argument

we use "}" to close the current render method
then declare a method that takes the same argument
we don't need to put a closing brace because ASP.NET will
do that for us

Lucas Tam · Aug 23, 2005

What good reason there is for not allowing methods in ASPX pages I
can't imagine, but here is how to get around that limitation:

It makes for messy code?

John Rivers · Aug 23, 2005

My Classic ASP isn't messy
it is a beautiful set of classes that render html
handles multi-branding
perform top-notch best-of-practice datasheets and forms
with full locking and security that run at full speed
and can be tested quickly and easily

what IS messy is a bunch of "UserControl" files
which miss out on all the benefits of object oriented programming
leave my ASPX pages full of messy register tags
and non-standardised property accesses

a UserControl is just a single method in a file
instead of in a class where it belongs

it is silly!

Marina · Aug 23, 2005

Who says you can't have methods in the page?

Just put your methods in <script runat="server"></server"

And as someone mentioned, even though you can do this, you shouldn't. There
is no reason you can't put it in a code behind file, or in a class library
DLL.

Karl Seguin · Aug 23, 2005

Then create custom server controls

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)

tom pester · Aug 23, 2005

I like my code and functions inside the aspx page itself unless the project
architecture tells you otherwise.
If you develop in a small team the separion isn't necessary and VWD now has
full intellisense support for this scenario.

The fact that you can't have pure html in a function annoyed me very much
too when coming from cASP but you get used to it.
I think they made it impossible for performance reasons cause mixing code
with HTML did have a noticable negative perfermance effect.
Maybe they wanted to eliminate a bad programming practice?

Cheers,
Tom Pester

Marina · Aug 23, 2005

Even when you develop in a small team, there are many advantages to not
putting your code right in the .aspx.
1) reusability - not unlikely your function will be useful elsewhere
2) compile time error checking
3) easier to read, as it's not mixed in with HTML

list goes on and on.

So yes, you can do it. But I still don't see why you would want to.

tom pester · Aug 23, 2005

Hi Marina,

1) reusability - not unlikely your function will be useful elsewhere

If its a common function it should be in a class file and not in the code
behind file right?
The cases where you can reuse a code behind file are rare and I haven't spotted
them in the wild.

2) compile time error checking

Doesn't asp.net version 2 solve this?

3) easier to read, as it's not mixed in with HTML

I am not saying to mix html with code. Thats a bad idea generaly.
If I do everything in 1 file I still seperate logic from presentation but
now I put all me code in the <script runat=server> block.
The only difference is that the code is now embeded in the page itslef. That
is the only difference.
It's crucial that you understand this.

list goes on and on.

What else?

So yes, you can do it. But I still don't see why you would want to.

The code behind model has been pushed very hard in VS 2002/3 and the main
reason I used it was the lack if intellisense in the aspx file.
Now that this restriction is taken away why would I use a code behind?

The question to ask is why would you put your code in a seperate file?

I can think of 2 reasons :

1) it _promotes_ (and nothing more) thinking where code is separated from
presentation (MVC model)
2) a designer can work on the aspx file while the programmer works on the
code behind (that's not an argument of mine. I read it in the ms docs)

I find these 2 arguments not good enough. Allthough the first point can be
helpful for beginners.

There is no reason for me to have 100 files in my project when I could have
50 instead (or 1000/500 for that matter). I like to work fast and scrolling
to the top of the page to alter some code is just that little faster.
I don't like switching files. I know it takes maybe 1 second but when I program
I switch betweeb files a lot. That argument doesn't hold on big monitors
or dual views.

I can't come up with any other reason that those 2 I mentioned.

Cheers,
Tom Pester

Marina · Aug 23, 2005

A code behind file is really a specialized class file. My point was, the
code should be in something that gets compiled into a DLL. Whether it's in
a class library that is unrelated to asp.net, or in a codebehind file - it
is really the exact same thing. It gets compiled into a DLL.

I don't know what 2.0 does, or how much it improved the IDE in that regard.

In my opinion, having code in <script> tags, is mixing it with HTML. As in,
there is HTML in that file, and there is code in that file. And it's all in
there together.

I find the 2 arguments you listed more then enough to support the reasons
for doing it. Except with the change, that it more the promotes thinking
about these 2 things as separate. There is a lot to be said from separating
your UI from the business logic.

And sorry, but your reasons for not doing just don't make sense to me. I
don't care if I have 100 files or 50 files. You still just see one icon in
VS, and you can either go to design view, or you can go to code. You don't
see twice as many files - so who cares if in reality there are?

It sounds like your UI and your business logic is all intermixed together.
This will make it very difficult to re-architect (not that it sounds like
there is a lot of architecture) or change things later on, since everything
is all over the place.

In any case, microsoft didn't limit anyone to any one model of how things
should be done. If this way works for you, go ahead.

tom pester · Aug 23, 2005

Hi Marina,

I find the 2 arguments you listed more then enough to support the
reasons for doing it. Except with the change, that it more the
promotes thinking about these 2 things as separate. There is a lot to
be said from separating your UI from the business logic.

I am all for the seperation of logic and presentation and business logic
should defenetily go into its own space regardless of how small the project
is.
But the little code you write for wiring things up, ie that are specific
to the GUI, don't need seperation cause its specific and thus not reasuable.

A function that gets all orders from a database should be in a class library
(and I mean not code behind).
IMO A function that wires up the result to a datagrid doesn't have to be
in a class.

BTW Everything in ASP.NET is a class. The aspx file too. It gets transformed
by a parser to a plain class :

http://dotnetdan.com/articles/aspnet/FirstPrinciples.htm
http://dotnetdan.com/articles/aspnet/DataBinding.htm

So by that rational I do everything in a class file so I must be doing it
right

And sorry, but your reasons for not doing just don't make sense to me.
I don't care if I have 100 files or 50 files. You still just see one
icon in VS, and you can either go to design view, or you can go to
code. You don't see twice as many files - so who cares if in reality
there are?

I hear you but I like to keep everything KISS. So there must be a _good_
reason if I have to double the project in files.

In any case, microsoft didn't limit anyone to any one model of how
things should be done. If this way works for you, go ahead.

The arguments you make are all solid but for me the separation between markup
and wire up code (not Business Logic) is a logical one.
You can make it a physical separition by splitting the file in 2. But what
does it give you? IMO not more power, except for the 2 reasons that are only
a consequence of making it physical.

Cheers,
Tom Peste

Guest · Aug 25, 2005

I don't have solid "evidence" of coding one way or the other. In most
instances, it's simply user preference. The framework handles both the same
way (ok there are a few differences, but not really). You can precompile your
pages and you can compile the code-behind.

I didn't come from classic ASP so I can't speak for someone's been used to
having "inline" code. So I personally like the separation that code-behind
provides. And I'm not using v2 of the VS and if it provides better
editing/debugging capabilities, then that's great. This is one reason I
haven't done my hard-core coding on the page itself because it has
Intellisense, better debugging, etc.

As for Mr. Rivers' complaint about ASP.NET in general as compared to ASP, he
seems to be one who's more impressed by how fast (see his "VS.NET is 10 times
slower than VB6" rant) or how pretty his code is, rather than the technology
advantages ASP.NET and the .NET framework provide. A rather sophomoric
complaint if you ask me. He should roll up his sleaves and look at the
technology. I would hope he'd never go back to the primitive world of VB6/ASP
if he understood the Framework better.

Bottom line, if you like coding on your page, great. If you like
code-behind, great.
Remember, however, if you're on a development team, pick one or the other.
Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've been
involved in projects where there's been a mixture and it can be confusing
going from one to the other and from an architecture standpoint, it's not
good practice.

-- John Harcourt

Kevin Spencer · Aug 26, 2005

Bottom line, if you like coding on your page, great. If you like

code-behind, great.
Remember, however, if you're on a development team, pick one or the other.
Settle it with a toss of a coin or arm-wrestle. Then stick to it. I've
been
involved in projects where there's been a mixture and it can be confusing
going from one to the other and from an architecture standpoint, it's not
good practice.

The real bottom line is, if you are serious about making a living as a
developer, adopt best practices. They are called "best practices" because
they improve the performance of the developer, and the performance,
scalability, and maintainability of the software that the developer creates.
Best practices are arrived at by experienced developers who have observed
the problems and pitfalls of various methodologies, both by their own
experiences, and by observing the experiences of others, over a long period
of time.

I was once told that "wisdom comes by experience, and experience by lack of
wisdom." However, the older I get, I realize that there is another better
way to come by wisdom, and that is by listening to those who already have
it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

John Rivers · Aug 27, 2005

who has it?

why not me?

big chunks of what is in asp.net today

i wrote myself in vb6 for asp about 8 years ago

code blocks aren't evil, they are the most intelligent
way of handling html literals in presentation logic

whether pre compiled or jit compiled, in methods, classes, controls
or anything you like

Kevin Spencer · Aug 29, 2005

who has it?

People who have diligently sought it for many years. People who can accept
painful truth, especially about themselves, and who are willing to change in
response to those truths.

why not me?

No reason whatsoever. The sooner you get started seeking it, the sooner you
will find it. but it takes a great deal of time, patience, and persistence.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

Guest · Aug 29, 2005

No argument from me there.
With the subject of code-behind, however, Best Practices indicate that the
size and scope of a project that you're dealing (and the developers) with can
help determine if you should use code-behind or not. MS didn't stop the
ability from writing in-line code. Many of the early .NET books (even from
MSPress) hardly mentioned code-behind at all. MS's own Matrix tool doesn't
support code-behind. So I can hardly be surprised to see hoards of
professional developers following Best Practices as they know it, but not
using code-behind. Totally legitimate.
From a personal level I've always used code-behind, even for small pages. I
just like the separation it provides. But I have a good buddy who wrote ASP
classic for years and finds code-behind a bit getting used to. His first
instinct is to write in-line code.

cheers.

Kevin Spencer · Aug 29, 2005

Hi John,

As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class logic
can be in the same file as the Template code and still be separated from it
(all at the top, for example). I feel that the most important "Best
Practices" consideration regarding Pages is that Pages should not contain
any business logic, only interface logic.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

John Horst · Aug 29, 2005

If I understand it right, there is a compilation difference between
inline and codebehind. I do know that you can change inline code
without having to redploy the binary in the bin folder. That might look
good from one view, but seems to come at a performance cost.

As for all the books out there, most have been written on a marketing
assumption that the reader may not have VS (thus they use inline samples
and do not show the user how to make the most of the VS IDE). I think
that assumption is probably largely wrong.

John

-----Original Message-----
From: Kevin Spencer [mailto:[email protected]]
Posted At: Monday, August 29, 2005 8:55 AM
Posted To: microsoft.public.dotnet.framework.aspnet
Conversation: TRICK: methods in ASPX pages with <%%> code blocks
Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks

Hi John,

As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class
logic can be in the same file as the Template code and still be
separated from it (all at the top, for example). I feel that the most
important "Best Practices" consideration regarding Pages is that Pages
should not contain any business logic, only interface logic.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

John Rivers · Aug 29, 2005

Yes!
Somebody understands at last.

Kevin said:
Hi John,

As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class logic
can be in the same file as the Template code and still be separated from it
(all at the top, for example). I feel that the most important "Best
Practices" consideration regarding Pages is that Pages should not contain
any business logic, only interface logic.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Paranoia is just a state of mind.

John Rivers · Aug 29, 2005

the difference between aspx and aspx.cs
is straightforward

aspx is jit compiled when the page is requested

everytime the page is requested the asp.net runtime
checks the modifydate and size of the file

if it has changed it recompiles the new one

this allows for designers to change aspx and upload
it without recompilation

that is a GOOD THING

however, where ms has made a mistake is in VS.NET
they should have allowed ASPX pages to be compiled
as part of the BUILD, this would let structural errors
be caught without a potentially long winded live test
or worse, a customer having a problem

thus allowing for, if required, fully compiled
ASPX and don't let the designer interfere with
production server

the point is there is no actual performance
difference between the two, code blocks are not evil.

and if you subscribe to the idea that no html literals
should be used by developers, thus enabling the
automatic html versioning stuff to work (not that it will)
you must continue that policy throughout your work, all
classes you create that do generate html literals must take
part in the html versioning infrastructure (like to see you
try) and also solve the issue of html versioning in aspx
(yeah, try that too!)

so back to my original point

WHY DID MICROSOFT FORCE ME TO STOP WRITING PRESENTATION CLASSES
AND METHODS WITH HTML LITERALS (CODE BLOCKS)

the answer: they have made an "ERROR IN JUDGEMENT" aka "A MISTAKE"

John said:
If I understand it right, there is a compilation difference between
inline and codebehind. I do know that you can change inline code
without having to redploy the binary in the bin folder. That might look
good from one view, but seems to come at a performance cost.

As for all the books out there, most have been written on a marketing
assumption that the reader may not have VS (thus they use inline samples
and do not show the user how to make the most of the VS IDE). I think
that assumption is probably largely wrong.

John

-----Original Message-----
From: Kevin Spencer [mailto:[email protected]]
Posted At: Monday, August 29, 2005 8:55 AM
Posted To: microsoft.public.dotnet.framework.aspnet
Conversation: TRICK: methods in ASPX pages with <%%> code blocks
Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks

Hi John,

As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class
logic can be in the same file as the Template code and still be
separated from it (all at the top, for example). I feel that the most
important "Best Practices" consideration regarding Pages is that Pages
should not contain any business logic, only interface logic.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Paranoia is just a state of mind.

John Harcourt said:

No argument from me there.
With the subject of code-behind, however, Best Practices indicate that

Click to expand...

the size and scope of a project that you're dealing (and the
developers) with can help determine if you should use code-behind or
not. MS didn't stop the ability from writing in-line code. Many of
the early .NET books (even from
MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
doesn't support code-behind. So I can hardly be surprised to see
hoards of professional developers following Best Practices as they
know it, but not using code-behind. Totally legitimate.
From a personal level I've always used code-behind, even for small pages.
I
just like the separation it provides. But I have a good buddy who
wrote ASP classic for years and finds code-behind a bit getting used
to. His first instinct is to write in-line code.

cheers.

Click to expand...

Kevin Spencer · Aug 29, 2005

If I understand it right, there is a compilation difference between

inline and codebehind. I do know that you can change inline code
without having to redploy the binary in the bin folder. That might look
good from one view, but seems to come at a performance cost.

There is not much of a difference. The Page class is compiled the first time
the Page is requested, and the compiled version is cached. It will expire
from the cache eventually, but most of the time, the cached version is used.
It is important to remember that the Page class itself is compiled from BOTH
the Page Template and the CodeBehind class, in either case. That is why the
Page INHERITS the CodeBehind when using a separate CodeBehind coding model.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Paranoia is just a state of mind.

John Horst said:
If I understand it right, there is a compilation difference between
inline and codebehind. I do know that you can change inline code
without having to redploy the binary in the bin folder. That might look
good from one view, but seems to come at a performance cost.

As for all the books out there, most have been written on a marketing
assumption that the reader may not have VS (thus they use inline samples
and do not show the user how to make the most of the VS IDE). I think
that assumption is probably largely wrong.

John

-----Original Message-----
From: Kevin Spencer [mailto:[email protected]]
Posted At: Monday, August 29, 2005 8:55 AM
Posted To: microsoft.public.dotnet.framework.aspnet
Conversation: TRICK: methods in ASPX pages with <%%> code blocks
Subject: Re: TRICK: methods in ASPX pages with <%%> code blocks

Hi John,

As far as CodeBehind is concerned, I am not aware of any significant
differences in the use of it versus not using it. The CodeBehind class
logic can be in the same file as the Template code and still be
separated from it (all at the top, for example). I feel that the most
important "Best Practices" consideration regarding Pages is that Pages
should not contain any business logic, only interface logic.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Paranoia is just a state of mind.

John Harcourt said:

No argument from me there.
With the subject of code-behind, however, Best Practices indicate that

Click to expand...

the size and scope of a project that you're dealing (and the
developers) with can help determine if you should use code-behind or
not. MS didn't stop the ability from writing in-line code. Many of
the early .NET books (even from
MSPress) hardly mentioned code-behind at all. MS's own Matrix tool
doesn't support code-behind. So I can hardly be surprised to see
hoards of professional developers following Best Practices as they
know it, but not using code-behind. Totally legitimate.
From a personal level I've always used code-behind, even for small pages.
I
just like the separation it provides. But I have a good buddy who
wrote ASP classic for years and finds code-behind a bit getting used
to. His first instinct is to write in-line code.

cheers.

Click to expand...

TRICK: ASP.NET methods with code blocks	1	Aug 18, 2005
ASPX now with methods and classes	6	Aug 26, 2005
I have fixed ASP.NET check it out	23	Aug 24, 2005
IIS5 > IIS6 Aspx pages with MSAccess dbs no longer working	8	Jul 26, 2005
First PageMethod blocks second page method from executing	3	Jul 23, 2007
Access a Class properties/methods from a .aspx file ?????	1	Jul 29, 2003
combining funtionality from two pages	1	May 30, 2008
Using wincontrols in aspx page	0	Feb 28, 2004

TRICK: methods in ASPX pages with <%%> code blocks

John Rivers

Lucas Tam

John Rivers

Marina

Karl Seguin

tom pester

Marina

tom pester

Marina

tom pester

Guest

Kevin Spencer

John Rivers

Kevin Spencer

Guest

Kevin Spencer

John Horst

John Rivers

John Rivers

Kevin Spencer

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads