Ralf Sternberg | b0b7a03 | 2015-05-07 13:10:03 +0200 | [diff] [blame] | 1 | <div> |
| 2 | |
| 3 | <h2>Re-Parenting Support</h2> |
| 4 | |
| 5 | <p> |
| 6 | The method <code>Control.setParent()</code> is now fully implemented and will move a control |
| 7 | from one parent to another. To indicate that the re-parenting was successful, the method will |
| 8 | return <code>true</code>. We implemented re-parenting in order to better support the E4 UI. |
| 9 | </p> |
| 10 | |
| 11 | <p> |
| 12 | Be aware you must not try to replace the parent of a control that is attached to another widget |
| 13 | using a <code>setControl()</code> method (e.g. a CoolItem, an ExpandItem, or a ScrolledComposite). |
| 14 | Those cases are neither supported by SWT nor by RAP. |
| 15 | </p> |
| 16 | |
| 17 | <h2>New client service StartupParameters</h2> |
| 18 | |
| 19 | <p> |
| 20 | In RAP 2.x, you could access URL parameters by calling <code>RWT.getRequest().getParameter(name)</code>. |
| 21 | The problem with this approach was that it only worked in the first request. |
| 22 | Moreover, <code>RWT.getRequest()</code> returns the actual XHR request, not the request that |
| 23 | returned the HTML page. That's why using this method in application code is not recommended. |
| 24 | </p> |
| 25 | <p> |
| 26 | Now there is a client service named <code>StartupParameters</code> that provides access to those |
| 27 | startup parameters. Since this service interface is also implemented by <code>AbstractEntryPoint</code>, |
| 28 | you can access the methods <code>getParameter()</code>, <code>getParameterNames()</code>, |
| 29 | and <code>getParameterValues()</code> directly in your entrypoint: |
| 30 | </p> |
| 31 | |
| 32 | <pre lang="java"> |
| 33 | public class MyEntryPoint extends AbstractEntryPoint { |
| 34 | |
| 35 | @Override |
| 36 | protected void createContents(Composite parent) { |
| 37 | String foo = getParameter("foo"); |
| 38 | ... |
| 39 | </pre> |
| 40 | |
| 41 | <h2>Move to Java 7</h2> |
| 42 | |
| 43 | <p> |
| 44 | As many other Eclipse projects, we recently decided to raise the minimal execution environment |
| 45 | to Java 7. |
| 46 | Since Jetty 9 and even some parts of Equinox now depend on Java 7, it became almost impossible |
| 47 | to run and test RAP with Java 5. |
| 48 | Moving to Java 7 makes our life easier and allows us to make use of some new features. |
| 49 | With modern JREs being available even for embedded platforms, so we think that we won't |
| 50 | exclude anyone by this move. |
| 51 | </p> |
| 52 | |
| 53 | <p> |
| 54 | The Bundle-RequiredExecutionEnvironment (BREE) of all bundles has been updated to <em>JavaSE-1.7</em>. |
| 55 | </p> |
| 56 | |
| 57 | <h2>Goodbye quirksmode!</h2> |
| 58 | |
| 59 | <p> |
| 60 | RAP used to enable the so-called quirksmode in HTML in order to avoid glitches in old |
| 61 | IE versions. With the end of support for antique browsers, RAP now uses the HTML5 |
| 62 | <code><!DOCTYPE html></code> declaration that enables standard mode in all browsers. |
| 63 | </p> |
| 64 | |
| 65 | <h2>Performance optimizations</h2> |
| 66 | |
| 67 | <p> |
| 68 | We started to work on a couple of performance optimizations, namely by reducing the number of |
| 69 | short living objects created during request processing. This reduces the load by the garbage |
| 70 | collection. |
| 71 | Moreover, we reworked the session initialization and removed the need for a transient |
| 72 | UI session when delivering the HTML, which also removes some load from the server. |
| 73 | Some more optimizations are planned for 3.0. |
| 74 | </p> |
| 75 | |
| 76 | </div> |