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-
[EMAIL PROTECTED] before 2008-11-21T00:00Z
