I've been having this discussion with my brother, and it looks like none of us is well qualified to answer the question.
n fact, since I've been learning ASP.Net MVC, I've the impression that I should create all my .aspx pages using HTML/CSS. He (my brother) sustains that - in the modern day - we should not spend to much time on HTML/CSS because there are software (like Dreamweaver) which do just that.
Although I do more of the server side coding, I think it's important to settle this matter for further orientation.
By the way, in case I should use Dreamweaver-designed pages, how would I integrate them in my ASPNET-MVC project?
Thanks for helping
This is the classic discussion pro/against html generation, and just by asking the question you risk the post being closed as "subjective" =)
Basically, you have to decide whether you want simplicity in your work creating the code, or in the code itself.
Dreamweaver (and every other WYSIWYG HTML tool I've ever encountered) will generate a lot of extra code, which will make it harder to incorporate your server side code - simply because there's a larger mess to navigate in.
On the other hand, creating the HTML page might be a lot faster than writing the code by hand.
If you're good at using a WYSIWYG editor, be it Dreamweaver, the built-in one in Visual Studio or some other one, you might benefit from drawing up the rough scetches in that. I would recommend, though, that you always do the finishing by hand, in the code. That's the only way you can retain complete control over your output.
From a purist perspective, unless you can already code your HTML, CSS and JavaScript by hand you shouldn't use a tool that does it for you.
Tools are very valuable at making your more productive, but the experience to know when they screw up is more valuable.
Well, the answer is pretty simple. Dreamweaver is just a glorified code editor with autocomplete, the ability to connect to FTP and upload your work within the program, and a unique "design view" which lets you move coded objects around with your mouse and also give you a visual representation of what your work looks like without opening a full browser. It doesn't matter if you use Notepad, Dreamweaver, or another code editor to create your code. For a fact, I know a lot of ASP/.NET programmers just use MS Visual Studio to do their work because ASP/.NET is simply a MS language and Visual Studio supports a lot of tools which ASP/.NET programmers find useful. That said, you can still code ASP/.NET with any other code editor, it just may be more manual or time consuming on your part to do so. You said "Dreamweaver-designed pages" and all this is is just a document coded with Dreamweaver being used as the code editor, there are no Dreamweaver specifics that would add to the document. Unfortunately, your bother does not seem to understand the differences or the complexities between programs or programming languages and vice-a-versa where they are similar. Whether you are programming for HTML or ASP/.NET, making a stylesheet with CSS, your project being server-side or client-side, it is always good practice to use standard markup and make sure all your work is cross-browser compatible with a strong influence on being compatible with IE. Just remember that most of all code is done by hand, and the reason for this is because the programmer needs to fact check everything he/she is doing to minimize errors and create an efficient document or program. Unfortunately again, a program just cannot do as good a job of realizing the ultimate coding goal than that of a human brain can achieve. Oh, and by the way, unless you are creating a simple document and utlizing only CSS to design that document, leave the design up to the designer.
Tomas is on the money with his comments. Your brother's notion that in the "modern day" you shouldn't have to mess with the code is sadly not true. The tools that we have for html/css/web development will get you only so far. You will likely be able to build a "functioning" site with any of them individually or in combination but to get the real fit and finish that you see in a excellent application you will be working in code as well.
Moreover, you have chosen ASP.NET MVC which for ASP is a pretty thin abstraction layer and works pretty close to the metal. It was designed as a framework for folks who do a lot of the code by hand and with minimal wizardry. The tooling at this point reflects that. The tooling will stub you out a basic application, but the rest you do either outside VS2008 or by hand in the VS2008 editor.
If you are "starting to learn" MVC as you said, your workflow will probably start off by using the framework code generated by VS, so now are working in VS2008. The html editor in VS2008 is limited to say the least, so if you want some more wizard driven development of css or html for your views you may work on a view page or a html snippet in Dreamweaver, Expression or your some other editor. You'll then be dropping that code back in VS2008 and doing more work there to link up the view to the controller.
As you get more of an understanding of the css and html you will use the wizards and dialog driven stuff in Dreamweaver less and less simply because it is faster to just open up the code and make the change.
Related
The long story:
The larger problem is that I'm trying to convince people from switching away from Outlook to a more sane bugtracker, preferably web-based that we could also use as a public bugtracker. But the current argument against it is that the Outlook editor (which is really Word with all the bells and whistles) allows easy inserting of pictures, advanced formatting, etc. So I wonder if I'm at a dead end, or there is hope yet.
The problem in a nutshell:
I want to know - is it possible to create a website component that would be a REALLY powerful rich text editor. A must-have feature is to insert pictures into the editor straight from the clipboard. Better yet - does something like that exist?
There is no limit on the allowed technology. It can be flash based, java based, work only in IE, etc.
Is it possible: Yes, but not with JavaScript alone. You will need a plugin or client software to accomplish this.
As far as the technology allowed, this really depends on how you want to implement it. You could use the JRE and write everything in Java. If you're more focused on IE you might consider VB or C#.
Vaadin and Apache Click seem to be equally good, which one should I choose for developing my web application. Or rather, what are the Pros and Cons of each framework.
I'm a committer of Apache Click but hopefully you will find my opinion objective.
I don't know Vaadin at all, just had a cursory look at their website and examples and mission statement.
Apache Click and Vaadin are meant for different problem spaces. Apache Click is targeted at traditional enterprise web applications while Vaadin targets the Rich Internet Application (RIA) space.
Apache Click is a traditional share nothing, stateless framework. Unlike traditional action based web frameworks Click provides a slightly higher level of abstraction by using Pages and Components. At the of the day Click isn't a revolution. Its just one of many approaches of doing web application development. In my opinion its a very good approach, both from a developer and maintainer point of view. (In enterprise environments the developer and maintainer are often not the same individual, so I differentiate between the two roles).
However developers sometimes have requirements that cannot be satisfied by traditional web applications, which is where RIA comes in. They provide a richer user experience (think desktop) but this does not come for free. RIA comes at a cost in terms of complexity, productivity and time-to-market. It makes sense though, if the requirements are for a richer experience, you need to do more in order to deliver that experience.
My advice here is: think carefully about your requirements. Don't simply assume that RIA is better, there is a price to pay, so make sure you get return for your investment.
Lastly, if your requirement is for RIA, then you should compare Vaadin with Flex. If your requirement is for a more traditional web application then compare Click with Struts, Stripes, Wicket, Tapestry etc.
Kind regards
Bob
I use both ;-)
Click is the best for classic web applications (pure html with no/ small/ handmade javascript).
It is very lightweight (small size and stateless), less verbose (you can do your html in html with velocity/freemarker power ;-).
A real php-killer.
Vaadin is the best for desktop like enterprise applications.
It is statefull, heavyweight, verbose, but amazing.
Grails, Play!, Spring MVC is a real step back after Click/Vaadin.
So my advice: use both!
For most of your pages you will use Click, for complicated tasks - Vaadin.
I've been using Click since 2006. I've built various web applications with it in the last 4 years. All apps (B2B) are still going strong and continue to be maintained/added to now. The best things about Click IMO include:
Very little magic and almost no plumbing. It's all just plain java (and jsp/velocity/freemarker take your pick; or alternatively use all 3 if you so choose; I have for some scenarios because it's so easy to).
It's super fast (It doesn't mean your app won't be slow, it just means Click will never be the reason why your app is slow)
It is so easy to integrate your favourite java lib eg. Ibatis SQLMAP, Spring, displaytag, DWR etc.etc.
You don't need to buy a book to understand/use it (although you may need books for all the other 3rd part libs you plan to use).
Most of my code written 4 years ago still works with the current release. That is just awesome.
Click fits in your head. The whole framework that is. It is so simple you don't have too many questions even as a beginner.
The guys that maintain Click are super responsive and very noob friendly.
It's simplicity helps my apps adapt to new/old tech. i.e I can easily do AJAXy stuff if I want or not.
The form features make handling html forms very easy/fast.
The table features make displaying data super easy/fast
Click's features help me write apps very quickly. Makes the need for scaffolding unnecessary imo.
If you want a light weight, fast, easy to understand framework which helps you build applications as fast as you or your team are personally able to, check out click, it will be worth your while.
Before making your choice you should evaluate all options by taking them out on a test drive.
I'm not familiar with Click, and someone should correct me if I'm wrong, but I understand Click basically a technique to link your server side code to web pages. The UI is page-based and you define the UI with components corresponding to HTML elements. Ajax is not (yet) supported, I gather.
Vaadin operates at a higher level of abstraction. With Vaadin you get to concentrate on your business logic, and build your UI naturally with views, layouts and other components (check out the Sampler). You don't need to care about RPC, page transitions, HTML or templates. Vaadin gives you a fully cross-browser compliant Ajax UI that looks and works great out of the box. It's very easy to get started, and the forum is very active (>700 messages last month compared to 96 on the Click mailing list).
Disclaimer: I'm a member of the Vaadin team and have not used Click.
I would choose, and I already did in a few projects Click (over all other frameworks).
The main selling point for me was that I was able to learn Click and be quite productive in one week-end (Vaadin - but other frameworks too took me much more).
The free and available documentation for Click is much better - you can compare the sites yourself (even if the Vaadin site looks cooler, the Click site is simply more useful - at least it was for me).
The live examples are much better - I always look at them as a snippet repository, and just copy what I need from there (since I'm a lazy programmer :) ) - there's a "Page Java" and "Page HTML" link for every example that shows the source code for every available example.
Regarding the message traffic, I don't think that should be a criteria, since having so good free online docs, and the framework being so much simpler, the users simply don't need to ask that much.
Disclaimer: I'm just a simple user that have used both frameworks.
Is Apache wicket an option as well ?
My experience is with jboss/ejb/jquery, but looking at technologies for starting a new project. I've done a quick bit of research myself abd Vaadin seems to be very well regarded.
Surely Apache Wicket is something you can not ignore if you are comparing UI frameworks. ( I am doing same.) I dropped Vaadin because of poor documentation ( maybe I am not a good Googler.)
Currently comparing Wicket, Click, and ZK.
Click and Wicket are ahead so far for the following reasons:
Generates pure HTML instead of rendering UI using JavaScript which happens in GWT, Vaadin, and ZK. You can use HTML5 features then.
Even with native HTML, server-side binding of UI forms is possible.
You don't need to worry about communication with the server. ZK also does this but with their own language ZUML.
I have found server-side memory footprint higher in ZK in the case of components like the ZK Grid. (Memory footprint for Click is not known to me yet.)
I want to streamline the process by which I create static websites.
I want to avoid having to do multiple editing operations when I have to change one page element, like the text or image in a footer.
I want to be able to use my tool on a local computer, in order to upload the resulting structure to my server.
I don't want to use a tool that is required to reside on a server. I simply don't want a php solution when I don't need it's power or want it's overhead.
I certainly don't want to use a CMS.
Ideally, I would like the solution to be well-documented.
I've looked at the perl template toolkit. But is capable of so much, that it's body of documentation effectively hides the simple tasks that I want to accomplish.
I've also looked at webgen, but the same problem exists. It can do so much that it is difficult to set up for the simple task of creating a small static website. Again, the documentation is very detailed, but unhelpful for the creation of simple sites.
What solutions do other developers use ?
The most obvious solution is to use an editor like Dreamweaver that has templating built in. The result of template + page content is a single static page that's served as plain HTML. The page processing is done at design time, not when the page is served. It's been a number of years since I've used DW but I'd guess it still offers this feature. Frontpage might support this as well, but I've barely used it so I couldn't tell you.
Another, more creative solution would be to make a scripted site using Perl or something and then mirror it with wget. The mirrored copy will just contain the HTML that was generated from your scripted pages. That way, you get (some of) the flexibility of scripting while still getting the performance and simplicity of serving static HTML.
It all depends on the language you're using... HTML is prolly not the best, but if you're using ASP.NET then you can use Masterpages. If you're using PHP or ASP you could include headers and footers, as well as navigation and other persistent content.
This is not so much a tool as it is a concept.
If you don't want to use any server side solutions and you don't want to use ASP.NET then your only real option is iFrames but they do have some issues with SEO so I would stay away from them.
Honestly, I would suggest ASP.NET. Just use Mono. It is open source and can run on Apache and a couple other *nix server types. It will allow you to use user controls and masterpages to manage your code and reduce code duplication. I know that will create some server side overhead but .NET does compile its code on the server. Also, it wouldn't be doing much on the code side just putting your html files together which something is going to have to do regardless. That would mean pretty minimal processing on the server.
I know you said no server-sided solutions but mod_layout for apache does what you want pretty easily.
http://freshmeat.net/projects/mod_layout/
Adobe's Contribute tool can let you do this too -- it's kind of like Dreamweaver for people who don't want to know about HTML. Perfect for the situation where a company chooses someone to maintain a website that has never done anything on the web beyond casual surfing (why does this happen so much?). It uses FTP/SFTP in the background.
That said, if you have any developer bones in you, you will be highly annoyed by the way it shields you from the code. Also, getting any help from Adobe is a lost cause.
There is Ristretto project: https://github.com/ViliamKopecky/Ristretto. It's designed for simple creation of HTML files. It uses templating from Nette Framework (PHP), but is produces plain HTML, so you don't need PHP on server.
It also allows you to keep variables aside from files in Neon format (Yaml-like).
Just a random question. I've been in internship and then working as a software designer for almost a year now, mainly with SQL Server 2005 / 2008, and Visual Studio 2008 with ASP.Net VB / C#, web software development. We recently started a project with ASP.Net MVC, and I just don't get this stuff.
The concept of Views, Controllers, Models etc is clear. I'm still a bit confused with some of the syntax, but it doesn't seem impossible to get. My problem however, is with all the basic controls and functions you had with basic ASP.Net. Want a dropdownlist? Go browse through 15 tutorials one of which may actually work. How about a gridview with editable rows? Manually build the tables or helper classes with loads and loads of code also built from several different tutorials. What about panels or multiview indexes to easily control the visible user-interface on a page? Well, go learn another tutorial about how to do it all from scratch. Etc..
I do not argue the idea that MVC is worth it. It has to be, with so many people smarter and more experienced than I am saying so. But I've now fought with this beast for over a month and am getting increasingly frustrated at having to use hours to days of time to do the most basic tasks that were easy even when I was barely beginning with the whole programming thing almost a year ago.
So my question. Are there others out there like me? Are there perhaps nice blogs or articles opening all this up to people like myself? Is ASP.Net MVC just something that is so hardcore advanced that you NEED to have extensive experience and talent to actually master it?
Thanks for your time.
It's not for advanced developers. It is for good developers.
Most ASP.NET WebForms developers have made it somehow through years without having a slightest idea of HTML, CSS, JavaScript or HTTP. Drag and drop some control, set up some properties and here you go. It is not the way of a professional. You need to know the basics. It is only a matter of time until some situation arrives where a standard control cannot help and you need to work around the postback mechanism, viewstate etc.
I agree that it is definitely more work trying to implement an editable data grid, add persistance for controls, add some nice Ajax effects instead of relying on UpdatePanels, yes. But you really need to know this stuff if you wish to be working as web developer.
What you are experiencing is being overwhelmed at once by all those things you should have learned already but have managed to postpone thanks to very well done abstraction mechanism of WebForms. The best course of action is to start learning these things now, step by step. It will likely take you at least 6 months of intensive studies to feel more or less confident with doing stuff manually. But when you have done this, you will be looking back at your start and feeling glad you did it.
I was trying to work out what the problem was with MVC until I grasped the essential difference between the person asking the question and me - it would be this, I first laid hands to keyboard in 1979 whereas Zan has been "working as a software designer for almost a year now".
When I started one more or less had to do everything (at least in terms of presenting a UI) from scratch - or at least using far more limited toolkits than is the case today. The notion of constructing a drop down list by running a loop to create the options is in some respects considerably less alien to me than binding a datasource to a control and having the result appear as if by magic (notwithstanding 9 years of VB.OLD and over 6 years of .NET and C#)
And that is the core difference between Forms and MVC as it currently stands - the way you produce the presentation code and consequently the fact that you need to understand HTML and do seemingly more work to achieve similar results (and this is one of the reasons that people keep emphasising, quite rightly, that MVC is NOT an appropriate solution for every project). In terms of the structure of an application - MVC encourages a better (more testable) style but its not the only means to achieve that end - the majority of the techniques are as applicable using forms and alternative patterns.
And again this raises the challenge of contemporary frameworks and tools - they do a huge amount of work for you (go look at Dynamic Data for example) but they also hide so much from you that we lose track of the fundamentals and of an understanding of the basic building blocks from which our complex applications are constructed. In this case the problem sounds like one I've had which is learning about the nuts and bolts how a web page is actually constructed (HTML, CSS, Javascript) and how it interacts with the server as opposed to just having the whole client experience automagically generated for you.
MVC is no more a tool for "good developers" than Forms is - rather its a good tool for developers that wish to achieve a particular result albeit one that comes with a price just as forms is also a good tool but with different outcomes because you're accepting a different set of compromises.
A good developer is one that can adapt - can learn the new techniques necessary to work on a different platform, to target new environments, to use appropriate solutions for a particular task and ultimately that can apply solid patterns and methodologies to their work in so far as is possible whatever the dev environment...
i also spend one year on mvc what i learn till now is u can rely on client side as much as u can but in classic asp.net most of time u used server side controls like gridview. In asp.net mvc u can replace it with jquery controls like jQgrid and jquery datatable. you must have to spend some time to learn asp.net mvc the it might looks u better then asp.net classic.
for reference read asp.net mvc pro book
MVC is not a new concept; in fact other languages have this kind of framework long before Microsoft got it. Think about Ruby On Rails, Zend Framework, Symfony etc.
If you say that MVC is for the hardcore and the alpha geeks, then by your logic other language developers are much more advanced than .Net developers. I don't think this is true.
Your problem with MVC stems from your webform background; ASP.Net and ASP.NET MVC greatly differ in terms of concepts and approach. So some unfamiliarity is expected for those who are moving from one framework into another. Me, on the other hand, who has no webform experience ( although I do have winform experience), don't find MVC hard to grasp.
And I don't think I am smarter than anyone else.
All i can suggest is that you need to do more of it! The more you practise, the more it will become clear. That's how it was for me. I was fundamentally stumped by the MVC concept to start with but after much frustration i just decided i would need to force myself to start using it or i'd never get it.
I'd recommend actually completing one or two of the tutorials found on the asp.net/mvc site from start to finish. I can personally recommend the NerdDinner (and the book from which this example was birthed - Pro ASP.NET MVC 1.0) and Storefront tutorials.
ASP.NET MVC is built on top of bunch of old concepts - HTTP, HTML, CSS, JavaScript. And so on. The whole point is to bring their power directly to your hands. If you can't handle this power - for example, you're not familiar with HTTP statelesness, or how to build rich pages with HTML/CSS/JS - you can't do much with ASP.NET MVC.
If you say that you're in programming for only one year then you're most probably not familiar with those concepts and that's the problem, not in the MVC itself.
Maybe you take ASP.NET MVC as a refinement of ASP.NET. That's wrong. They're VERY different. Imagine yourself doing web development with only HTML, CSS, and jQuery [1]... can you? If you can't then you will have troubles doing MVC.
I personally worked with ASP.NET for couple of years, and ASP.NET MVC was a breath of fresh air. It's just so much simpler and cleaner.
[1] This can be done, for example with data fed via web services.
MVC is great but the argument that it makes you happy by finally giving you the power of HTML, CSS and Javascript is real crap. The same logic would say: code in pure SQL and forget nHibernate or Linq. Why is abstraction bad? I like MVC but please don't use such arguments. MVC needs something to be able to build complex rich user interfaces (which are browser compatible).
Finally, on HTML, CSS and Javascript. The fact that MVC forces you to go back to the basics does in now way mean that the developers do it right. Whether you use web forms or MVC, a bad JS developer stays a bad JS developer (and same for HTML or CSS).
Sometimes it is better to not give too much power to the weaker developers in a team.
I've got to do some significant development in a large, old, spaghetti-ridden ASP system. I've been away from ASP for a long time, focusing my energies on Rails development.
One basic step I've taken is to refactor pages into subs and functions with meaningful names, so that at least it's easy to understand # the top of the file what's generally going on.
Is there a worthwhile MVC framework for ASP? Or a best practice at how to at least get business logic out of the views? (I remember doing a lot of includes back in the day -- is that still the way to do it?)
I'd love to get some unit testing going for business logic too, but maybe I'm asking too much?
Update:
There are over 200 ASP scripts in the project, some thousands of lines long ;) UGH!
We may opt for the "big rewrite" but until then, when I'm in changing a page, I want to spend a little extra time cleaning up the spaghetti.
Assumptions
The documentation for the Classic ASP system is rather light.
Management is not looking for a rewrite.
Since you have been doing ruby on rails, your (VB/C#) ASP.NET is passable at best.
My experience
I too inherited a classic ASP system that was slapped together willy-nilly by ex excel-vba types. There was a lot of this stuff <font size=3>crap</font> (and sometimes missing closing tags; Argggh!). Over the course of 2.5 years I added a security system, a common library, CSS+XHTML and was able to coerce the thing to validate xhtml1.1 (sans proper mime type, unfortunately) and built a fairly robust and ajaxy reporting system that's being used daily by 80 users.
I used jEdit, with cTags (as mentioned by jamting above), and a bunch of other plugins.
My Advice
Try to create a master include file from which to import all the stuff that's commonly used. Stuff like login/logout, database access, web services, javascript libs, etc.
Do use classes. They are ultra-primitive (no inheritance) but as jamting said, they can be convenient.
Indent the scripts properly.
Comment
Write an external architecture document. I personally use LyX, because it's brain-dead to produce a nicely formatted pdf, but you can use whatever you like. If you use a wiki, get the graphviz add-in installed and use it. It's super easy to make quick diagrams that can be easily modified.
Since I have no idea how substantial the enhancements need to be, I suggest having a good high-level to mid-level architecture document will be quite useful in planning the enhancements.
On the business logic unit tests, the only thing I found that works is setting up an xml-rpc listener in asp that imports the main library and exposes the functions (not subroutines though) in any of the main library's sub-includes, and then build, separately, a unit test system in a language with better support for the stuff that calls the ASP functions through xml-rpc. I use python, but I think Ruby should do the trick. (Does that make sense?). The cool thing is that the person writing the unit-test part of the software does not need to even look at the ASP code, as long as they have decent descriptions of the functions to call, so they can be someone beside you.
There is a project called aspunit at sourceforge but the last release was in 2004 and it's marked as inactive. Never used it but it's pure vbscript. A cursory look at the code tells me it looks like the authors knew what they were doing.
Finally, if you need help, I have some availability to do contract telecommuting work (maybe 8 hours/week max). Follow the link trail for contact info.
Good luck! HTH.
Since a complete rewrite of a working system can be very dangerous i can only give you a small tip: Set up exuberant tags, ctags, on your project. This way you can jump to the definition of a function and sub easy, which i think helps a lot.
On separating logic from "views". VBScript supports som kind of OO with classes. I tend to write classes which do the logic which I include on the asp-page which acts as a "view". Then i hook together the view with the class like Username: <%= MyAccount.UserName %>. The MyAccount class can also have methods like: MyAccount.Login() and so on.
Kind of primitive, but at least you can capsulate some code and hide it from the HTML.
My advice would be to carry on refactoring, classic ASP supports classes, so you should be able to move all everything but the display code into included ASP files which just contain classes.
See this article of details of moving from old fashioned asp towards ASP.NET
Refactoring ASP
Regarding a future direction, I wouldn't aim for ASP.NET web forms, instead I'd go for Microsoft's new MVC framework an add-on to of ASP.NET) It will be much simpler migrating to this from classic ASP.
I use ASPUnit for unit testing some of our classic ASP and find it to be helpful. It may be old, but so is ASP. It's simple, but it does work and you can customize or extend it if necessary.
I've also found Working Effectively with Legacy Code by Michael Feathers to be a helpful guide for finding ways to get some of that old code under test.
Include files can help as long as you keep it simple. At one point I tried creating an include for each class and that didn't work out too well. I like having a couple main includes with common business logic, and for complicated pages sometimes an include with logic for each of those pages. I suppose you could do MVC with a similar setup.
Is there any chance you could move from ASP to ASP.Net? Or are you looking at keeping it in classic ASP, but just cleaning it up. If at all possible, I would recommend moving as much as possible moving to .Net. It looks like you may be rewriting/reorganizing a lot of code anyway, so moving to .Net may not be a lot of extra effort.
Presumably someone else wrote most or all of the system that you're now maintaining. Look for the usual bad habits (repeated code, variables that are too widely scoped, nested if statements, etc.), and refactor as you would any other language. Keep an eye out for recurring things in the same file or different files and abstract them into functions.
If the code was written/maintained by various people, there might be some issues with inconsistent coding style. I find that bringing the code back into line makes it easier to see things that can be refactored.
"Thousands of lines long" makes me suspicious that there may also be situations where loosely-related things are being displayed on the same page. There again, you want to abstract them into separate subroutines.
Eventually you want to be writing objects to help encapsulate stuff like database connectivity, but it will be a while before you get there.
This is very old, but couldn't resist adding my two cents. If you must rewrite, and must continue to use classic ASP:
use JScript! much more powerful, you get inheritance, and there some good side benefits like using the same methods for server-side validation as you use for client-side
you can absolutely do MVC - I wrote an MVC framework, and it was not that many lines of code
you can also generate your model classes automatically with a bit of work. I have some code for this that worked quite well
make sure you are doing parameterized queries, and always returning disconnected recordsets
Software Development Project Management practices indicates that softwares like this are requiring to retire.
I know how hard it is to do the right thing, even more when the responsible manager knows sht and is scared of everything other than the wost way possible.
But still. It's necessary to start working on the development of a new software. It's simply impossible to maintain this one forever, and the loger they wait for retiring it the worse.
If you don't have proper specification/requirements documentation (I think no asp software in the world does, given the noobatry hability of those coders), you'll need both a group of users that know the software features and a manager to be responsible for validating the requirements. You'll need to review every feature and document its requirements.
During that process you'll go learning more about the software and its business. Once you have enough info, you can start developing a new one.