Forum OpenACS Q&A: ADP versus HTML

If...no...when you are building an OpenACS site from scratch with numerous (static) pages consisting of (hopefully) "magnet content" you want to collect comments and links. You ask yourself whether to use .html or .adp pages, or perhaps a mixture. These publishing decisions should be backed-up by some opinions from the community, so for instance:

• To be able to collect comments on .html pages you'll have to sync with Postgres, right? This is beautiful and allows you to add links/comments on .html documents, but no "add a link/comment" will be offered on .adp pages unless you:
  1. stick to the same non-dynamic syntax in your .adp as you would use in .html ("/BODY" being the tag determining where to insert the comment stuff, see /tcl/ad-html.tcl)
  2. register ad_serve_html_page for /*.adp
  The .adp url gets synced allright (given you have the following in the static section of the /parameters file: ns_param IncludeRegexp ".html?$|.adp$") but I for one can't see why you should use .adp's if it weren't for the possibility to call procedures and stuff, like ad_footer for example. And I rather not call some "add_comments_here" procedure manually on every page if there are thousands. Any suggestions on how to best modify ad-html.tcl to enable comments on .adp's that are not using "/BODY" but ad_footer?
  
  
• Also, Don, I read your posting where you said that the (much longed-for) site-wide-search implementation would probably be an out-of-db one. Thats great I suppose, because that would mean I can edit the procedure: ad_check_file_for_sync in /admin/static/static-syncer-ns-set.tcl so that it's not inserting copies of the static pages into the table static_pages. Gosh! I'm relieved (and I'm sure your superb backup script is too 😉 now that there's no need for keeping a copy of each page in the db for full-text indexing. Still, are there any disadvantages with the "out-of-db" search approach compared to PLS and the like?
  
  
• Can Alta Vista and the others index .adp pages? (I guess the answer is yes...)
  
  
• Pros/cons regarding .html/.adp. Thoughts?

Thanks Everyone!

As far as searching goes, the "out of database" comments have to do with whether or not the search index should be stored in the database,  or directly in the filesystem.  As to whether or not the indexing of one's static pages would continue to be done via visiting the static_pages table or not, I don't know.  We'll either have to teach an indexer to search PG tables (bboard, news_items, etc) or teach the scripts or PG triggers how to stuff the indexer's tables regardless of  how we treat static .html pages.

Hi Don!
Regardless of wheter or not the search index is stored in the database, can I just skip stuffing copies of the content pages in the db? Or is that depending on what concept of doing searches is chosen?

Parsing the ADPs before stuffing them into the database sounds like the Right Thing to me. But if you don't feel like branching, this works:

<%= [mab_page_header "<title>Page Title</title>"] %>

...where mab_page_header is some function you've written that strips out the title tags. I hear you gagging, but it does the job. As long as the stuffer sees <title> somewhere, it doesn't care too much about the context.

And of course you can always make your footer function DTRT for General Comments/Links. I agree it would be better to have it all done for you by ad_serve_html_page.

There's also an abstract URL issue here, which I asked about a while ago on the mailing list. I'll reproduce it here:

Another problem in this mess is that the process of stuffing static content into the database includes the extension. Will it be hard to make this play with abstract URLs? My worry is that if an adp is invoked abstractly (without the .adp extension) and it calls gc_insert_comments_here or whatever, that proc won't have a means of determining the actual file name that it's running under (as distinct from the URL), and that as a result it won't find its comments, because they are indexed under the file name, not the abstract URL.

I use abstract URLs for everything, so I would much rather that commments/links were indexed in the database by abstract URL. But I don't really know for sure whether this is broken or not.