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).
Related
Just got a new website project for my company internal use. The whole website isn't that complicating but requires quite a lot of real time interaction. Basically, it's an interactive time line table where we can freely drag and drop each elements to move and resize them.
At first I wanted to use this opportunity to learn Python+Django (I'm given a huge amount of time) but then I read around and a lot of people mentioned Rails is better for creating rich interactive website.
So, for a website with a lot of drag & drop interaction like this, is Rails really the better choice? Is Rails built-in ajax that much easier to work with compare to Django+jQuery? How flexible and customizable is Rails' built-in ajax? I want to learn RoR just as much as Python by thee way.
I don't think AJAX functionality will define which framework you find yourself preferring.
I can't answer most of your question relating to ajax, but still think this post could be useful for you: it's highlighting a huge difference between ROR and django -- mainly RoR uses magic, django doesn't.
I prefer django for exactly that. Others may prefer RoR for the same reason I don't.
What's wrong with "magic"?
Rails' developers are of the opinion
that this sort of "magic" is a good
thing because it makes it easier to
quickly get something working, and
doesn't bore you with lots of details
unless you want to reach in and start
overriding things.
Django's developers are of the opinion
that this sort of "magic" is a bad
thing because doesn't really save all
that much time (a few import
statements isn't a big deal in the
grand scheme of things), and has the
effect of hiding what's really going
on, making it harder to work out how
to override stuff, or harder to debug
if something goes wrong.
Both of these are, of course, valid
stances to take, and generally it
seems that people just naturally
gravitate to one or the other; those
who like the "magic" congregate around
Rails or frameworks which try to
emulate it, those who don't congregate
around Django or frameworks which try
to emulate it (and, in a broader
sense, these stances are somewhat
stereotypical of Ruby and Python
developers; Ruby developers tend to
like doing things one way, Python
developers tend to like doing things
another way).
So I think one will click for you regardless of out of the box ajax support.
Speaking as someone who mostly works on Rails, I would say take a day with each framework, follow a "getting started" screencast or tutorial, or pick up a book. ( For rails, I recommend Beginning Rails 3 ). Then, keep going with whichever one you feel more comfortable with.
One amazing resource rails has is Railscasts. Railscasts almost single-handedly converted me from PHP to ROR. I don't know if Django has a similar volume of quality screencasts available or not.
All frameworks are pretty heavily focused on the server-side of the equation. Now, Rails has a lot of things that help make writing views (your drag and drop stuff) nice, such as HAML (a fantastic template language)... and while I don't know enough to post links I'm sure Django has similar helpers. It's worth noting that both Django and Rails can use jQuery or any other javascript framework.
But, in the end, just by the nature of the web as stateless, there's going to be a degree of independence between your client-side templates and javascript, and what's serving that from the server side.
The real question you should probably be focused on is: Do you want to become a jQuery ninja, or do you want to scale up a notch and focus on Javascript itself, perhaps using tool suites like MooTools or Prototype. Your drag and drop stuff is client-side, so that's where your toughest decisions will have to be made.
Good luck!
I used to worry about things like this and would try new frameworks all the time because people would say it was a big improvement over the last one I was using until I realised I wasn't doing anything. Now I just pick one and stick with it. The fact that I know it much better than any others means I am more productive, even though the other frameworks probably include nice little tricks and shortcuts, and because I know it better I can debug problems faster.
Basically what I am trying to say is that just about every popular web framework can do everything that you want it to. Some are better than others but what really matters is that you become an expert in at least one of them. Being able to dabble in lots is not helpful, you really need to know one inside and out. Committing some code to the project helps this process.
Mainly depends on which programming language you prefer to work and most comfortable with. Some prefer the flexible syntax of Ruby others like the cleanliness of Python. Also need to take into consideration the production environment (aka what OS is it going to be hosted on).
Django does not do interactive web applications, it is agnostic to the whole "frontend" part, this is done in Javascript with little to no support from Django (except for transferring data from AJAX calls).
So if you want to use Django for this, you will have not only to learn Python but also to learn loads of Javascript.
I like this solution as hand-written Javascript feels a lot clearer than any of these generating tools to me, plus there are plenty of libraries that make writing advanced Javascript GUIs a breeze these days, check out Jquery UI or ExtJS.
From there, the server side will only be AJAX calls that (de)serialize data in JSON, nothing else.
Both Rails and Django are good. Try them both out and see which you like better.
How much does it matter what server side language is used for building a web app to take advantage of HTML 5? It seems to me that the ruby community will probably have the fastest uptake, and as a result the most support. Does that seem right? If I want to make a serious investment in HTML5, what server side language should I use?
It doesn't matter which server-side language you use, they all support HTML 5.
You just have to make sure you write good markup that can be validated.
You will gain experience writing HTML as you build more complicated web applications with server side languages. I'd focus on one of those first and let the HTML come to you as you need it.
One of the best ways to learn is by validating existing HTML and fixing all of the errors and warnings. This will help teach you the common mistakes made when writing HTML and get you more familiar with the rules.
As far as server side languages go, you have several options and there are tons of resources already online to help you make the right decision.
http://articles.sitepoint.com/article/server-side-language-right
http://forums.whirlpool.net.au/forum-replies-archive.cfm/90884.html
It's all about picking the one that is right for you. And, the best part is, if you pick a language that doesn't suit you, you can learn a new one later.
Also, here is some information on Books for Server Side Languages which may prove helpful.
It doesn't matter at all.
Whatever server side platform you use should not be based on what revision of HTML you will render. The two are completely decoupled. That is unless you opt for some framework that generates the HTML for you.
The server-side language you use has no bearing on HTML5.
Presentation frameworks, if you opt to utilize one, may take a while to take full advantage of HTML5.
I agree that the server side language may not matter much, though any framework you choose such as django or Ruby on Rails will hopefully have html helpers that you can use to build a view.
FWIW RoR 3.0 outputs valid HTML 5
http://guides.rails.info/3_0_release_notes.html
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.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have BS in Computer Science, and thus have experience developing software that runs at the command line or with a basic GUI. However, I have no experience making real, functional, websites. It has become apparent to me that I need to expand my skills to encompass web development. I have been using Ruby to develop applications, but I am aware that it is quite popular for web development. I want to use my skills as a programmer to assist me in developing a personal website for a band.
I have experience with HTML, but very little with CSS. I want to leverage my skills with programming languages to create a website containing pictures, audio clips, a dynamic calendar, a scheduling request tool, and other features common to band websites.
What kind of resources are available for a competent desktop programmer to learn the entire process for developing a website? Is it best to use free CSS templates and WordPress as a foundation for my site or make it from scratch? Should I use GUI tools or write it all in Vim/Emacs? Is Ruby on Rails sufficient for my personal website, or should I consider a more mature development platform?
My main goal for this project is to come up to speed on current web design technology, and actually understand the entire process for building a website.
I think one really important thing to understand in web development is HTTP. HTML and CSS are important, but I think it's more critical to understand the stateless nature of the web, and how each of the HTTP verbs work, and what they can/can't do.
http://www.freeprogrammingresources.com/http.html
A good tool for seeing how HTTP works is Fiddler.
If it's as much a learning exercise as anything then take an iterative approach. Build revise. Build revise. My (very) rough guideline below:
Client
Start with the structure of a website and concentrate on the client.
Use notepad and build a bunch of static pages for your band. i.e. Hand code initially. Try to build all your pages with CSS. No table markup. Then play around with some Javascript to bring things to life. (Navigational menu\ Calendar selections\etc). Learn about how to import and link to Javascript and CSS files.... and how these files are treated re:caching etc.
Try to learn up to the limits of what you can do on the client (generally). Factor in the nuances of 3-4 browsers (Firefox/IE6/IE8/Chrome) re:DOM and client side eventing.
Server
Then start looking for what you might want to change across pages/sessions. i.e. what needs to be manipulated server side. And pick a server side technology.
Start with basic post-back processing. Forget databases at this point. Learn how your framework of choice maintains state..... not just the name of the technology but the real nuts and bolts of it. One of your single greatest assets as a web developer is understanding the state model(s) of the technology you're using.
Then go for a deep dive on the web server technology of choice (and in general). Understand the full request pipeline from client to server and back. This will teach you forms, http and its verbs, web server, filters and modules, server to framework hand off, page and control life cycles, back to the client.
Now start working on dynamic content injection and the like. How to make and use reusable components in your web pages.
Databases, caching, performance and diagnostics.
Then get into into all the fun stuff like ajax, etc. Replace your javascript with jQuery, etc.
Then you got the whole Webservices\XML\JSON\etc side of things to discover.
Resources
Well the web obviously. For client side stuff, going to the sites of companies who make third party web controls can be quite interesting. Asking how the hell they did that? Viewsource is your friend. Look at how they structure and build their pages. Pick a couple of good web designer sites, and you find a plethora of rants about browser wars etc that will give you good (under the hood) info.
Once you hit server side, I'd go for white paper type learning from your vendor of choice for your technologies.i.e. webservers/frameworks/etc. Again find a 3rd party howto/evangelist site (I used to use a lot of "4 guys from Rolla" for example) that will demonstrate how to do various things. Language learning is ongoing. Basically just do the best you can till you find a better way.... and always be on the lookout for a better way.
You really need to understand html, forms and css to get anywhere. I say forms as this will give you the round trip needed to understanding the stateless nature of web dev.
To further labour the point, I have interviewed many people who think you can only have one form on a page and can only have one submit button per form. This is all down to a lack of foundation knowledge.
So for that I'd recommend starting with htmldog.com.
After that, a lot of web development is done with frameworks. Gone are the days where you do it yourself (well mostly) but my above point still stands. You do need to be able to peep under the hood with some confidence.
I've been doing web development for 12 years and started out with Perl on Solaris and Linux. Since then I've also done Java and more recently ASP.NET. However, I'm slowly falling for Django in my private projects.
What I've found over the years is that the inherent problems - cookies, javascript, presentation, state, authentication are all the same but just handled differently. So ultimately its down to you and your language preference. Plus a little of enlightened self interest when it comes to potential employment.
Programming aside, you should also become familiar with web servers (Apache and IIS spring to mind), Http codes and headers, Mime types and encoding and FTP. As well as Javascript (mentioned already), plugins, browser platforms and good development practises such as using Firebug, Fiddler and so on. It also wouldn't hurt to have a good idea of the image formats available, image optimisation, CSS sprites, content compression, caching and the like.
All depends on where you want to start!
For a newbie, I'd pick Django and (obviously) Python. Good, clean language with cheap startup options, low cost IDEs (ie free) and hosting your sites is very affordable.
But that's just a subjective opinion.
If your goal is to
My main goal for this project is to
come up to speed on current web design
technology, and actually understand
the entire process for building a
website.
Then start from scratch in Ruby, PHP, Java, ASP.NET, etc...
When you run into a design problem or just want to know how others have approached something, then look at the frameworks.
Once your up to speed, and your website is starting to grow, then segway into a framework, to get up to speed on the frameworks.
I agree with John on this one.
As you know from your own experience in pursuing your BSc, understanding the basics of any language is what makes you even more capable in expanding that knowledge or specializing.
With that in mind, it would be best to understand the basics of HTML and CSS.
Understanding the syntax and overall language will help in the future when you want to pursue large projects using frameworks like Django and Rails. The basics will also especially help with tweaking CMS' like Wordpress to be more customizable to your needs.
One thing in particular that I'd like to mention is that web programming, like many other forms of programming has its own special structure and "proper" way of doing things.http://www.w3.org is a great way to ensure that your work is passing general web design standards, most sites don't follow this because it is tedious, but from a learning perspective it ensures that you get a nice strong foundation.
www.w3schools.com is also a great resource for detailed help on web programming. Lastly, I like colourful code, so I like using basic text editors such as notepad++ or notepad2 or gedit to do my web coding. GUIs like dreamweaver may tend to fill up your code with extra junk and spaces, so I don't recommend them, but they are still great tools.
Don't bother with Rails yet -- write CGI scripts in Ruby. It will be very similar to what you have done for class.
After you have about thirty of those under your belt, you'll know what you want out of a web framework.
I'm a Computer Scientist and a web programmer and I would suggest you learn both HTTP and CGI:
CGI Made Really Easy
HTTP Made Really Easy
As the titles of the above tutorials claim, they made the concepts "really easy" for me.
Once you've got CGI and HTTP down pat, I'd suggest checking out following sites that provide a wealth of articles and references for web programming:
webmonkey
w3schools
Mozilla Developer Center
Assuming you want to concentrate on writing web apps, then Perl, PHP, Python and Ruby are all fine choices (I myself use Perl predominantly) and I'd suggest doing some research into the popular web frameworks available for each language.
Most importantly, pick something simple as your first web app, e.g. a form and a page that shows the results of submitting that form. Some good examples (using Perl's CGI module) can be found here:
CGI.pm - a Perl5 CGI Library -- see the first set of links on this page.
When you want to start writing web apps that use a database, read up on SQL and popular libraries/modules in your chosen language for database manipulation, especially ORM (Object-Relational-Mapping) interfaces that allow you to deal with records in an Object-Oriented fashion.
Good luck with it! Being a web programmer is fun because your audience is teh intarwebz! :)
If you are starting from scratch as per John MacIntyre's suggestion, you may lean towards PHP. With all of its shortcomings, it does have one really good user manual. It is also easy to get started with and is installed on pretty much every host and goes well with Apache.
Also, w3 schools is good to begin learning about CSS and XHTML but don't forget to check out the specs at W3C.
Also, please read this Stack Overflow question & answers.
For what you're describing, Rails or Django might be slight overkill but it wouldn't hurt to learn them. Django, in particular, might be good because of the notion of a project containing multiple apps (e.g. calendar).
Whether you use a framework or write everything yourself, though, you'll need to know HTML and CSS. CSS is extremely simple if you have a BS in CS...you could read a tutorial and know it in five minutes.
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.