Re: Why I prefer inline code to code-behind

CGI.. i meant CGI executables.
Simple tasks only.


"Edwin Knoppert" <info@xxxxxxxxxxxxxxxxxxx> schreef in bericht
news:dnaa6q$p9r$1@xxxxxxxxxxxxxxxxxx
>
> I agree, my colleague does exactly the same.
> He did ASP for a few years now.
> The whole VWD settings are demolished to old unformatted style like
> captial tags and indents off etc..
> (To bad it isn't notepad i can read that in his mind :) )
> Everything goes directly in the html code, i hate it!
> I love the server/client code seperation!
> Only a few obvious things are required in HTML with ASP.NET tags.
>
> Well, i'm not a good HTML/website builder, i'm more the server-side :)
> I never use CCS for example, well i believe that's a sin ?
>
> I did only CGI and finally dotnet gave me something i can actually work
> with!!
> I desp. awaited v2.0 and worked with the beta's.
> Never v 2003 or so.
>
>
>
>
> "Marina" <someone@xxxxxxxxxx> schreef in bericht
> news:eMM2VzD$FHA.532@xxxxxxxxxxxxxxxxxxxxxxx
>> To be honest, I think the reason your prefer it, is because you prefer
>> ASP. And ASP allows people to be much more hacky in their approach to
>> programming. It's just a bunch of script thrown together, often with
>> little to no structure. Where ASP.NET takes more discipline, if you will.
>> And it takes the correct approach and mindset to be successfull in it. In
>> fact, I would recommend people forget everything they know about ASP when
>> starting with ASP.NET. It always seems that ASP gets in the way of doing
>> things the 'right' way in ASP.NET because it is hard to let go of old
>> habits. It feels like those that didn't know ASP before starting ASP.NET
>> have a much easier time picking it up.
>>
>> Here are my responses to your points.
>>
>> 1. Most applications would use a source control system that would require
>> a checkout. Then, one would do a build of the application and redeploy
>> that. Not only do you have source control and history that way, you also
>> have builds that you can do at any time.
>> 2. I don't think everything should be all in one massive projects. A
>> large application should be broken up into logical pieces, with business
>> logic being in separate class libraries, etc. This way no one piece is
>> overly large that its size makes a difference when uploading.
>> 3. Ok yes. But, if one is doing a build, then it does not matter, since
>> odds are other things have changed as well. Additionally, after some
>> number of copying the .aspx files over, I believe the application
>> restarts anyway. So this approach is not full proof.
>> 4. If you are only fixing the code behind, the only file you need to
>> upload is the DLL. You do not need to upload anything else. And if you
>> made changes to the UI as well - so what? Who cares if you have to upload
>> 1 or 2 files? Besides, you would be doing builds anyway, so this would
>> not be an issue.
>> 5. So add the objects from the toolbox so that VS.NET does the other
>> stuff for you. If you do everything manually, that may envolve multiple
>> changes. However, I have found that going into design mode in the .aspx,
>> and switching to code behind, VS will put the object declaration in for
>> you.
>> 6. That is unfortunate. I don't think you really see the power of
>> separation and reusability as far as code maintanability and speed of
>> development on future modules and projects.
>>
>>
>> <neilmcguigan@xxxxxxxxx> wrote in message
>> news:1134075507.552663.216850@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>>>I just wanted to list some reasons why I prefer inline code to
>>> code-behind.
>>>
>>> 1. you can fix some bugs more quickly. remote desktop into server,
>>> change the aspx file, and she's good to go. I'd say this is one of the
>>> major reasons classic ASP became so popular.
>>>
>>> 2. don't have to upload the large codebehind site DLL to fix one bug.
>>>
>>> 3. updating the codebehind site DLL restarts the application. fixing
>>> one aspx page does not. (um, i think)
>>>
>>> 4. one file to upload, not two.
>>>
>>> 5. if you manually add a runat=server control to the aspx page (ie not
>>> from toolbox), you have to add some more stuff to the codebehind page
>>> manually, but not with inline
>>>
>>> 6. the code/html separation thing is pretty bunk in my mind. if all
>>> code is in a script tag at the top of the page, and all html is below
>>> it, that's separate enough for me.
>>>
>>> 7. MS added better support for inline code in 2.0, such as
>>> intellisense, so they obviously are going to support it in the future.
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: form to email document
    ... I've never worked with PHP or CGI. ... I was hoping for something like the procedure used to upload a form, ... You could do this by writing a custom ASP ...
    (microsoft.public.frontpage.programming)
  • Re: Send and recive files
    ... > I've created a submit form where the user can select a file to upload. ... > When the user press the button for submit the selected file, how my asp ... > How can i send file to the client? ... - When I have to send file from server to client, ...
    (microsoft.public.inetserver.asp.general)
  • Re: Confirmation message instead of page
    ... Do you mean replace the whole upload page with ASP or something in the ... > Since you can use ASP, consider writing your own form handler in ASP, ... >> Jonathan Blitz ... >>> Can't be done using FrontPage extensions. ...
    (microsoft.public.frontpage.programming)
  • Re: Send and recive files
    ... Set objFSO = Server.CreateObject ... > I've created a submit form where the user can select a file to upload. ... > When the user press the button for submit the selected file, how my asp ... Normally the server ...
    (microsoft.public.inetserver.asp.general)
  • Re: Need some fresh ideas
    ... I have an upload form that allows a user to browse and select ... asp server script validates the input ... SQL Server to it ... * editFile updates the form data. ...
    (comp.lang.javascript)