Let's say one has an OI web app, with a mix of static and dynamic pages. Where should the pages be stored?

Some dynamic pages will of course be created from scratch by the app, so they will not be stored anywhere.

For the static pages I assume the natural place to store is as html files in the web server's document directory. But they could also be stored as files anywhere accessible from OI, read by the app with OS(B)Read, and returned to the client. A third possibility is to store the pages' data in the app's tables.

But there might be a third kind of pages, falling inbetween the two: dynamic pages that are made wholly or partly from static bits and pieces. (Or there could even be stuff on a meta-level: instructions on how to assemble such dynamic pages from named pieces.) These static building blocks could be stored as separate files, read by the app with OS(B)Read, perhaps mixed with data from the database, and finally returned to the client. They could also be stored in the app's tables, but again read, mixed and assembled, and returned to the client.

One might want to store all the static stuff in one place - both static html files and building blocks for dynamic pages. This not to spread the components of the app all over. So one might want all the static stuff kept together, either in the web server's document directory, or in some other folder, or in the app's tables.

Btw - stuff stored in the app's tables might not count, since it's together with the main part of the app anyway. So it's not spreading out as in having to keep track of yet another folder. But it's spreading out as in having to do maintenance on data in more than one place. Also this kind of data is easier to maintain if it's kept in plain files outside OI. At least that's what I think.

If everything is stored in a folder outside the web server's document directory, everything must be OS read. But with simple static pages one shouldn't have to do that. It's easier and faster just to use a link. Also static pages can be too long for an Inet function to return.

On the other hand, if everything is stored in the web server's document directory, one might get problems with long folder names (or folder names containing spaces). A web server will often be installed to a folder with long names, and then the server's default document directory will contain long names, causing problems when the app needs to OS read files. One can of course change the web server's document directory to a folder of one's own choice, but that might not agree with other apps already using the server. Neither might one be able to reinstall the server itself to a folder of one's own choice.

Any comments or ideas?

You might think my worries are insignificant, but it's always easier with something that's simple and maintainable and works out of the box, not needing on-site adjustment for each new client.

- Oystein -

Oystein,

For the smaller pages, especially those with a template nature to them, it would be easier to store in a LH table. Sometimes we simply use inserts to bring this kind of stuff in.

You can do the same thing with larger pages, but either way I don't think you can avoid a certain amount of maintenance. I'm sure Sprezz or WinWin has done more Web stuff than we have and can offer more insight to this issue.

Ultimately, though, if you are constructing large HTML returns then this does dictate how the page gets sent back. As you know, OICGI can only return up to 64K (probably less) whilst Sprezz's S/Web overcomes this easily.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don - thanks for the response!

All you others - don't be shy!

- Oystein -

[notag]Most of the time we'll have all the pages generated through SWeb. Some very static pages and images we might keep loaded on the server itself.

Generally we load pages through SWeb so we can ensure it's not cached anywhere, especially on data entry pages.

Most of our stuff has swapout settings, so IMAGE/mygif.jpg or something, with SWeb autoswapping out for the proper location. Works just as well on DOCS/somedoc.htm. This way, if anything is moved, we make a single change in an INI file, and the server can always find the doc.

[<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Click here to visit our web site?';return(true)">The Sprezzatura Group</A>]

[<I>World Leaders in all things RevSoft</I>]

[<img src="http://www.sprezzatura.com/zz.gif">]

[<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0"}end hiding from non-JS browsers –></script>] [<FORM ACTION "" METHOD=GET NAME="TOCNavigator" <SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()"> <OPTION>Pull down this menu to choose whereabouts on the Sprezz site to go <OPTION VALUE="http://www.sprezzatura.com">Home Page <OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New <OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL <OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST <OPTION VALUE="mailto:support@sprezzatura.com">Send mail to support at Sprezzatura <OPTION VALUE="mailto:sales@sprezzatura.com">Send mail to sales at Sprezzatura </SELECT> </FORM>][/notag] </QUOTE> —- === At 23 NOV 2000 05:57PM Oystein Reigem wrote: === <QUOTE>Sprezz, Most of the time we'll have all the pages generated through SWeb. Some very static pages and images we might keep loaded on the server itself. Strange expression - "very static". But I think I see what you mean. Generally we load pages through SWeb so we can ensure it's not cached anywhere, especially on data entry pages. Now you're talking about possible problems with static pages. Why do you really need to reload them? Not because their content changed. But because they're not "very" static. They contain a script that needs to be run again. Or? Most of our stuff has swapout settings, so IMAGE/mygif.jpg or something, with SWeb autoswapping out for the proper location. Works just as well on DOCS/somedoc.htm. This way, if anything is moved, we make a single change in an INI file, and the server can always find the doc. I use some INI-oid and swap tactics myself. Are you mentioning this as a way to get around the problem with long file names? - Oystein - </QUOTE> —- === At 24 NOV 2000 05:01AM The Sprezzatura Group wrote: === <QUOTE>[notag]It's not that we have to reload that page, but perhaps the frame around it. Part of it is consistancy of access. Let's use this site (meaning RTI's) as an example. This is how I would layout the internals. Some other members of the Sprezz collective might have other options. Their opinions are irrelevant <g>. In actually, we would have this page loaded with borderless frames, but it's not, so we'll take the page as is. This response page has the following items: [<TABLE ALIGN="LEFT" BGCOLOR="#FAFFB3" BORDER="1" CELLSPACING="0" CELLPADDING="0" WIDTH="40%"> <TR> <td>A side image map</td><td>Static</td> </TR> <tr> <td>The top image</td><td>Static</td> </tr> <tr> <td>Main input section</td><td>Slightly Dynamic</td> </tr> <tr> <td>Thread Links</td><td>Very Dynamic</td> </tr> <tr> <td>Return to view</td><td>Static</td> </tr> <tr> <td>Bottom Links</td><td>Static</td> </tr> </TABLE>] Slightly dynamic means it's mostly the same, with just some tiny bits modified. Very dymanic means it must be completely generated per page. So, the page would be end up being a table within a table. The outer table would have the left side bar in the first column. The second column would be another table containing the rest of the page. The side bar image links and bottom text links would probably be autoinserted from stored pages. The top graphic would be a img tag. The data entry sections up to the submit button would be entered, with swappable tags for the subject/author/category/date auto-fill. The thread links would be a single swap out. The links sections would be linked in through a function or something. In SWeb, it would just be [<code>www_exec_method( "DOCUMENT", "READ", "HTML", "TEXT_LINKS", docInfo, docProps, docBufferNo, docBufferCount)</code>] [<code> if www_Get_Status( errorText ) then</code>] [<code> abort = TRUE$</code>] [<code> end else</code>] [<code> call www_Exec_Method( "RESPONSE", "SETCONTENT", docBuffer, "+" )</code>] [<code> docBufferNo += 1</code>] [<code> if ( docBufferNo > docBufferCount ) then</code>] [<code> eofDocument = TRUE$</code>] [<code> end</code>] [<code> end</code>] [<code> until ( eofDocument or abort )</code>] [<code> repeat</code>] which would take it on to the end of the current response object we are working with. If we were to do this with frames, the side images would be a single frame, linked in from a straight http call to the server. The bottom text links would be the same. The idea is that in almost all of RTI's pages, these links always appear. So, the links should take the actual content and display them in the center frame. Sometimes, you'll notice, it takes forever to get the side image to re-download. There's no reason for this, if you can avoid it. Using Domino puts an extra wrinkle in this, since these pages are just dynamically created from NSF files. Also, someone at RTI back then hated frames and refused to have the site designed with them. [<A HREF="http://www.sprezzatura.com" onMouseOver="window.status='Click here to visit our web site?';return(true)">The Sprezzatura Group</A>] [<I>World Leaders in all things RevSoft</I>] [<img src="http://www.sprezzatura.com/zz.gif">] [<script language="javascript">function openNewPage () {window.location.href=(document.TOCNavigator.pageToGoTo.options[document.TOCNavigator.pageToGoTo.selectedIndex].value);document.TOCNavigator.pageToGoTo.selectedIndex="0"}end hiding from non-JS browsers –></script>]

[<FORM ACTION "" METHOD=GET NAME="TOCNavigator"

<SELECT NAME="pageToGoTo" SIZE=1 onChange="openNewPage()">

<OPTION>Pull down this menu to choose whereabouts on the Sprezz site to go

<OPTION VALUE="http://www.sprezzatura.com">Home Page

<OPTION VALUE="http://www.sprezzatura.com/whatsnew.htm">What's New

<OPTION VALUE="http://www.sprezzatura.com/senl.htm">SENL

<OPTION VALUE="http://www.sprezzatura.com/patches.htm">Download S/LIST

<OPTION VALUE="mailto:support@sprezzatura.com">Send mail to support at Sprezzatura

<OPTION VALUE="mailto:sales@sprezzatura.com">Send mail to sales at Sprezzatura

</SELECT>

</FORM>][/notag]

View this thread on the Works forum...