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

[Yahor Radtsevich]

On Tue, Nov 20, 2012 at 11:38 AM, Max Rydahl Andersen <
max.andersen at redhat.com> wrote:

> > > 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.
>
> True, so VPV is a part of VPE ? :)
>
Would be a part of vpe component on github, but it is completely
independent.

>
> What is your plans for making it available - as an extra tab on VPE or
> even as a separate view ?
>
For the beginning, my plan is to create a separate Preview View. The
problem with views is that we cannot attach them to an editor. It will be
like JavaDocs View, which is absolute unnecessary when a non Java editor is
used. So it would be good to create a new tab in the VPE editor later.

>
> > >       • 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.
>
> we've seen a few issues with the browsersim not working all smooth with
> WebKit, but I guess for VPV this is less of a concern since we will simply
> just
> be using whatever built-into-eclipse browser is enabled by the user on his
> platform, correct?
>
Yeah, it will use any browser. But of course, each browser, has its own
features/bugs which should be taken into account when creating the viewer.

>
> > If it is a rewrite we should make sure to move everything that is not
> public api into internal packages.
> > Will do it.
>
> Would also be good to make an effort on making the API to add support for
> other libraries more approachable than previous VPE.
> i.e. documented API's, example of how to do it etc.
>
Agree. We could also make creation of templates more approachable by
creating a simpler templating system. Now in VPE only Java and XML tamples
are allowed. But we could allow also something like javascript
micro-templating <http://ejohn.org/blog/javascript-micro-templating/>.

>
> > > 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 about absolute relative paths like "/images/funky.png" - I guess that
> will be handled the same way as before where the href's are rewritten to
> have a proper "root" ?
>
Good question. I just forget about this root-relative case.
It looks like one server per viewer or at least one server per workspace is
needed to handle it. I assume, that our users may have several editors
opened, so one server with changing root directory is not an option.
Obvious drawbacks of multiple servers are:
- we have to manage their creation/disposal
- these servers will consume more resources (not much, but at least a port
and a connection-waiting thread per each)
- pages from different projects will not be able communicate with each
other, because of same-origin policy. (Anyway, now I am not planning that
they will communicate even on one server per workspace.)
These seem to be not very big problems, probably it is worth it to create a
server per editor, which should be pretty easy to maintain.

>
> btw. who's github branch are you doing this work in ? Would be nice to
> take a look and try run it from time to time.
>
Now it scaterred locally and in old svn workspaces. I will create a vpv
branch in github/yradtsevich/jbosstools-vpe.

>
> /max




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