<p dir="ltr"><br>
On Nov 21, 2012 9:25 AM, "Max Rydahl Andersen" <<a href="mailto:max.andersen@redhat.com">max.andersen@redhat.com</a>> wrote:<br>
><br>
> > 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<br>
> > be using whatever built-into-eclipse browser is enabled by the user on his platform, correct?<br>
> > 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.<br>
><br>
> 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" ?<br>
I hope none or only several of them will be affected, like rich:calendar, which is very complicated and really 'rich'.<br>
><br>
> > > If it is a rewrite we should make sure to move everything that is not public api into internal packages.<br>
> > > Will do it.<br>
> ><br>
> > Would also be good to make an effort on making the API to add support for other libraries more approachable than previous VPE.<br>
> > i.e. documented API's, example of how to do it etc.<br>
> > 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.<br>
><br>
> interesting idea.<br>
><br>
> > > How is that handled?<br>
> > > 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.<br>
> ><br>
> > 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" ?<br>
><br>
> > Good question. I just forget about this root-relative case.<br>
> > 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.<br>
> > Obvious drawbacks of multiple servers are:<br>
> > - we have to manage their creation/disposal<br>
> > - these servers will consume more resources (not much, but at least a port and a connection-waiting thread per each)<br>
> > - 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.)<br>
> > 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.<br>
><br>
> well multiple open ports for an app is not exactly awesome.<br>
><br>
> Especially not if these threads aren't fast to shutdown (i.e. instantly)<br>
><br>
> 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 ?<br>
><br>
> i.e. useragent set to "VPV-root: xxxx/project/" and let the server respond accordingly?<br>
><br>
> Someway to expose the properties the visual page editor already have in context of "root" and "absolute root" settings already.<br>
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.</p>
<p dir="ltr">Today we found that the following approach may work.</p>
<p dir="ltr">If we set URL as <a href="http://localhost:1234/index.jsp?root=xxxx/project/">http://localhost:1234/index.jsp?root=xxxx/project/</a>, 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.</p>
<p dir="ltr">What I like in this approach is that it will also work for any browser, a SWT embedded browser or a stand alone browser.</p>
<p dir="ltr">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.</p>
<p dir="ltr">Another drawback we found is that html frames won't work this way.<br>
><br>
> > 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.<br>
> > Now it scaterred locally and in old svn workspaces. I will create a vpv branch in github/yradtsevich/jbosstools-vpe.<br>
><br>
> okey - let us know when something to look at.<br>
><br>
> /max</p>