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

[Max Rydahl Andersen]

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

I guess those changes will actually leak into the various templates ? i.e. the code would have to do "if browser=ie do X else do Y" ?

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

interesting idea.

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

well multiple open ports for an app is not exactly awesome.

Especially not if these threads aren't fast to shutdown (i.e. instantly) 

How about multiplexing these somehow - can you control part of the useragent or other parts of the browser which you could use in the request to make the server respond differently ?

i.e. useragent set to "VPV-root: xxxx/project/" and let the server respond accordingly?

Someway to expose the properties the visual page editor already have in context of "root" and "absolute root" settings already.

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

okey - let us know when something to look at.

/max