Re: Java Applet element proposal

Dianne Hackborn (hackbod@mail.CS.ORST.EDU)
Thu, 8 Jun 95 10:46:35 EDT

On Wed, 7 Jun 1995, Tim Pierce wrote:

> I'm not persuaded that this is the right way to go about
> applet implementation. If you view an applet as just a
> fancy way to produce an image on your page, then sure, this
> makes sense, but my impression of the applet concept is that
> it goes beyond simple image generation. Downloading an
> applet from a remote site permits the browser to execute
> some arbitrary chunk of code, but it doesn't seem to me that
> the function of the applet is limited to producing images.
> If that's indeed the case, I don't like overloading the
> <IMG> tag this way.

Yes, the implementation I am working on also has a concept of a script
associated with an entire document, which can be composed of from various
modules brought over the network. This allows you to interact with the
document at a global level, and it seems like something along this line
will be needed for forms. [I like the idea of sub-documents, but one of my
goals is to make as few changes as possible to current browsers, and
encapsulate the scripting code into one well-defined library. I can
probably set up the library so that it is possible to handle sub-documents
with it, but I'd rather do other things than implement this in the actual
browsers themselves. :)]

Currently, the global script is able to do things like manipulate the
document's HTML tree before it is displayed, for example to dynamically
determine an <IMG> to show in the document:

cursor = html.NewHTMLCursor(doc.VisHTMLTree)
cursor.MoveNextID('titlepic')
cursor.PasteAfter(html.NewHTMLTree('<IMG HREF="http://www/..."')
doc.Reformat()

You can also add handlers to the document to catch [currently only a
limited number of] user events; I'm currently thinking about or working
on being able to store state information in the local browser
environment, retrieving data in the background while the user interacts
with the document, etc.

Another thing I would like to do is more explicitly define how a browser
gets the instance object it will display. This would allow the user to
handle multiple objects in the global scope, and define interaction between
them. For example, in pseudo-Python code:

<HEAD>
<MODULE URL="http://www/nifty_widgets.py" SYMBOL="my_module">
</HEAD>
<BODY>
<FIG INSTANCE="my_module.Nifty1(args)">
<URLARG name="hownifty" value="extremely">
</FIG>
</BODY>

So, if the 'INSTANCE' attribute is present, the browser would evaluate
what it contains using the appropriate language [with 'args' representing
that object arguments from any URL and <URLARG>s], expecting that the
resulting value is whatever type would be appropriate for an embedded
object in that language. If it isn't present, whatever current default
action to get the needed instance would be performed.

-------------------------+--------------------------------------------------
Dianne Kyra Hackborn | "We are not going to have a big-ass Mondo Nuclear
hackbod@mail.cs.orst.edu | War. Period."
Oregon State University | -- Frank Zappa
CS Graduate Submissive |
<http://www.cs.orst.edu/~hackbod/>