[Laszlo-dev] Presentation Types, New Components, and MVC

[P T Withington]

I don't think we have the concept of Presentation Types right yet.   
We've got some experimental infrastructure [which intentionally is all  
marked as private] that solves two problems: 1) converting native (JS)  
types to/from data representations, and 2) converting native (JS)  
types to/from string representations.  Yes, these both take the same  
path, but I split them out to make the point that we really want to  
support multiple conversions, because there _could_ be other external  
representations than strings (e.g., we could have a binary data  
representation, instead of XML/string).

I've recently been playing with 'old components' to make them a bit  
more user-friendly.  The motivation was an example that Lou wanted to  
build where he had a slider that was used to set the color of a sample  
swatch.  He wanted to display the color (stored in the slider's value  
as a Number) as a CSS color (in #xxxxxx notation).  Surely  
Presentation Types to the rescue?  Well, I glued a new API onto  
basecomponent, adding a type attribute and acceptValue and  
presentValue methods (André's names) that input/output string  
representations of value according to type.  It works well enough for  
Lou's example, but last night I had a bad dream:  I've got it upside  
down!  The slider component _is_ a representation, not a value, really  
I should be saying:

   present this color as a <slider>

   accept a color from a <slider> (representation)

Just the same way I say:

   present this color as a String

   accept a color from a String (representation)

I think the problem is that 'old components' have their MVC so  
entwined, I got confused.  I think what we really want is for the  
model to be a Presentation Type, where the Presentation Type, stores a  
native value _and_ a type (possibly encoded as the subclass of  
PresentationType), where the type is what defines how that native  
value is represented in different presentations.

Sticking with the color example, I think we want a  
ColorPresentationType, which is abstractly a subtype of 'number in  
range', that is, it has a minimum value (0), a maximum value  
(0xffffff), and stores a current value (the 24-bit color it represents).

PresentationType's need an interface to connect the type with a  
representation.  Currently, we have present/accept which convert to/ 
from String representations, but even within that interface we need  
more control.  When presenting a color as a string, we should be able  
to say whether or not we want to use color names, #xxxxxx notation,  
rgb(ddd,ddd,ddd) notation, etc. (maybe someone wants hsv, lab, ???).   
Maybe the presentation format is encoded in a subclass, or is another  
instance attribute?

And we need to be able to present a color as a component too.  If we  
present it as a <slider> we need to convey the min, max, and current  
value.  For labeling the thumb, we need to convey the presentation  
format.

But, I think they main thing I am coming down to, is that in the New  
Components effort, the component should _not_ be storing the native  
value, it should be referring to an instance of a PresentationType  
that stores the native value.  The PresentationType is the Model, a  
component is a View that is one possible representation of that  
PresentationType, and it also may be a Controller, that allows you to  
change the value of the PresentationType/Model.

If we had multi-methods, I think that the generic functions `accept`  
and `present` would dispatch on two types:  the PresentationType  
(Model) and the Representation (Controller for accept, View for  
present).  Since we don't have multi-methods, we're stuck with a 2- 
level dispatch.  Either each PresentationType needs to know about all  
it's possible Representations, or each Representation needs to know  
about all the possible PresentationTypes it can represent.  I _think_  
the latter is the way to go, since the number of Representations seems  
like it could be much larger than the number of PresentationTypes, and  
there is likely a fairly small API between Representations and  
PresentationTypes (underneath it all, they all boil down to scalars,  
array/list, and record/object).

Take-home Exam:

Q1.  Is this a proper interpretation of Model-Value-Controller?

Q2.  Is PresentationType a useful abstraction or an implementation?   
Should we be concerned about the overhead of creating  
PresentationtTypes's, or are they actually lighter weight than  
exisiting <basevaluecomponent>'s which they effectively replace.

Q3.  ES4 planned to add generic functions to Javascript.  Should we  
adopt that in our implementation to avoid the 2-level dispatch problem  
of implementing PresentationType's?

Expected time: 8 hours
Be sure to footnote any references to prior research used to justify  
your answers
Your completed exam must be returned to mailto:laszlo- 
dev at openlaszlo.org before 2008-11-21T00:00Z