This is a never-ending issue that we have failed to solve over and over (see
attached, plus I linked LPP-8899 to a number of previous go-rounds). I think
we need to really come up with a uniform approach to this issue (of
distinguishing content from extension).
--- Begin Message ---
[Added laszlo-dev.]
On May 29, 2005, at 10:37 AM, P T Withington wrote:
On 29 May 2005, at 10:01, Oliver Steele wrote:
On May 24, 2005, at 8:01 PM, P T Withington wrote:
Er, I can see why you can't subclass a dataset instance, because
you can't distinguish the content from members, but why can't you
create a subclass of dataset? Is this because dataset is really
a special form? [I'm really asking Oliver this.]
Right. Technically, it's because
<class name="myclass" extends="tag">stuff</class>
<myclass/>
is defined to be equivalent to:
<tag>stuff</tag>
But we could say this isn't true for extends="dataset", and then
you could add methods to a subclass.
Oh right. Adam's nifty thing where you can start with an instance
and switch to a class when you need it.
Also here: <http://osteele.com/archives/2004/03/classes-and-
prototypes>. And it made into into the dguide too, I think.
Text works because it ignores anything that isn't a declared as an
HTML element in the schema. (Well, that's the spec. The
implementation is WETter than that. Now ask me what WET means :-)
We have a similar problem with text, right? Except text happens to
work because we can distinguish between plain text (which is
treated as content) and tags (which are treated as extensions).
That won't work if the content of the text is html will it? Or are
we being even trickier and knowing that only certain tags are
extensions?
Could we do something like this?
<dataset ...>
<?lzx
<attribute ... />
<method ...>
...
</method>
?>
<xml>
<content>
<goes here>
</content>
</xml>
</dataset>
Or instead of <?lzx ... ?> use <![CDATA[ ... ]]>?
I don't like these, since neither one gives <dataset> an <attribute>
element in the source, causing problems for editors and another path
in the compiler.
Some other ideas:
Namespaces
<dataset name="ds" xmlns:data="local:data">
<attribute name="a" value="1"/> <!-- This adds an attribute to
the dataset -->
<data:attribute name="a" value="1"/> <!-- This is the xml
content of the dataset -->
</dataset>
I admit I can't quite get this to work, but in case anyone else can
kick life into it...
<Model> element
Require a <model> element for inline data, so anything that isn't
inside the <model> element is property of the instance (or class):
<dataset name="ds">
<attribute name="a" value="1"/> <!-- This adds an attribute to
the dataset -->
<model>
<attribute name="a" value="1"/> <!-- This is the xml content
of the dataset -->
</model>
</dataset>
This is a breaking change, so it would need to be phased in. It also
has the disadvantage that not every XML fragment represents an MVC
model. This is already a source of confusion for server-side
developers.
Subclassing
Fix subclassing dataset, and specify that the class definition can't
have inline data. (This is the original proposal at the top of this
message.)
<dataset name="ds">
<attribute name="a" value="1"/> <!-- This is the xml content of
the dataset -->
</dataset>
<class name="mydataset" extends="dataset">
<attribute name="a" value="1"/> <!-- This adds an attribute to
the dataset -->
</dataset>
<mydataset name="ds">
<attribute name="a" value="1"/> <!-- This is the xml content of
the dataset -->
</dataset>
This breaks the instance substitution principle: it's not the same as
subclassing works for other base classes, so it requires special
knowledge on the part of developers and refactoring tools.
Partial classes
I'm going to propose (Real Soon Now) that we add partial classes (aka
open classes), in order to make it possible to reskin components with
the maintenance overhead of copying files, and without the runtime
overhead of subclassing. This could also be used to add methods to
datasets, if the rule were that inline data is only allowed in the
main class declaration (probably a good rule for independent reasons).
<dataset name="ds">
<attribute name="a" value="1"/> <!-- This is the xml content of
the dataset -->
</dataset>
<extend name="ds">
<attribute name="a" value="1"/> <!-- This adds an attribute to
the dataset -->
</extend>
(The syntax for partial classes is yet to be decided; this is a stub
so you can see how it would interact with this particular problem.)
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--- End Message ---
Oliver's last suggestion, "partial classes", are [tadah!] mixins. So we have a
possible solution to the question: How can I do instance-first development on
a tag that has (potentially HTML/XML) content? If I need to add a method to a
<text> with HTML content (or <dataset> with XML content), I have to do it with
a mixin. Then we don't have to have any magical DWIM-ing of the content. (For
many of the instance-first things you'd like to do, you have the shorthand of
specifying the extension in the open tag, just not for more complex things like
methods, etc.).
Rather than:
<text type="html">
Some <b>HTML</b> text
<method>...</method>
</text>
You have to say:
<mixin name="extension">
<method>...</method>
</mixin>
<text type="html" with="extension">
Some <b>HTML</b>text
</text>
I'm implying that `type="html"` says: the content is HTML, and will be passed
verbatim (and interpreted by HTML rendering). For `type="text"`, we could
heuristically look for embedded XML that can be interpreted as extension (and
what is not, should be passed through but _not_ interpreted by HTML rendering).
I think there is a crying need to solve this issue once and for all in a sane
way.
On 2010-04-22, at 16:47, Henry Minsky wrote:
> I'm looking at LPP-8898, regarding the munging of HTML content in <text>
> views
>
> http://jira.openlaszlo.org/jira/browse/LPP-8898
>
> Tucker and Max suggested passing the HTML content verbatim (including
> whitespace) from the LZX to the compiled
> javascript for the runtime.
>
> At first I thought I could do this by just passing the content verbatim, but
> we allow many LZX tags inside of text content,
> e.g.,
>
> <text>This is some text
> <handler name="oninit">
> ...
> </handler>
> And some <b>more</b>
> <method name="foo" args="a,b">
> ...
> </method>
> <attribute name="foo" ...../>
> </text>
>
> So, currently, the LZX compiler has a little scanner that looks for known
> HTML tags, and does
> some processing. Whitespace is normalized away by default, unless the <pre>
> tag is seen:
>
> P, BR
> PRE sets verbatim (literal whitespace) mode
> face control: B, I, FONT tags modify the font
> A [href] indicates a hyperlink
>
> Any other tags are ignored.
>
>
> Do we want to change this mechanism? Should we have a "whitelist" of LZX
> tags rather than whitelist
> of HTML tags?
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> [email protected]
