``Webby verbs'' are verbs displayed as buttons at the bottom of the page and that allow you to manipulate the object. If you wonder what a ``webby verb'' is click on the help button on the ``holder'' page. This verb will display the standard help message plus all the comment strings it finds on top of the objects verbs.
``Webby'' Verbs are by convention all verbs whose name terminates by ``_web''.
E.g. the inherited help verb on each object is #1:help_web.
You should have a look at it sometimes. Why do webby verbs work?
Have a glance at sections 14.3.1 and 14.3.2!
Let's program a simple verb that will show the contents of the holder. In order to do that we have to introduce a new type of verbs, i.e. verbs that are called by other verbs. Such verbs (i.e. ones not typed in by the user as commands) are by convention ``this none this'' verbs. Therefore we create our verb like this:
>@verb holder:show_web this none this
Now please display the verb argument specifiers and the permissions
by typing: '@d holder:show_web'. In case you forgot the ``this
non this'' you got to do the following thing (use 'help ...' if you
want to know more right now):
@args holder:show_web this non this
@chmod holder:show_web +x
Programming simple ``webby'' verbs without buttons is quite simple as you can see in the example below. The only really new thing here is that we use verbs as functions. Functions are cool for letting application programmers use complex software packages such as the Web interface. You may want to read section 8.2.4 to see why. In section 8.4 we used verbs as procedures, i.e. algorithms that that work on data-structures but do not return values for other use. Note, however that builtin-in functions exactly did that. So what we ask from now is to write function verbs according to some specifications, i.e. they must return a certain type of value and they will accept certain arguments as input. You must follow those specifications, else nothing will work.
The show verb has the following specifications:
Now, copy the verb onto your holder object and check if it works over the www interface.
>@l holder:show_web
#2108:"show_web" this none this
1: "This link will show you the contents of holder";
2: header = "Show contents of" + this:title();
3: item_list = {};
4: for item in (this.holding)
5: item_list = {@item_list, "<li>", item};
6: endfor
7: return {@$www_utils:do_html_header(header), tostr("<h1 align=\"center\">",
header, "</h1>"), "<ol>", @item_list, "</ol>",
@$www_utils:do_html_footer()};
--
Now let's examine line 7. This line returns a list to a verb that has called this function. The list is the HTML code that will be displayed in the body of the page which will be generated in reply to activation of this webby verb. This list must be a FLAT list of strings representing HTML code.
Note that the top of all html pages should stay the same by convention (well you might decide otherwise). Now let's see in detail what kind of list the return statement returns:
@y\$www_utils:do_html_header(header) will build:
<html> <head> <title> .... </title> </head> <body> ....
tostr("<h1 align=\"center\">", header, "</h1>") will build the main title (h1) of the page
"<ol>", @item_list, "</ol>" will build an <ol> ... </ol>
type of list, and insert in the middle the elements of the item_list we built
above.
@\$www_utils:do_html_footer()} will add a footer to the html page,
e.g. things like <\body> <\html>.
``Webby'' verbs with arguments are more trickier. Arguments to displayed in the web are specified in comment lines at the beginning of the verb. (See section
>@l holder:add_web
#2108:"add_web" this none this
1: "text to add: ?txt70?.";
2: player:report(args);
3: header = "Add element to " + this:title();
4: text_to_add = args[1][1];
5: player:report(text_to_add);
6: this.holding = {@this.holding, text_to_add};
7: return {@$www_utils:do_html_header(header),
tostr("<h1 align=\"center\">", header, "</h1>"), "<ol>",
"done ...", "</ol>", @$www_utils:do_html_footer()};
--
.