http://www.softvelocity.com

The Clarion ASP and PHP templates are similar enough to each other that I can cover them together. These products allow you to generate ASP or PHP code (respectively), which can be used by a commercial web server (IIS, Apache etc). Using a set of templates, and by using information in the dictionary, they are more productive than coding ASP or PHP by hand.

The main advantages of these templates are:

1. They generate the web site using very main-stream languages (namely ASP and PHP). You will find hosting ASP or PHP sites, at commercial providers, easy to do – and ISP’s will gladly assist you in setting them up.  If you are targeting a very high volume web site, a single one-off site, and if you do not have your own “internet server” then these templates should be strongly considered.
2. They use very well established technology as their “base”. For example IIS or Apache.
3. Of all the solutions listed here, the PHP templates are the only ones that can be run from a Linux server. All the other options require Windows on the server.

The main disadvantages of these templates are:

1. They generate “programs” written in native ASP or PHP code. This implies that you either need to know, or learn, one of these languages in order to make best use of the templates. Note that you do not have to know these languages to get stuff done, just as you don’t need to know the Clarion language to write Clarion apps, but it does help enormously, and realistically you will need to at least be able to read the code in order to code sophisticated apps. A basic knowledge of HTML is almost certainly required, especially as you will use this to control the overall “look” of the site.
   
2. Both template sets use ADO as their data source, and hence limit the data files you can use in your app.  This may, or may not, be a problem depending on what backend you are currently using.
   
3. Deploying at your ISP means the database must reside at your ISP. If you are dealing with a situation where this database becomes a “copy” of another database (which might be on your LAN) then you have to deal with synchronization issues.
   
4. Because they rely on “other” software, installation and configuration can be an issue. If you intend for users to deploy the system themselves, or with minimal assistance, then the deployment overhead may be significant.

I would use these templates in situations where:

1. I am reliant on commercial ISP’s for hosting.

http://www.softvelocity.com

Although it ships in the box in the Enterprise Edition, the Web Builder templates are often overlooked.

The main advantages of these templates are:

1. They take an existing application, and webify it. Thus, if you have an existing app, the time required from start to finish could be extremely short. In many cases no more than a few minutes.
   
2. The code underneath the app is written in Clarion. Thus no extra language skills (other then HTML) are required.
   
3. It delivers the same interface via your web site as via your Windows 32 bit program. People familiar with your Windows app will be comfortable straight away with the interface.
   
4. As it is a Clarion program, it can use any data source available to any clarion program, including TPS, SQL, ODBC etc.
   
5. The client-side interface is a Browser. (Compared for example, to the IP driver or ClarioNet where the client side is a Clarion program.)

The main disadvantages are:

1. It requires the proprietary Application Broker (50 user version included in Clarion, larger use version available separately).  In a public-web sense this means you will need your own internet server (either hosted yourself, or co-hosted at an ISP). For most sites hosting it yourself on DSL or ADSL is certainly an option.
   
2. It delivers the same interface via your web site as via your Windows 32 bit program. It’s quite possible that this will be overkill for what you are trying to achieve. Also the “feel” of the site will not be web-specific, it’ll “feel” like a windows app trying to run in a browser.
   
3. The Application Broker has a (possibly unjust) reputation for being unreliable. I say “possibly unjust” because I believe the Clarion 6 version is a lot more stable than its predecessors. I have not personally used it myself in a commercial setting, so I cannot comment on that front.
   
4. Web Builder requires a stateful connection between the client and the server. This makes it somewhat intolerant of broken connections. I’ll discuss the concept of Stateful, and Stateless, approaches in the next chapter.

I would use the WebBuilder approach when:

1. A customer wished to experiment with web access to the program, but without spending a lot of money .
   
2. A small number of users wished to access my program remotely, with the same feature set offered by the Windows 32 bit application and,
   
3. If I was targeting an intranet, rather than public web site, or if I was targeting a small-volume public web site.

http://www.capesoft.com/accessories/netsp.htm
http://www.cwhandy.com

These two 3rd party add-ons approach the problem from a similar point of view. They are similar enough to discuss together.

They both adopt the position that a Clarion program itself can be a web server. There is no need for a supporting product, thus no IIS, Apache or Application Broker. This makes deployment a lot easier. However, by not using PHP they are Windows bound, and worse, they create proprietary programs (i.e. an Exe) and these are not likely to be run by an ISP on a shared machine. Thus if you are creating a public web server you will require your own server.

Unlike WebBuilder your existing app interface is not utilized. You will need to build the web interface from scratch, one page at a time. However this also allows you to build the interface specifically targeted at the Browser audience. In my experience this is a different set of users to the ones running the Win 32 bit app, and thus has different requirements, and expectations to the existing Windows users. Most of all though your web interface will look like a web interface.

Main advantages:

1. Deployment. Since the program is the server it’s as easy as running the install program. Everything can be contained inside your Clarion Exe. It can run on the user’s work-station, or on a server. If you like you can embed literally everything inside your exe.
   
2. Support is easier because there are no external dependencies to worry about.
   
3. Code is 100% Clarion. HTML knowledge is recommended – especially if you wish to customize the “look” of the site. However you can get going without HTML if you need to.
   
4. You can use regular web-site page designers (for example Dreamweaver, or Frontpage) to design your pages.
   
5. Leveraging the supplied NetTalk templates makes you a lot more productive than coding by hand. There are templates for Menus, Browses, Forms and so on.
   
6. NetTalk uses a stateless approach on the server, which translates into far fewer resources being required by the server, even if multiple people are using the site simultaneously.

Main disadvantages:

1. You’re creating a proprietary program. So expect to use your own server, either co-located at an ISP or served from your own office.
   
2. Your customers may raise security concerns because you’re not using “main stream” technology. However it could be argued that esoteric software is ultimately less susceptible to penetration.
   
3. Your existing app interface is not utilized. You will need to build the web interface from scratch, one page at a time.

I would use NetTalk when:

1. I am expecting a large number of installations – typically done by the end users themselves.
   
2. I wish to create a remote management, or remote access to my app without any extra overhead. For example if you are creating a Service then a web interface is encouraged. NetTalk allows you to build the interface directly into your program with very little fuss.
   
3. Where I am unable, or unwilling, to support IIS, or where dependence on IIS would make an additional burden for the support staff.

Incidentally both add-ons offer a lot more than just web serving.

http://www.clarionet.com/
http://thinetsolution.com/

ClarioNet is a lot like Web Builder, except that the client runs a generic Clarion Terminal program instead of a browser. Like Web Builder it uses the Application Broker at the server end, but because the client program is a Windows 32 bit app, the interface is a lot more like the real Windows 32 bit application.
Thin@ is relatively new to the Clarion community, but is rapidly becoming a popular solution. It follows a similar approach to ClarioNet, however it uses a Thin@ broker rather than the shipping AppBroker. It also supports an MDI interface.

Main advantages are:

1. It leverages an existing program, and so the time taken from conception to deployment may be very small.
   
2. It uses a generic client-side app, which only has to be deployed once. After that application updates are done on the Server only.
   
3. It presents an almost-identical interface to the user as the one they experience when running the “real” windows 32 bit app.
   
4. The program is 100% Clarion. Nothing else is required, not even HTML.

Main disadvantages are:

1. (ClarioNet) Like the web builder it depends on the application broker. (See the Web Builder section above for more details.)
   
2. (ClarioNet) It reduces the interface from MDI to SDI and does not support COM controls, or NetTalk.
3. More resources per-user consumed than a web app.
4. Client Exe must be distributed and installed on all client machines.

I would use ClarioNet or Thin@:

1. Where I had a fixed number of known users. I would prefer apps where the length of time each user remains connected is limited. I would need to inspect the program to determine the impact of missing MDI and COM functionality.

http://www.microsoft.com/windowsserver2003/techinfo/overview/termserv.mspx
http://www.citrix.com/lang/English/home.asp

Terminal Server and Citrix deserve a mention, if only because it is so similar to ClarioNet. Where ClarioNet replicates the Application interface at the client, Terminal Server or Citrix replicates the whole Windows desktop at the client.

Main advantages are:

1. It simply doesn’t get any easier from a programmers point of view. If your program runs in Windows it runs in Terminal Server. Your client can implement this approach and there are almost certainly no changes necessary to your program. (Other than the fact that you may have limited the number of copies that can be started on a single machine.)

The main disadvantages are:

1. Cost. Each client requires a license from Microsoft or Citrix.
   
2. Each session takes up considerable resources on the server, for the whole duration of the session. Sufficient RAM for all the users is absolutely essential.

Accessing the database remotely is an option. Using either IP Driver, or SQL technology, it is possible for your Clarion app to access data stored on another machine, with only an IP connection.

Main advantages:

1. Simple to implement.

Main disadvantages:

1. Client-side program required.

http://www.capesoft.com/accessories/replicatesp.htm

I’ll also mention Replicate here (a CapeSoft 3rd party accessory). Replicate is unique in that it allows multiple users to access the data, from remote locations, but without being connected. In other words if the ability to continue working offline is paramount then this is probably the best option.