Webware for Python

Geoffrey Talvola wrote:
> I think I agree with you, Jason -- Webware should provide an easy hook to
> swap in a subclass for a key class like Session and it shouldn't feel like a
> hack.  The Mixin stuff feels like too much of a hack, and adding a bunch of
> hooks at specific places in the code just adds clutter.
> 
> Perhaps a setting in Application.Config could specify classes to use in
> place of the standard classes:
> 
> 'CustomClasses': 
> 	{
> 		'Session': 'MyPackage.MyModule:MySession' ,
> 		'Request': 'MyPackage.MyModule:MyRequest'
> 	}

I think this allows customizability, but not extensibility.  It's 
customizable because you can alter the appserver without modifying the 
main source.  But it's not extensible, because it can only be done once 
per installation for each main class.

   Ian

We should have both. 

I like subclassing when I change the basic implementation (data level), 
and hooks/callbacks/plugins where I need to
add code that responds to events of the basic web application flow.

That is not a clear sentence, but here is what I mean:
If I wanted to change sessions to store data in a database rather then 
memory I would sublclass session and replace the
method that persists the data.

If I wanted to trigger something to happen when the session starts 
(outside of normal session handling mechanics) I would rather write a 
event handler
that responds to onSessionStart()

Example:
So if I want to create a customer record and start clickpath tracking, 
that should be done in the context
of an event handler.  If I want to store sessions in a database I would 
subclass.

'CustomClasses':     {
        'Session': 'MyPackage.MyModule:MySession' ,
        'Request': 'MyPackage.MyModule:MyRequest'
    }

'Interceptors':   {
    'Session_onCreate': ['MyPackage.Cart:MySessionEvents_onCreate',
                                        
'MyPackage.User:MySessionEvents_onCreate'
                                        ] ,
 }
 
So I have lots of customization as to what happens when a sesion is 
created, but only way to create a session.

-Aaron


Ian Bicking wrote:

> Geoffrey Talvola wrote:
>
>> I think I agree with you, Jason -- Webware should provide an easy 
>> hook to
>> swap in a subclass for a key class like Session and it shouldn't feel 
>> like a
>> hack.  The Mixin stuff feels like too much of a hack, and adding a 
>> bunch of
>> hooks at specific places in the code just adds clutter.
>>
>> Perhaps a setting in Application.Config could specify classes to use in
>> place of the standard classes:
>>
>> 'CustomClasses':     {
>>         'Session': 'MyPackage.MyModule:MySession' ,
>>         'Request': 'MyPackage.MyModule:MyRequest'
>>     }
>
>
> I think this allows customizability, but not extensibility.  It's 
> customizable because you can alter the appserver without modifying the 
> main source.  But it's not extensible, because it can only be done 
> once per installation for each main class.
>
>   Ian
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss



-- 
-Aaron
http://www.MetroNY.com/
"I don't know what's wrong with my television set. I was getting
 C-Span and the Home Shopping Network on the same station.
 I actually bought a congressman."
    - Bruce Baum

Aaron Held wrote:

> We should have both.
> I like subclassing when I change the basic implementation (data level), 
> and hooks/callbacks/plugins where I need to
> add code that responds to events of the basic web application flow.

Agreed.

In my option, the desire of users to subclass basic classes like Session 
or Request is most probably a sign of some design deficiency. It should 
be possible to _collaborate_ with the framework to achieve developer's 
goals instead of thrashing it. ;-)

Of course, there could be situations where the user wants something very 
different that was not anticipated by the framework. In such cases he 
could use subclassing as a last resort.

On Thu, 2004-02-26 at 12:04, Ian Bicking wrote:
> Geoffrey Talvola wrote:
> > I think I agree with you, Jason -- Webware should provide an easy
> hook to
> > swap in a subclass for a key class like Session and it shouldn't
> feel like a
> > hack.  The Mixin stuff feels like too much of a hack, and adding a
> bunch of
> > hooks at specific places in the code just adds clutter.
> >
> > Perhaps a setting in Application.Config could specify classes to
> use in
> > place of the standard classes:
> >
> > 'CustomClasses':
> > 	{
> > 		'Session': 'MyPackage.MyModule:MySession' ,
> > 		'Request': 'MyPackage.MyModule:MyRequest'
> > 	}
> 
> I think this allows customizability, but not extensibility.  It's
> customizable because you can alter the appserver without modifying
> the
> main source.  But it's not extensible, because it can only be done
> once
> per installation for each main class.

Good point Ian. I think this is an important distinction to make.
We've talked before about wanting to make it possible to use
pre-fabricated components in Webware which weren't necessarily written
to be aware of each other, enabling Webware developers to factor general 
functionality out of their apps and share them with each other.  Obviously
we need extensibility as you describe above if we expect multiple components
to play together nicely.

I've been thinking more about the idea of using signals/events as a
metaphor for this, as you suggested.  This idea certainly appears to
have been a breakthrough in the gui toolkit world (specifically GTK).
I looked at your Component/CPage stuff a while back (in the sandbox).
Have you been using that model for much Webware development?  Have you
been happy with it?

I'm going to take a look at http://pydispatcher.sourceforge.net/ and see how
it might fit in (thanks for the link, Max!).

peace,
Jason

Jason Hildebrand wrote:
> Good point Ian. I think this is an important distinction to make.
> We've talked before about wanting to make it possible to use
> pre-fabricated components in Webware which weren't necessarily written
> to be aware of each other, enabling Webware developers to factor general 
> functionality out of their apps and share them with each other.  Obviously
> we need extensibility as you describe above if we expect multiple components
> to play together nicely.
> 
> I've been thinking more about the idea of using signals/events as a
> metaphor for this, as you suggested.  This idea certainly appears to
> have been a breakthrough in the gui toolkit world (specifically GTK).
> I looked at your Component/CPage stuff a while back (in the sandbox).
> Have you been using that model for much Webware development?  Have you
> been happy with it?

Unfortunately, my professional life has been moving away from Webware, 
though I hope to bring it back at some point (Zope hasn't really grown 
on me, even if I've learned to cope).  So I haven't had a chance to use 
these things as much as I'd like.  (For others, the code in question is 
in Sandbox/ianbicking/Component, and is just a compatible subclass of 
Page that doesn't require any other Webware support)

Part of Component/CPage was the idea of providing services or 
functionality to a servlet, which is a lot like Mixins, only slightly 
more formal.  Events were also necessary, since Mixins (either as done 
in Component, or in MixIn) are unfriendly with each other -- and even if 
you can use them together, it's overly clever and feels fragile to me. 
I think PyDispatcher would probably be a better solution than the ad hoc 
events I implemented.

I think for the small tests I've done -- user management, a user 
notification pattern, and a form processor -- that it works fairly well. 
  It's not magical or particularly complex, but it provides convenience. 
  I think the resulting components are also easy to document and 
explain, which is something I particularly value.  So even if the 
components mostly just remove some boilerplate that would otherwise be 
needed, I think that's valuable.

   Ian

I'm not sure if the Mixin is the way to go with what you are thinking.

Personally I would be against subclassing a 'core' class such as sessions,
I would rather see some hooks for calling implementation specific code.

This could even give contexts a reason to exists!

Something like
def onSessionStart...
def onSessionEnd.....

Take a look at the callback chain system in pyBloxsom, I think they
did a interesting job.

-Aaron


Max Ischenko wrote:

> Aaron Held wrote:
>
>> in "context"/__init__.py
>>
>> from MiscUtils.MixIn import MixIn
>> from WebKit.Session import Session
>>
>> from MaxUtils import NotifyCode
>>
>> class SessionMixIn:
>>    def expiring(self):
>>       NotifyCode('Session is ending')
>>     # Now inject the methods from SessionMixIn into Session
>> MixIn(Session, SessionMixIn)
>
>
> Thanks!
>
> I have been thinking about extending the base WebKit for a long time 
> and this is looks like a solution at last.
> But, is it possible to call the "parent" or "original" method that 's 
> been substituted?
>
> Quickly inspecting the mixin implementation I would say No but may be 
> I've overlooked something?
>
>>> Is it possible to register a callback in WebKit so that my code 
>>> would be notified when the session ends?
>>
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss



-- 
-Aaron
http://www.MetroNY.com/
"I don't know what's wrong with my television set. I was getting
 C-Span and the Home Shopping Network on the same station.
 I actually bought a congressman."
    - Bruce Baum

Aaron Held wrote:

> I'm not sure if the Mixin is the way to go with what you are thinking.
> 
> Personally I would be against subclassing a 'core' class such as sessions,
> I would rather see some hooks for calling implementation specific code.

Completely agree here. By having found no such hooks, the Mixin gives at 
least some way to control WebKit, rather hackinsh way, I admit.

And surely WebKit could be designed to be more open for customization.

On Wed, 2004-02-25 at 04:22, Max Ischenko wrote:
> Aaron Held wrote:
> 
> > in "context"/__init__.py
> >
> > from MiscUtils.MixIn import MixIn
> > from WebKit.Session import Session
> >
> > from MaxUtils import NotifyCode
> >
> > class SessionMixIn:
> >    def expiring(self):
> >       NotifyCode('Session is ending')
> >
> > # Now inject the methods from SessionMixIn into Session
> > MixIn(Session, SessionMixIn)
> 
> But, is it possible to call the "parent" or "original" method that 's
> been substituted?

I needed this several months, and added this ability to MixIn.  I held
off checking it into CVS because I wanted to run it for a few months to
make sure it didn't break anything (particularly in MiddleKit, which uses
a lot of MixIns).  It has worked fine, though, so I just checked it in.  

If you're not using Webware from CVS you can just make a copy of
MixIn.py and put it wherever you want -- it doesn't depend on anything else
and doesn't need to be in the Webware source tree.

In a nutshell, you want to do:

from MixIn import MixIn
from WebKit.Session import Session

from MaxUtils import NotifyCode

class SessionMixIn:
   def expiring(self):
      SessionMixIn.mixInSuperExpiring(self)  # call original method
      NotifyCode('Session is ending')

# Now inject the methods from SessionMixIn into Session
MixIn(Session, SessionMixIn, mixInSuperMethods=1)

--
Jason D. Hildebrand
jason@...

On Wed, 2004-02-25 at 13:37, Aaron Held wrote:
> Personally I would be against subclassing a 'core' class such as
> sessions,
> I would rather see some hooks for calling implementation specific
> code.

Hi Aaron,

I'm curious as to your rationale for preferring hooks over using subclasses
to do customization.  I keep my own copies of modified Webware source in CVS
(merging is a painful operation), so I'm interested in making Webware more 
extensibile too, but I'm unsure of how we can best achieve this.

<storytime>
Several years ago I wrote a framework in PHP which provided a lot of
callbacks for customization.  On problem I ran into is that depending on
how you need to customize, you might want to execute some code before,
instead of, or after an event:

    preCommit()
    commit()
    postCommit()

This led to a proliferation of callback functions which achieved the goal of
customizability, but had several shortcomings:

    - difficult to keep track of all the callback methods and their names

    - to maintain sanity, the three callbacks for an event (pre, the
      event itself, and post) need to have the same parameters, which
      means changing in three places

    - I ended up with a pile of 'bare' callback functions (not attached to a
      class), for which it would be difficult for someone else to understand
      the interplay.

I eventually realized that using classes would clean a lot of this up.
With classes you only need one method per event.  Any subclass which
overrides this method can call the superclass' method (or not) when it
needs to, thereby controlling whether the new functionality is executed
before, instead of, or after the event.
</storytime>

This is food for thought.  I'd like to hear more about what you envision for
a good way to make Webware extensible -- maybe we can make some progress on
this front.

peace,
Jason

Jason Hildebrand wrote:
> <storytime>
> Several years ago I wrote a framework in PHP which provided a lot of
> callbacks for customization.  On problem I ran into is that depending on
> how you need to customize, you might want to execute some code before,
> instead of, or after an event:
> 
>     preCommit()
>     commit()
>     postCommit()
> 
> This led to a proliferation of callback functions which achieved the goal of
> customizability, but had several shortcomings:
> 
>     - difficult to keep track of all the callback methods and their names
> 
>     - to maintain sanity, the three callbacks for an event (pre, the
>       event itself, and post) need to have the same parameters, which
>       means changing in three places
> 
>     - I ended up with a pile of 'bare' callback functions (not attached to a
>       class), for which it would be difficult for someone else to understand
>       the interplay.
> 
> I eventually realized that using classes would clean a lot of this up.
> With classes you only need one method per event.  Any subclass which
> overrides this method can call the superclass' method (or not) when it
> needs to, thereby controlling whether the new functionality is executed
> before, instead of, or after the event.
> </storytime>

Well, since we're talking about events, maybe it should done as events. 
  The problem I see with classes is that they aren't composable -- you 
can make one, and only one subclass (at least, only one subclass will be 
used).  Mix-ins are composable, since you can apply the mix-in to an 
already-mixed-in class (well, at least with your patch), but they are a 
little difficult to work with, and tend to be tightly coupled to the 
code they are modifying.

Events don't really solve those problems, but at least they make it a 
bit more explicit.  You still have to deal with the order in which 
registered actions are executed, what effect those actions can have on 
the flow of the code (e.g., can they stop the event, or modify the 
event), and you may want both pre- and post-events for nearly any event. 
  And you have to specify all the events, and any data associated with 
the event.

But I think events are a good metaphor, even if it's still work.  I 
believe there's some good generic frameworks on PyPI for event 
dispatching.  At least, I remember seeing one somewhere that looked 
good, in the last month or two.

   Ian

This will sound a little vague.  That's because I have very little to go
on.

I've got a medium-complex webware app running, and on one of the boxes
I'm deploying it on (and only one) webware does not descend into
contexts.

As an Example, I can view /MenuPage fine, with Main set at the default
context.  Viewing Main/MenuPage results in a 404 - "The page you
requested, /Main/MenuPage, was not found on this server." Every other
context - Basket, Camp, Static, etc have the same problem, but work fine
elsewhere.

This same code works fine on multiple other staging servers, on
virtually identical platforms.  The only difference I can find is that
this box is a custom-built apache (Not sure why - it's a hosted box, so
I didn't do it.)  My question to you guys is ... can anyone think of a
possible cause?  I think I've already eliminated any simple causes, but
I'd like to hear what you've all got to suggest, because this has me
completely stumped...

Webkit 8.0/8.1 (I upgraded it to see if it fixed anything) on Linux with
under apache2, using mod_webkit2.

- Scott

Is the 404 from Apache or Webware?
Check the webware/apache logs and try to see if there is any redirection 
happening
try using the wkcgi adapter as a test
look for Apache rewrite rules

-Aaron

Scott Russell wrote:

>This will sound a little vague.  That's because I have very little to go
>on.
>
>I've got a medium-complex webware app running, and on one of the boxes
>I'm deploying it on (and only one) webware does not descend into
>contexts.
>
>As an Example, I can view /MenuPage fine, with Main set at the default
>context.  Viewing Main/MenuPage results in a 404 - "The page you
>requested, /Main/MenuPage, was not found on this server." Every other
>context - Basket, Camp, Static, etc have the same problem, but work fine
>elsewhere.
>
>This same code works fine on multiple other staging servers, on
>virtually identical platforms.  The only difference I can find is that
>this box is a custom-built apache (Not sure why - it's a hosted box, so
>I didn't do it.)  My question to you guys is ... can anyone think of a
>possible cause?  I think I've already eliminated any simple causes, but
>I'd like to hear what you've all got to suggest, because this has me
>completely stumped...
>
>Webkit 8.0/8.1 (I upgraded it to see if it fixed anything) on Linux with
>under apache2, using mod_webkit2.
>
>- Scott
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>_______________________________________________
>Webware-discuss mailing list
>Webware-discuss@...
>https://lists.sourceforge.net/lists/listinfo/webware-discuss
>  
>


-- 
-Aaron
http://www.MetroNY.com/
"I don't know what's wrong with my television set. I was getting
 C-Span and the Home Shopping Network on the same station.
 I actually bought a congressman."
    - Bruce Baum

>From Webware, not Apache ("Webware Webkit Application Server" on 404
page)

Apache reports no errors (beyond the 404 in the access log)

IP_ADDR - - [26/Feb/2004:16:53:21 -0500] \
"GET /Main/MenuPage HTTP/1.1" 404 229 "-" "Mozilla/5.0 \
(X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 \
Firefox/0.8"

There are rewrite rules:

<VirtualHost IP:PORT>
    ServerName name
    ServerAlias name
    
    DocumentRoot /unixweb/web/stuff/htdocs/
    SSLEngine on
    SSLCertificateFile /apache/conf/ssl.crt/name.crt
    SSLCertificateKeyFile /apache/conf/ssl.key/name.key
    RewriteEngine On
    RewriteRule ^(.*) /Main/$1 [L,PT]
    <Location /Main>
      WKServer localhost 8121
      SetHandler webkit-handler
    </Location>
    SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0
    
    CustomLog /unixweb/web/name/logs/access_log combined
    ErrorLog /unixweb/web/name/logs/error_log
</VirtualHost>

This is similar (identical?) to the staging deployments, except for the
ssl bit.

I have not tried wkcgi yet - in fact, I've never tried it at all, so
I'll have to go pound the docs for a while.

On Thu, 2004-02-26 at 17:23, Aaron Held wrote:
> Is the 404 from Apache or Webware?
> Check the webware/apache logs and try to see if there is any redirection 
> happening
> try using the wkcgi adapter as a test
> look for Apache rewrite rules
> 
> -Aaron
> 
> Scott Russell wrote:
> 
> >This will sound a little vague.  That's because I have very little to go
> >on.
> >
> >I've got a medium-complex webware app running, and on one of the boxes
> >I'm deploying it on (and only one) webware does not descend into
> >contexts.
> >
> >As an Example, I can view /MenuPage fine, with Main set at the default
> >context.  Viewing Main/MenuPage results in a 404 - "The page you
> >requested, /Main/MenuPage, was not found on this server." Every other
> >context - Basket, Camp, Static, etc have the same problem, but work fine
> >elsewhere.
> >
> >This same code works fine on multiple other staging servers, on
> >virtually identical platforms.  The only difference I can find is that
> >this box is a custom-built apache (Not sure why - it's a hosted box, so
> >I didn't do it.)  My question to you guys is ... can anyone think of a
> >possible cause?  I think I've already eliminated any simple causes, but
> >I'd like to hear what you've all got to suggest, because this has me
> >completely stumped...
> >
> >Webkit 8.0/8.1 (I upgraded it to see if it fixed anything) on Linux with
> >under apache2, using mod_webkit2.
> >
> >- Scott
> >
> >
> >
> >-------------------------------------------------------
> >SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> >Build and deploy apps & Web services for Linux with
> >a free DVD software kit from IBM. Click Now!
> >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> >_______________________________________________
> >Webware-discuss mailing list
> >Webware-discuss@...
> >https://lists.sourceforge.net/lists/listinfo/webware-discuss
> >  
> >
>

Ian Bicking wrote:
> Jason Hildebrand wrote:

>> I eventually realized that using classes would clean a lot of this up.
>> With classes you only need one method per event.  Any subclass which
>> overrides this method can call the superclass' method (or not) when it
>> needs to, thereby controlling whether the new functionality is executed
>> before, instead of, or after the event.
>> </storytime>
> 
> 
> Well, since we're talking about events, maybe it should done as events. 
>  The problem I see with classes is that they aren't composable -- you 
> can make one, and only one subclass (at least, only one subclass will be 
> used).  Mix-ins are composable, since you can apply the mix-in to an 
> already-mixed-in class (well, at least with your patch), but they are a 
> little difficult to work with, and tend to be tightly coupled to the 
> code they are modifying.
> 
> Events don't really solve those problems, but at least they make it a 
> bit more explicit.  You still have to deal with the order in which 
> registered actions are executed, what effect those actions can have on 
> the flow of the code (e.g., can they stop the event, or modify the 
> event), and you may want both pre- and post-events for nearly any event. 
>  And you have to specify all the events, and any data associated with 
> the event.

Hmm. Seems like Jason and you talks about something like CLOS 
multimethods and it's call-next-method. Although this is a powerful 
concept, I sure the extensibility of the WebKit could be achieved more 
easily, without having to introduce overly broad concepts.

The extensibility would depend upon good framework design, not the hacks 
like mixins that patche living objects on the fly.

Anyway, we could address these problems one at a time.
Take for example my struggle with custom Session class. Why I can't tell 
the WebKit (in contextInitialize, for example) to use specified class 
instead of the standard Session? It would solve the problem neatly 
without the need for mixins. And I'm free to either subclass the Session 
class or use brand new class for this purpose.

> But I think events are a good metaphor, even if it's still work.  I 
> believe there's some good generic frameworks on PyPI for event 
> dispatching.  At least, I remember seeing one somewhere that looked 
> good, in the last month or two.

http://pydispatcher.sourceforge.net, I bet. Quite impressive.

Fixed it - or at least got it working on this particular machine.

For reasons I don't understand right now, Apache is appending an extra
"/" at the front of the urlPath.  I whipped this up as a fix, and
thought it may be useful to someone else.

--- pristine/Webware-0.8.1/WebKit/Application.py        2003-01-22 04:03:25.000000000 -0500
+++ Webware-0.8.1/WebKit/Application.py 2004-02-29 16:04:21.000000000 -0500
@@ -1169,6 +1169,9 @@
                extraURLPath=''
  
                urlPath = request.urlPath()
+
+               while urlPath[:2] == "//":
+                       urlPath = urlPath[1:]
                if debug: print '>> urlPath =', repr(urlPath)
  
                ##if the requested file is in the filesystem outside of any context...

Its not always a caching issue, its a browser auto-form-fill 'feature'
Use Mozilla and download the web developer toolbar.  It will help you 
turn on/off these features and even
let you see hidden form fields w/o resorting to view source ->search

But I don't get this bug much since I switched to telnet as a browser, 
Mozilla is just too bloated for me.

-Aaron

Matt Feifarek wrote:

> Ian Bicking wrote:
>
>> If it's the browser, I sometimes force a real refresh by putting some 
>> random number in a variable in the URL, e.g., somepage?z=10394.
>>
> It's also pretty easy to set http headers that prevent caching:
>
> .setHeader( "Pragma", "no-cache" ) # for http1.0 clients
> .setHeader( "Cache-Control", "no-cache" ) # for http1.1 clients
>
> There are also some <META> tags, I think...
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> https://lists.sourceforge.net/lists/listinfo/webware-discuss



-- 
-Aaron
http://www.MetroNY.com/
"I don't know what's wrong with my television set. I was getting
 C-Span and the Home Shopping Network on the same station.
 I actually bought a congressman."
    - Bruce Baum

--- Tim Roberts <timr@...> wrote:
> On Sun, 22 Feb 2004 21:04:25 -0800 (PST), David Rushby 
> <davidrushby@...> wrote:
> 
> >In a situation such as this, I use DHTML (document.createElement) to
> >instantiate a new SCRIPT element whose SRC is pointed to a
> >GET-parameterized Webware servlet.  The servlet responds as
> appopriate
> >to the GET parameters with some generated JavaScript code
> (content-type
> >text/javascript), which the browser runs as soon as it's loaded. 
> This
> >code typically updates the user interface in some way via DHTML.
> >
> >It works splendidly, at least for my purposes.
>
> Have you tried this with other browsers?  DHTML tends to be rather 
> specific to Internet Explorer.

Yes, also with Mozilla.

It's compliant with W3C standards.  It doesn't work in Opera, but since
it's standards-compliant and I'm using it only on intranet sites, I
don't care.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools