Probably the big question here is "Why Active Docs?". You say the application is going to be web based. This raises the bigger question, "How are you going to get at your data?".

If this is an application for an Intranet, well then no big deal. If you can guarantee the environment, you can access data pretty much the way you are used to, either with file shares or ODBC/OLE DB for remote data. But if it's an Intranet app with the client doing all of the work, I'm not sure what the big advantage to ActiveDocs is. A lot of people use the term Web-based with "In a Browser" interchangably and if it's just a local app there's really no advantage to running "In a Browser" except a common entry point to the application. Plus there are many liabilities in terms of overhead and architecture.

On the other hand, if it's an Internet app or if you're trying to move the work off of the client, ActiveDocs are a possiblity. Certainly an ActiveDoc provides more UI possibilities than HTML/JavaScript, although it also puts more demands on the client. However, with an Internet app you need to decided on a transport mechanism for the data. It's probably not a good idea just to share a directory on your server and use that directly via the Internet - besides poor performance it's also a Security risk. Plus you'll have naming issues, especially when you have anonymous users you don't have access to a DNS that names your server. You could use remote data (ODBC/OLE DB), but then you have DSN issues.

The best solution is probably to use your Web server to pass the data back and forth. In which case you have to convert it into a text-based format so that the Web server can return it to the client intact. Two possiblities are XML and Rick Strahl's West Wind WWIpStuff (http:\\www.west-wind.com).

I've implemented ActiveDocs using Rick's stuff to do things like get at the contents of general fields via the Web, or provide complex controls (Rich Text Box, for example), and it worked pretty well. I've also used XML to pass data from a Web Server to a VFP Client, and that worked well too. But before you decide what architecture to pick, you should look at your apps requirements. You can do an awful lot even with just ASP (including use VFP COM objects, although that will work better in a later revision of VFP), HTML, and Scripting instead of taking the hit of using ActiveDocs. I generally use these things in combination with VFP COM objects to model objects in the "Middle Tier" and either provide access to data from ASP or generate HTML directly.

>Hi everyone...
>
>My question is this:
>
>Do I have to decide to build an application from the inception based on the Active Documents base class to generate Active Documents and move the application to the web?
>
>
>My concern is this. I have already created tables and made all my joins as if I were creating a desktop application. I have not made any attempt to create active documents. I have not created any forms yet. I guess what I am aksing, is if I am still in a position to create active documents and make it all work, without starting over. I have never done this before, so it's like walking in a pitch black room searching for a door. I guess that is half the fun... finding the light after working at it for a while!
>
>The application I am working on is going to be strictly web based, and I am just realizing I need to create Active Documents to have it gel with the browser.
>
>The reason why I am confused is b/c I have a FoxPro book and there is a page or two dedicated to Active Documents. My interpretation on what it is saying is that Active Documents are just like a regular FoxPro application.....just a little different. It is implying they are two distinct applications, created in two seperate ways.
>
>If anyone has had any experience creating active documents, I would sure love to hear any insight you have and the steps you took to make it happen.
>
>Jason