Active Pages

Tonight I coded up a very basic "Active Page" framework.  It really does nothing more than let you embed Smalltalk statements in your HTML in <? ?> tags, but it's pretty powerful as it stands.  Not bad for 12 methods (only a few of which do any really significant work).

I've attached a sample SAP and a sites.cnf for playing with this.  Essentially, the SAP itself is used to generate a method on an instance of SwazooActivePage.  SwazooActivePages are instantiated anew for each Request.

There are a couple of issues that I'd like to open for discussion:

Portability
This depends on the Compiler, whose invocation is undoubtedly platform-dependent.  Should we build a platform-specific SwazooCompiler, or should we just plan on tweaking this method in each dialect?

Version Numbering
It seems that people want a x.y.z version scheme, which is fine by me.  For what I'm doing, the version number in StORE is enough, but I'd be glad to accomodate a different scheme. So should I have rolled the revision (HTTPServer class>>version) to 0.50.1?

Comments are appreciated, fire away...


Ken



<Site>
 <SiteIdentifier ip: '192.168.1.254' port: 8081 host: 'message'>
 <Swazoo.SwazooActivePageResource stringUriPattern: '/' filePath: 'Sites/test/' directoryIndex: 'index.sap'>
</Site>

Hi Ken,

Nice work!

> *Portability*
> This depends on the Compiler, whose invocation is undoubtedly
> platform-dependent.  Should we build a platform-specific SwazooCompiler,
> or should we just plan on tweaking this method in each dialect?

If the goal is to be as source compatible as possible (which is an
interesting exercise in itself), then SwazooCompiler would be a good idea.
We could use it for the ActivePages and in Site.

Is there a need for a FileResource superclass that just maps urls to the
local fileSystem. FileResource could subclass it to provide
caching/notModified responses and SwazooActivePage could subclass it to
provide dynamic content based on files.

As it stands, I think the decision on whether the resource is notModified is
based on the 'sap' file not the converted page.

Steve
www.dolphinharbor.org

Steve Waring wrote:

If the goal is to be as source compatible as possible (which is an
interesting exercise in itself), then SwazooCompiler would be a good idea.
We could use it for the ActivePages and in Site.

Okay, I'll move towards that.  I'd forgotten about the use in Site.

Is there a need for a FileResource superclass that just maps urls to the
local fileSystem. FileResource could subclass it to provide
caching/notModified responses and SwazooActivePage could subclass it to
provide dynamic content based on files.

As it stands, I think the decision on whether the resource is notModified is
based on the 'sap' file not the converted page.

You're right; that's not the correct behavior here.  Your idea for a "file mapping resource" makes good sense to me.  If there are no objections, I'll call it FileMappingResource.


Ken