[jbosstools-dev] Next-generation VPE - Visual Page Viewer (VPV)

[Yahor Radtsevich]

Hi All!

There are some thoughts on the future development of VPE. Would be great to
hear any feedback/comments.

The idea is to add to VPE the must have features, like the support of
JavaScript and HTML5 and the support of 64-bit JVM on all OS. And get rid
of all less important features and the features that do not work very well
(i.e. editing - that is why we call it 'viewer').

*Why VPE needs significant changes/rewriting?*

Because of three things (at least):

   - Currently VPE does not support JavaScript.
   - Currently VPE is based on XULRunner 1.9 and XPCOM, which means that:
      - This is not a default browser engine for Eclipse. This is the
      reason of many incompatibility issues such as JVM crashes on some
      workstations.
      - 64-bit JVM is not supported on Windows and OSX.
      - No HTML5 support (yes, we simulate HTML5 tags, but it is not
      enough).
      - We have to ship XULRunner with JBoss Tools/JBDS
   - There are a lot of features in VPE which are working not very well,
   and still make the code to be complicated and bug-prone (i.e. visual
   editing or D&D). These features are spread on all code, it is not easy to
   isolate them and get rid of them without rewriting a significant part of
   VPE.

*How does VPE work now?*

VPE has a visual DOM builder and a lot of templates. For every XML/HTML
file opened in an editor, WTP automatically creates a W3C DOM tree (source
tree). Using templates, the visual DOM builder converts all nodes from the
source tree directly into XULRunner DOM tree (visual tree).

*So, what is wrong here:*

   - We cannot use any browser other than XULRunner, because VPE templates
   and the whole VPE code is tight coupled with XULRunner interfaces.
   - We cannot enable JavaScript. We store Java objects for every XULRunner
   node. If the visual tree is modified by JavaScript, we will get errors.
   - JUnits are slow, we cannot run JUnits to test templates without
   rendering them in XULRunner.

*VPV architecrture*

My vision is that the main process of the source to visual conversion
should looks like this:
*W3C source DOM--(by W3C DOM based templates)-->W3C visual DOM->HTTP
server->SWT browser widget*
*
*
The explanation follows.

*Why W3C visual DOM by W3C DOM based templates?*

Under W3C DOM based templates I mean that these templates will use
org.w3c.dom.* interfaces to produce visual DOM. To create W3C templates we
should rewrite all our existing VPE XPCOM based templates (~150 Java
classes) and many core classes. It is a lot of work, but as a bonus I
expect them to simplify significantly.

There are two not so good alternatives:

   - Leave XULRunner DOM based templates as is and create wrappers for W3C
   DOM nodes. So the templates will ‘think’ that they are creating XULRunner
   DOM, but actually W3C DOM will be created.
   - It is a simple to implement approach, but potentially it produces a
   lot of runtime errors. E.g. if a template uses getStyle method, which does
   not exist in W3C DOM, we will get a not implemented exception.
   - Leave XULRunner DOM based templates as is and create wrappers for
   browser nodes.
   - Simpler than the previous approach, but slower and requires to build
   visual DOM in the UI thread.

*Why HTTP server?*

It is a simple way to know what resources our browser needs and send them
on request.

There are two not so good alternatives too:

   - Use browser.setText(htmlText)
   - In this case the browser do not have a base URL, so we should replace
   all relative links to resources in the htmlText to absolute links, like
   “style.css”->“file:///foo/barproject/style.css”. And this is not enough -if
   linked resources have relative links, we should replace them too. But how
   we can replace these links in linked resources if we cannot change them?
   The answer is we should embed these resources in htmlText, like “<link
   href=style.css>”->“<style>style.css content here</styles>”. This approach
   is implemented in VPE. It is very complicated. What is worse, it does not
   work with JavaScript, where you can load resources as you want, e.g.
   link.href = ‘style’ + ‘.’ + ‘css’ - what poor VPE can do? Interpret
   JavaScipt? No.
   - Create a temporary directory, copy converted .html file and ALL
   resources there (because we do not know which resources are needed
   exactly). Then point our browser to it:
   browser.setUrl(“/temp/dir/converted.html”).
   - Synchronization problems: have to manage tons of files, delete them if
   not needed etc. Speed problems: all resources should be deployed to the
   temporary folder before viewing the converted html in browser.


*We are going to open a TCP port, what about security?*

No problem here. Java allows to restrict connections to localhost only:
new ServerSocket(8383, 0, InetAddress.getByName("localhost"))
At least the standard Windows firewall does not worry and does not show the
“Security alert” pop-up.

*How hard to write our own HTTP server? Is not it easier to reuse something
like Jetty?*

We do not need a complicated server. Just a server which supports GET
requests would be enough. Writing of a custom server is the simplest task
ever :) Here is an
example<http://cs.au.dk/~amoeller/WWW/javaweb/server.html>of a 150
lines HTTP server with support of GET requests, MIME types and
response codes.

-- 
Best Regards,
Yahor Radtsevich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20121109/fdc00edb/attachment.html