Brian,
(please don't take offense) .. this is a classic example of solution driving requirements instead of requirements driving the solution. Your 'solution' is patterned after a traditional web site, many, many web pages (.aspx) which, as you noted, results in a complex maintenance process.

You need to get your boss to focus on the requirements and not on how it will be implemented ( I know, easier said than done )

DNN is not page-centric, it's module/data centric. In other words, instead of hundreds of pages that display different 'instances' of data in the same format, you would have a single page that contains a 'module' that would use parameters passed on the querystring to retrieve the appropriate data from the database and display it to the user. Selecting a different college, or department, or professor would result in the same page refreshing but now displaying the newly requested data.

Maintenance is actually much simpler, because all of the data is in the database, there is no data in the pages .. giving you many maintenance options including using scripts to update the data, importing from other sources, or editing the data using the module's admin/settings pages.

DNN can absolutely handle your 'requirements'. What DNN can't do is implement your solution. :)

ok you have to stop thinking about pages and think process - what you want to process
the dnn framework will work - it produces the mechanics of the site display , the processes are the modules in your case.

an example -

I use dnn in an informational site - it allows users to drill down countries,states,towns and what goes on in the towns ie facilities, business, sights etc  the overall process is basically the same as you outline -

I need a module to allow the user to select state, once selected then I need a module that uses the outcome of the state module to select town - once town is selected I need a module to use the output of the towns module to display the town , I need modules to use the town output to display business's within the town etc.

Where I actually put these modules within the site is not of a major concern

Your process is similar -

• module to select state ,
• module to selct college,
• module to select course within colege,
• module to select professor within course etc

at this stage I have not even thought about what page will go were or what modules are on what pages -

I am just manipulating data by the individual modules(processes)

The whole process could be actually placed on one page in the menu - each module calling the next one and overlaying the existing module on the page or you could set up a number of pages ie state (where you select the state, colleges where you select the colleges displayed for that state etc.

Since it is a drill down process it is not logical to browse to a url in the middle or end of the drill down so it is more logical to have the modules use the same page ie you have to start at the start to get to the end.

Remember that in a dymanic site such as dnn each visitor gets a generated page so two visitors on the same 'page' can have totally different content displayed

You have to remember in dnn the pages do not actually exist untill the module manipulates the data in the database and the module displays it. It is not stored as a page on the server and lives only as long as the user requests it.

You must attack this project first by designing the database tables you will need to hold the information - how you want to recall this data will play a part in how you design the tables. Once the tables are designed then you need to build the modules to access the data

You cannot do what you want using DNN without coding modules - if you don't understand the DNN data coding system then I would suggest you use the doodads system available in the MYGeneration software system ( its free) Using the mygeneration templates it will code most of the hard stuff for you.

The approach you are taking is for static pages your 'processes' are the menu navigational system. This is a standard approach for html type sites not a dnn framework site.

>So, under ohio we have a 'physical' page called Colleges.Under Colleges, we may have private and public, and then under each of those pages we have lists of colleges, then maybe departments and then classes, etc. 

this is a static web site approach - to move this to a dymanic site your state page can have any state displayed, your colleges page can have any state colleges displayed etc. the mosule determines for that visitor what is actually displayed  In dnn this is done by the use of modules nd the state page may be the same as the college page and the school page and the professor page each will differ in thier url by the parameters after the default.aspx - in dnn there is actually only one physical  page and that is default.aspx .

Actually what you are trying to do is fairly simple using DNN  and only requires a few simple modules to process the data.