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

[Yahor Radtsevich]

On Fri, Nov 16, 2012 at 2:03 PM, Max Rydahl Andersen <
max.andersen at redhat.com> wrote:

> > 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 ;)
>
Ha-ha. Ok, but it would be not bad if we had a name to distinguish it from
'classic' VPE.

>
> > 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 ?
>
Yes, I assume they two will coexist until we decide that the new one is
mature enough to completely replace the old one and XULRunner things.

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

>
> > 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?
>
One http server for one eclipse instance. Pages on the server will be
available under paths like localhost:xxxx/project/pathtopage/page.jsp. We
could also dispose the server when no VPE editor is opened.

>
> > 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
>
>


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