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

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" <Tom.PesterDELETETHISSS@xxxxxxxxxx> wrote in message
news:a1a977a211ec848c77622d5add66b@xxxxxxxxxxxxxxxxxxxxx
> 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
>
>
>> "tom pester" <Tom.PesterDELETETHISSS@xxxxxxxxxx> wrote in message
>> news:a1a977a211e31e8c776171d24dc03@xxxxxxxxxxxxxxxxxxxxx
>>
>>> 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
>>>> 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.
>>>>
>>>> "John Rivers" <first10@xxxxxxxxxxxxxx> wrote in message
>>>> news:1124802159.732594.264450@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>>> 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
>
>


.

Relevant Pages

  • Re: ATTN SELF-STYLED LIST POLICE (was RE: Mr. Day)
    ... On Tuesday 07 December 2004 01:59, Thomas Cameron wrote: ... >> Thank you Gene. ... >> then provided some reasons. ... > voluntarily choose to use an MUA which doesn't handle HTML? ...
    (Fedora)
  • Re: Paypal without HTML email
    ... >> Well the reason I suggested Google mail is because it reads HTML ... But there are rational reasons for preferences of that type. ... monitor and store plain ASCII text messages better and easier than ... more graphic rich formats such as HTML. ...
    (uk.people.consumers.ebay)
  • Re: Building a website using FrontPage as the front-end and C++ as the back-end.
    ... to write your own data provider meets your requirements David. ... > and HTML - I have learned Java in the past and to a lesser degree HTML too ... > And, if for practical reasons, I need to throw in between my web pages and ... >> is a client-server app, with HTML and JavaScript on the client, and some ...
    (microsoft.public.frontpage.programming)
  • Re: Custom Kernel Build -- All Those Modules
    ... As for the time 'saved', while the compile is chugging along, use ... opinions on his reasons - he merely stated his reasons and asked for ... It may be that someone is being paid to work on the kernel, ... of boot is important. ...
    (Debian-User)
  • Re: everything is ambiguous!... total badness! help!
    ... One of the main reasons I post here is to take advantage of Murphy's law. ... Bob ... > My controls assembly was behaving perfectly well (no compile errors in the ... > ambiguous in the namespace ''. ...
    (microsoft.public.dotnet.languages.vb)