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