6:38 p.m.
On Nov 21, 2012 9:25 AM, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
wrote:
> 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" ?
I hope none or only several of them will be affected, like rich:calendar,
which is very complicated and really 'rich'.
> > 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.
I wouldn't like to change the user agent, because client logic may depend
on it. Changing/adding of another request headers won't work in WebKit.
Today we found that the following approach may work.
If we set URL as http://localhost:1234/index.jsp?root=xxxx/project/, then
all linked resources will be requested with the 'Referer' header set to
this URL. This header may be used on the server to return right resources.
What I like in this approach is that it will also work for any browser, a
SWT embedded browser or a stand alone browser.
Redirects/clicks from one page to another should be handled separately, but
it is possible in SWT to do URL rewrite before the page requests are sent.
Another drawback we found is that html frames won't work this way.
> 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