Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: Community (was IOS).

From: jason:cunliffe:verizon at: 20-Mar-2002 11:55

Porter Woodward <[pwoodward--cncdsl--com]> wrote:
> what about making index.r files visible to search engines? Depending on how > much control over your web server you have, it could be easy to serve > index.r as the default for directories. Apache and IIS make this a > relatively trivial process. Just setup the server to serve index.r, > index.html, index.htm, etc. In that order.
Yes. In Apache you use the DirectoryIndex directive: DirectoryIndex index.html index.htm index.shtml index.php index.r I have not played around with the order yet. Experimenting now with substituting all my index.html files with index.r files so that folders become 'smart', creating self indexing links. When new stuff is uploaded into them, index.r is always uptodate since its dynamic. This is so trivial to do but immediately opens up some interesting options for self maintaining web sites. Next is include some metadata files in each folder which the index.r files can use. For example about.txt [description] use.r [local file tracking access] etc What I really want is something in REBOL which works a little like Zope's powerful 'acquistion' without the voodoo baggage of Zope. For those that don't know, Zope is a server side content management system writetn in Python. It is thus highly object-oriented and adaptable, using URL paths to access a 2-way web object model. In Zope, this might be a regular URL descending the default hierarchical file structure tree, but it might also be combined with methods which change the context namespace before rendering the file "afile.html". In the URL above, english muight be subfolder or it might be script to render in that langauge. graphic might a zope method to enable thumbnails etc. graphic might in fact live at the top level in the Zope object hierachy. Meaning it need only be defined once and everything 'below' can access or acquire it. In Zope the traverasl searach starts at the bottom [end of the URL path] and looks up to its parent to ask "do you have a methiod called 'graphic'?" If yes then it uses that one, ie the first one it finds. If no then it asks its parent and so on. The result is site-wide shared functions which can be implemented by putting methods at the top level. A single change to one method script can alter all refrencesw to it across a site. Very powerful. These can be overloaded, customized by inserting variations of the same name anywhere in the hierachy. This allows local contexts to be changed modularly while allowing common code and embedded method calls to remain the same. What strategies in REBOL can we use so that each index.r maintain itsef easily? It could be something very simple. An index.r is either a "parent" or not. If enabled as a parent a script will return its code when any child asks for it, else it will ask up the hierachy to find a parent. In practice once can populate a site with empty index.r scripts [the default]. All they know to do is ask for a parent script. when they find it they run the code locally at their level. Any tmie you want to customize, just add implicit or inherited behavior.. I am thinking out loud here, so please jump in. REBOL seems ideal for implementing all sorts of genetically inspired adaptive designs, including for simple but powerful inter-website programming. Vanilla already offers many wonderful features in a very elegant model of its own.
> Now - you may ask - what happens when a plain-jane web browser hits that > index.r? Well, unless we have a standard way of detecting the requestor > (e.g. browser type) and taking the appropriate action, it won't do us much > good. So every index.r (or other publicly accessible rebol page) should > probably do a quick check to see if it's being requested by a REBOL client - > if so it should just hand over the code. Otherwise, it should probably > print some nice HTML message for older browsers to understand.
Good idea. How do you check if it's being requested by a REBOL client?
> Something about this being a "Rebol Powered" site - and needing REBOL to > function - not unlike a Flash site. Now, this could be annoying to some - > but the presupposition is that we're not going to be stuck with browsers > forever.
Yes. Also rebol scripts can be embedded within HTML. How many people have played around with this feature? ./Jason