[Laszlo-dev] attribute list format: proposal and problems

[Benjamin Shine]

A few of us came up with a proposal for how to handle the attribute  
list format in the new docs. This email describes the proposal, gives  
examples, and identifies problems. Please review and comment.

In the 3.4 docs, we listed...
Name / Usage / Type (tag) / Type (JS) / Default / Category

The current proposal is to collapse Usage and Category into a single  
column, tentatively named Category, but I suspect there's something  
better. For the purposes of this discussion, let's call it "Flavor."  
The Flavor column would contain exactly one of these four choices:
* tag only
* read-write
* read only
* javascript only

These flavors don't quite capture all the information in the old  
category + usage. See "Lab Notes" below for intresting/tricky details.

A fundamental underlying problem is that the read-only-ness of  
anything is just a suggestion; the actual bits of data in the runtime  
model are not protected. Calling them "read-only" really means  
"undefined and probably incorrect behavior will result from trying to  
modify these at runtime." Tucker, is that correct? Do we do any  
runtime protection against writing?

In the next few days, I hope to propose something reasonable and  
readily implementable with the information currently represented in  
the markup in lzx and lfc source.

*** Lab Notes from an experiment with attributes of <edittext> ***

Some attributes seem to map easily to a flavor: read-write is  
relatively uncomplicated.

Name     current "Usage"  current "Category"     ===> Flavor
maxlength 	Tag & JS	setter		read-write
pattern		Tag & JS	setter		read-write

The picture quickly gets complicated:
Name     current "Usage"  current "Category"     ===> Flavor
multiline	Tag only	final		?
password	Tag only	final		?

...but closer inspection reveals problems: in script, one may read  
the values of myedittext.password and myedittext.multiline; how is it  
tag only? The password attribute is a current topic of interest, and  
rather complicated. "Tag only" and "final" don't seem to cover it.

Name     current "Usage"  current "Category"     ===> Flavor
focusable	Tag & JS	read only	read only
id		Tag & JS 	read only	read only
clip		Tag only	final		tag only

Is focusable really read only? I thought you could change something's  
focusable-ness at runtime, but how would the doctools or a developer  
know that? (I would have to actually write a test to figure it out.)  
On the other hand, I believe that "id" really is read only.

JS only AND readonly seems to require a new flavor:
Name     current "Usage"  current "Category"     ===> Flavor
hassetheight	JS only		read only 	?
totalframes	JS only		read only	?
classroot	JS only		read only	?

...this flavor seems to be "never modify these unless you are editing  
the LFC and you really know what you're doing."


Event handlers are weird -- why are some "eventhandler" and some  
"setter"? Is there actually a difference in usage between (for  
instance) onmousedown and onkeydown, or is this just a doc error?
Name     current "Usage"  current "Category"     ===> Flavor
onblur		Tag only	eventhandler     ?
onmousedown	Tag only	eventhandler     ?
onkeydown	Tag & JS	setter           ?
ondata		Tag & JS	setter		 ?

And some fundamental class system things are tricky:
Name     current "Usage"  current "Category"     ===> Flavor
class		Tag only	final           ?  (You can examine myview.class in  
javascript; it's not really tag only.)

Criminy!