Refactor export to web classes

[cxbrooks]

Note: the issue was created automatically with bugzilla2github tool

Original bug ID: BZ#511
From: Elizabeth Latronico <[email protected]>
Reported version: 9.1.devel
CC: [email protected]

Blocker for: BZ#507

[cxbrooks]

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