Refactor export to web classes

Refactor export to web classes to handle new features, and update class diagram with new actors

-- HTML Page Assembler idea from Edward (mail below). Allow a flexible layout with custom named

elements where content can be exported to those instead of just start, end, head -- Refactor HTMLTextPosition to be “HTMLPosition” and allow other elements to use this -- Refactor provideContent() and provideOutsideContent() -- AreaEventType should include smartphone events (onTouch, …) -- IconScript should be more general – right now designed to run a script when an icon is clicked on. Might have other ways of running script (e.g. onLoad()). Refactor to just Script? With subclasses? -- Handling other types of HTML elements – images, audio, …

HTMLModelExporter always generates the same view (e.g. UCBPowerServer model) -- How to generate custom view? Refactor this actor? Assemble view manually like in WebServerDE? Create additional actor (HTMLPageAssembler?)

HTML Page Assembler idea from Edward:

I think the way to deal with (8) is:

 Enhance the "export to web" capability (and hence the
 HTMLModelExporter actor) to have a "templatePage"
 parameter. If provided, this template page should
 provide <div id="..."> ... </div> blocks
 and the web exporter will put things there.
 A template should include at least ids end, head,
 and start, probably, although we can just say that
 if you use a template that does not include these,
 then those parts of the HTML will not be generated.

 This requires changing the HTMLTextPosition
 attribute, which currently says:

anything_else: Put the text in a separate HTML file
named anything_else.

I think this functionality of sending things to a separate file is not really needed, since models can do that anyway with a FileWrite actor. I'm not sure whether any demos use this, but I doubt it. I'll update the documentation now so we don't build demos relying on it.

I can tackle the above... I think the write way to do it is with JavaScript, not with line-by-line parsing parsing of the HTML template, as currently done in HttpCompositeServiceProvider. An alternative would be to put in a full HTML parser, which might actually be a cleaner solution. I'm not sure, but I suspect that this will require the template to be not just HTML, but also proper XML (meaning, for example, that every

has to be terminated with a

Actually, if we take the HTML parser approach, then we can provide another actor:

HTMLPageAssembler: Create input ports with arbitrary names, say "foo", and provide a template HTML with, say,

, and the actor inserts the string provided on input foo into the

block.

The code for this actor could then be reused by the Export to Web infrastructure.

Thoughts about this?

Edward

icyphy / ptII

Refactor export to web classes #308