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

> There are some thoughts on the future development of VPE. Would be great to hear any feedback/comments. thanks - sorry for late answer. > 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'). I know it is just a name but this is still going to be part of an *editor* - its just that the visual part is not editable. For me VPE still works, its a Visual Preview Editor ;)

> 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. Okey so how do we handle this migration ? If its a rewrite I assume the two will be able to coexist ?

If it is a rewrite we should make sure to move everything that is not public api into internal packages.

> 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. don't we need to have a http server for each page that is open ? i.e. if you have the same page name (i.e. index.html and ../images/funky.gif) ...but different content for your project. How is that handled?

> 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 of a 150 lines HTTP server with support of GET requests, MIME types and response codes. as long as its just raw get requests and no magic "execution" that can be misused/hacked then thats fine. /max