Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » In 2016, Eclipse Scout will get a brand new HTML5 Renderer
In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1633416] Tue, 24 February 2015 21:29 Go to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 207
Registered: June 2015
Senior Member
It is our belief that the future of business applications mostly lies in the domain of web applications. In consequence, Eclipse Scout needs to provide the best possible web experience for the users of Scout applications. And to achieve this goal for the 2016 release, we already have started to write a new Scout web rendering engine. This engine is directly based on HTML5/CSS3 standards. Thanks to this substantial investment, Scout applications will be able to take advantage of the latest web technologies and comply with the new de-facto standard for web applications.

This decision also implies that future Scout web applications are no longer based on the Eclipse RAP project. At the same time, discussing this topic extensively with our customers, we found that their demand for the existing Swing and SWT rendering components no longer matches the necessary expenses to maintain these components. This is why we decided to discontinue the Scout SWT and Swing desktop rendering components after the Eclipse Mars release.

As this is a significant change, we like to start talking about it early and have also written a corresponding blog post.

The purpose of this forum post is to collect public feedback on this change. Please feel free to ask questions or talk about your concerns.

[Updated on: Thu, 03 September 2015 10:10]

Report message to a moderator

Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1633523 is a reply to message #1633416] Tue, 24 February 2015 22:38 Go to previous messageGo to next message
Santo Mota is currently offline Santo MotaFriend
Messages: 62
Registered: July 2013
Member
so, it means that eclipse scout will not continue working like a desktop aplication?
And what about Mobile? there is a plan to make easier the ability to run an aplication on multi-divice?
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1634289 is a reply to message #1633523] Wed, 25 February 2015 07:34 Go to previous messageGo to next message
Urs Beeli is currently offline Urs BeeliFriend
Messages: 567
Registered: October 2012
Location: Bern, Switzerland
Senior Member
Matthias, thanks for this transparent and open blog post!
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1634379 is a reply to message #1634289] Wed, 25 February 2015 08:34 Go to previous messageGo to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 207
Registered: June 2015
Senior Member
@Santo Mota:

Scout and desktop applications: Yes, you are right, according to the current planning, and starting with 2016 Scout will no longer provide a desktop rendering component. However, it is important to see that this might change again in the future. The clear separation of the application model from the UI rendering technology will not be touched, and the possibility to add a desktop renderer in the future remains intact. Depending on the needs of our commercial customers this topic might come up any time or not. And if we invest in a Scout desktop renderer again, this will likely be based on JavaFX.

Scout and multi-device support: This is scheduled for 2016 too. We would hate to loose the multi-device support that we have now. Therefore, the new HTML5 renderer will come with multi-device support as well. In this respect we do not expect that much will be changed, as we need the capability to write a Scout application in Java once and having it rendered in desktop browsers, on tablets and on mobile devices without any code changes.

I hope to have properly addressed you questions in the statements above, and please, continue this discussion until you feel comfortable with the answers.
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1635072 is a reply to message #1633416] Wed, 25 February 2015 15:59 Go to previous messageGo to next message
Kay Dohmann is currently offline Kay DohmannFriend
Messages: 1
Registered: February 2015
Junior Member
Great decisions to separate Scout from the Eclipse Runtime and OSGi and to develop a new HTML5 renderer!

But for me, I think having multiple renderers is also a very great feature. I always also need a standalone version of my apps. And this can easily be done by generating a desktop app.

As you do not plan to touch the separation of the application model and the UI rendering technology, is it possible that the old Swing and SWT rendering components will still work? Or will you accept community based work on those components to make them work with future Eclipse Scout versions?
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1635480 is a reply to message #1635072] Wed, 25 February 2015 20:34 Go to previous messageGo to next message
Boy D'Poy is currently offline Boy D'PoyFriend
Messages: 67
Registered: October 2011
Member
swithing from RAP to HTML5+CSS+Javascript is OK to me and recommended to you Smile
we have to fit with the state of art, and the default mobile and tablet rendering as now was quite weak.
i personaly in the current app I'm building had to redirect mobile and tablet requests to a Servlet rendering HTML5 + CSS3 + JS + AngularJS ... leading me in fact to develop 2 apps! Sad


Once You Go Scout, You Never Come Out!
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1635895 is a reply to message #1635480] Thu, 26 February 2015 01:16 Go to previous messageGo to next message
Santo Mota is currently offline Santo MotaFriend
Messages: 62
Registered: July 2013
Member
will continue the support for rap aplication renderi after 2016?
another thing, you must do a hard work with those material such a Scout Book 4 and the wiki. it's seem a little change but we must care about several things.
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1636557 is a reply to message #1635072] Thu, 26 February 2015 08:45 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
Kay Dohmann wrote on Wed, 25 February 2015 16:59
But for me, I think having multiple renderers is also a very great feature. I always also need a standalone version of my apps. And this can easily be done by generating a desktop app.

As you do not plan to touch the separation of the application model and the UI rendering technology, is it possible that the old Swing and SWT rendering components will still work? Or will you accept community based work on those components to make them work with future Eclipse Scout versions?


@Kay Dohmann:
Thank you for your feedback and welcome on the Scout Forum.

To be sure to avoid any misconception: with the Mars Releases (June 2015) you still will have the Desktop UIs (Swing and SWT) as you know them today. In order to inform our community early and to allow the community take part in the discussion well ahead of this significant changes we are talking about the N-Release (June 2016) well ahead of time.

Regarding the continuation of the desktop renderers: We expect that the transformation of Scout to a Java framework will break the existing rendering engines. And from our early estimates we think that the necessary work to make them work with the OSGi-free version of Scout will be substantially larger than that for normal release upgrades (and for the SWT renderer more work than for the Swing renderer).

The Scout team is aware that the possibility to create web and desktop applications is a strength of the framework as we know it today. And personally, I did appreciate this feature as well. However, the principal issue was mentioned
by Matthias: so far, we did not find anyone ready to invest in the Swing or/and the SWT renderer. The major projects of our company (applications we sell) have decided to migrate to the new version of Scout and to become web application only solutions. Some other company projects have decided to stay on a version of Scout providing Desktop renderers (they benefit from the Long Term Support that our company is offering). When we started to discuss the roadmap with our customers, we were not so sure about their reaction. This is why we were organizing 1:1 discussion with each customer and for the moment they follow the strategy of BSI.

Now if someone is ready to invest on any Desktop renderer, we will do our best to support such a project. Either by reusing the existing code and transforming it to the new OSGi-free version of Scout or by starting a new rendering engine from scratch (based on JavaFX, for example).

The best way would be to first discuss the details with us (project setup, where to host the code ...). In my opinion you should wait until the big refactorings are over. This means that summer 2015 might be a good time to go into the details of such an approach. I can only encourage you, but keep in mind that this is a lot of work.

PS: Your interest in the future of Scout makes me think that you might have worked with Scout in the past. We would love to hear more from you and who you are (check this story to understand why we are doing this).
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1636888 is a reply to message #1635895] Thu, 26 February 2015 12:27 Go to previous messageGo to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 207
Registered: June 2015
Senior Member
@Santo Mota

Quote:
will continue the support for rap aplication renderi after 2016?


The Eclipse RAP rendering component of Scout will be publicly supported with the Scout Mars release until February 2016. Starting with the N-release, Scout will no longer come with a RAP renderer, instead Scout will be shipped with the new HTML5 renderer.

If you need support for the Scout RAP rendering component for a longer period of time, then you would have to stick to the Mars release and to start about thinking about commercial support.

Quote:
another thing, you must do a hard work with those material such a Scout Book 4 and the wiki. it's seem a little change but we must care about several things.


With the Mars release we plan to have a first version of the Scout book that covers the Scout frontend parts. Depending on the progress of the book, more and more of the content in the Scout wiki will be moved into the book. At the same time we are investigating if we should migrate our LateX based book setup to AsciiDoctor.
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1644554 is a reply to message #1636888] Mon, 02 March 2015 04:20 Go to previous messageGo to next message
Marco Dorfliger is currently offline Marco DorfligerFriend
Messages: 43
Registered: January 2015
Member
Some very exciting changes coming! It's really nice to see such transparent communication of this.

The decision to drop the desktop renderer comes as a surprise. As Matthias remarked, it gave Scout a certain flexibility. I also found the Swing deployment to be noticeably more responsive than RAP (mostly noticeable over slower connections), presumably due to network traffic containing 100% application data (all UI data is already on the client). A web-only release would I suppose also mean no offline mode (a great feature imo), and migration of existing desktop-based Scout projects to the 2016 release remains an open question. As a result, I imagine some adopters opting to remain with the Mars release (as you said some of your commercial projects have done). You may be inadvertently splitting the framework into two 'streams'.

Don't take the wrong message from all this though. It's really great to see BSI staying on top of the game, and I look forward to seeing how the next release manifests.
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1645035 is a reply to message #1644554] Mon, 02 March 2015 09:49 Go to previous messageGo to next message
Matthias Zimmermann is currently offline Matthias ZimmermannFriend
Messages: 207
Registered: June 2015
Senior Member
@Marco

Marco Dorfliger wrote on Mon, 02 March 2015 04:20
... I also found the Swing deployment to be noticeably more responsive than RAP (mostly noticeable over slower connections)


This is exactly one of the focus points of the new HTML5 renderer. With the new renderer we are trying to keep as much state/processing in the browser (without breaking the Scout application model). This leads to immediate responses to user actions in many of the cases which makes the new web UI react to user input without first having to do a server round trip (over a possibly slow connection). Of course, this is not possible in cases where we need access to business rules etc. But with the new HTML5 UI we already see a much improved usability over the current web renderer.

Marco Dorfliger wrote on Mon, 02 March 2015 04:20
... A web-only release would I suppose also mean no offline mode


As of now, we think that we will be able to wait to address the offline topic. This means that we do not yet like to specify if and in which release train we will add the offline feature. So far, we were considering a hybrid desktop approach for the new HTML5 UI that would include a local web server for the client application. With this approach we would then be able to re-create the offline setup you mentioned above. This setup would also allow for integrating client side services such as CTI, bar code scanners, etc.

As we are driven by the business of our customers, Scout's answer to offline and client side intergration might come in the next month or in two years only.

Marco Dorfliger wrote on Mon, 02 March 2015 04:20
... and migration of existing desktop-based Scout projects to the 2016 release remains an open question


With the current RAP renderer, a migration of existing desktop applications to a web application is possible today. With this approach, it is straight forward to check for any features in your current application that might need to be adapted to a web based scenario.

For Scout applications that do need offline capability or other client side integration of devices/services the hybrid desktop approach mentioned above should allow for a good migration path.

For the case when the UI technology of your Scout application must remain on a desktop UI technology, the new HTML5 UI does not fit. This question seems to be simiar to the one posed by Kai Dohmann. Please see this message for our comments

Thanks for your valuable questions, Marco
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1695500 is a reply to message #1645035] Fri, 15 May 2015 10:35 Go to previous messageGo to next message
Marco Dorfliger is currently offline Marco DorfligerFriend
Messages: 43
Registered: January 2015
Member
Something else. The @ClassId annotation was just added in 4.0 to support automated testing. According to the new and noteworthy this feature has only been enabled for Swing and SWT (I tried to enable it for RAP and couldn't find any classid in the html, so I assume this doesn't work for RAP). Jubula (I presume) is the preferred testing tool for those UIs. With the plan to discontinue desktop UI technologies, this testing approach becomes somewhat deprecated, and without web support the @ClassId feature becomes redundant.

Well I imagine that @ClassId values will eventually be embedded into the web UI to support web UI tests (via lets say Selenium). The question is when.

P.S. Is there a chance that Jubula tests written now for Swing/SWT could be migrated to work using the Jubula web driver (via Selenium)? Just thinking out loud. Smile
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1695637 is a reply to message #1633416] Mon, 18 May 2015 09:52 Go to previous messageGo to next message
Bertin Kiekebosch is currently offline Bertin KiekeboschFriend
Messages: 330
Registered: August 2011
Senior Member
The new engine is directly based on HTML5/CSS3 standards. Are there any other libraries or frameworks used for the new rendering engine?
Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1695684 is a reply to message #1695637] Mon, 18 May 2015 13:13 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
I think the Javascript client will have a dependency on JQuery. As far as I know, there is no other dependency.

When the UI layer will be contributed to the Eclipse Repository, we will have the definitive list of dependencies, because we need to indicate them to the eclipse foundation.
The foundation will check them (see IP Cleanliness, in particular "Third Party Dependencies" to know more about it)


Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696574 is a reply to message #1695684] Wed, 27 May 2015 10:35 Go to previous messageGo to next message
Dennis Geesen is currently offline Dennis GeesenFriend
Messages: 46
Registered: June 2014
Member
Since I already replaced the client of one of my scout applications with a HTML5/CSS3 client, I want to share some of my experiences:

First, I tried to use indeed RAP, but the unique feature of RAP (try to emulate SWT in a browser by creating HTML/CSS/JavaScript on the server and push it to the client) is its disadvantage at the same time.
For me, these were the main reasons against RAP:

  • RAP's approach is more old-fashioned (coming from JSP/JSF) than modern (rest-based with html5 web app)
  • adding new or special controls is awful comapared to "normal" web development.
  • there are a lot of cool front-end tools you cannot use, for example a package manager like bower, build tools like grunt or simply frameworks like bootstrap, angularjs and so on.
  • scale out is more complicated


My research and deliberations then took me to the following architecture. The server acts like a microservice. The server offers a REST interface that is able to handle JSON data. The client is based on AngularJS, Bootstrap and Bower/Grunt and communicates over HTTP requests using JSON and the REST interface. This allows me, for example:

  • scale out by simply duplicating the server application
  • use the same REST interface for other apps (e.g. native mobile)
  • use all the cool already existing frontend themes, tools and all the UI/UX stuff (for example: toaster notifications, better form widgets like masked inputs or hierarchical multi-selects, animations...)
  • use bootstrap to have a responsive layout. With a little more effort, the web app is directly suitable for smartphones and tablets. You can even wrap up this html5/javascript client into "native" mobile applications using cordova/phonegap!
  • since the server runs jetty to serve the web-app, I am able to update the server including the web app files and therefore, I can also update all clients. (I had really problems to get synced updates for swt-clients and a scout server before...)


However, starting from scratch is no problem, since there are some cool frameworks like Dropwizard or Spring Boot and front-end generators like Yeoman (which offers different generators for different frameworks), but starting with an existing scout application is not very easy.
Another problem (which was already mentioned) are client side operations like printing or file system operations. For this, I use "node webkit" that wraps HTML5/JavaScript into a desktop-based webkit container. Since node-webkit allows to call node.js directly from the DOM, I am able to call native modules (e.g. the node file system module). Another advantage: the users have the feeling that they use a "normal" desktop application, instead of opening a browser...

Sooo, what I did so far:
I added a REST-API to the scout server using Jackson and Jersey. First, my idea was to simply annotate scout services to enable get/post/delete and so on. However, Jersey/Jackson had some problems during the (de)serialization of the FormData. So I decided to create a new REST-layer with dedicated resources and own DTOs. The resource classes build/wrap the DTOs and just calling the scout services. Since I already had a domain model before, this was not really complicated. But, integrating Jackson/Jersey/Jetty in my scout server and OSGi is not that easy (compared to spring/dropwizard with maven). For example, you have to manually start Jetty to be able to inject the resources.
I also refactored the server to be a rcp product, so that it is runnable standalone without tomcat (why putting a running jetty into a tomcat!?). So, my server is now a REST-based microservice.
Finally, I used AngularJS, Bootstrap and node-webkit to create a desktop-based web app against the REST-API.

Although there are some problems you did not expect from a java/swt-point of view (like multiple modals or stackable forms), there is nothing I am missing compared to SWT. Except of the tooling and form generators from scout Smile


Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696612 is a reply to message #1696574] Wed, 27 May 2015 13:32 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
Hi Dennis,

It seems to me that you have an interesting set-up. Thanks for sharing.

Dennis Geesen wrote on Wed, 27 May 2015 12:35
Another problem (which was already mentioned) are client side operations like printing or file system operations. For this, I use "node webkit" that wraps HTML5/JavaScript into a desktop-based webkit container. Since node-webkit allows to call node.js directly from the DOM, I am able to call native modules (e.g. the node file system module). Another advantage: the users have the feeling that they use a "normal" desktop application, instead of opening a browser...


Have you evaluated Electron from the Atom project?
This project is often mentioned. It looks really similar to what you have with node webkit.

I wonder if something similar exists for the JVM? It would be nice to have something like that to be able to consume the JVM ecosystem from the browser. I am not familiar with the node.js ecosystem.
I have seen that JavaFX provides a web-view (also Webkit based I think), but I never experimented with it.

Dennis Geesen wrote on Wed, 27 May 2015 12:35
I also refactored the server to be a rcp product, so that it is runnable standalone without tomcat (why putting a running jetty into a tomcat!?).

We are using the servlet brigde approach. It wraps an equinox runtime into the war (not the jetty runtime). I agree with you, the solution is not nice (and one motivation to go away from OSGi).

Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696644 is a reply to message #1696612] Wed, 27 May 2015 15:37 Go to previous messageGo to next message
Dennis Geesen is currently offline Dennis GeesenFriend
Messages: 46
Registered: June 2014
Member
Jeremie Bresson wrote on Wed, 27 May 2015 15:32

Have you evaluated Electron from the Atom project?
This project is often mentioned. It looks really similar to what you have with node webkit.


Yes, I do and I also use it in another project. Although it is basically the same, I also think Electron has some more features. My simple problem was: I found it too late and I already started with node webkit Smile

Jeremie Bresson wrote on Wed, 27 May 2015 15:32

I wonder if something similar exists for the JVM? It would be nice to have something like that to be able to consume the JVM ecosystem from the browser. I am not familiar with the node.js ecosystem.
I have seen that JavaFX provides a web-view (also Webkit based I think), but I never experimented with it.


Yes, I had exactly the same thoughts!!! Their main approach is to offer desktop-only applications using JavaScript only. Therefore I think it is a good approach.
Since I also not familiar with node.js, I seriously considered to implement such a "jvm-webkit" framework. Due to this, I also looked at JavaFX and its web-view and alternativesto get a simple construct.
My main conceptual problem is: How to invoke and map Java entities and functions from/to JavaScript without getting an ugly mix of Java and JavaScript. However, I started to look at exploiting the nashorn engine for that...
But at the moment I have no time for some experiments...

If there is a demand, maybe I will start the project Very Happy

Re: In 2016, Eclipse Scout will get a brand new HTML5 Renderer [message #1696860 is a reply to message #1695500] Fri, 29 May 2015 07:05 Go to previous message
Jeremie Bresson is currently offline Jeremie BressonFriend
Messages: 1250
Registered: October 2011
Senior Member
Marco Dorfliger wrote on Fri, 15 May 2015 12:35
Something else. The @ClassId annotation was just added in 4.0 to support automated testing. According to the new and noteworthy this feature has only been enabled for Swing and SWT (I tried to enable it for RAP and couldn't find any classid in the html, so I assume this doesn't work for RAP). Jubula (I presume) is the preferred testing tool for those UIs. With the plan to discontinue desktop UI technologies, this testing approach becomes somewhat deprecated, and without web support the @ClassId feature becomes redundant.

Well I imagine that @ClassId values will eventually be embedded into the web UI to support web UI tests (via lets say Selenium). The question is when.

P.S. Is there a chance that Jubula tests written now for Swing/SWT could be migrated to work using the Jubula web driver (via Selenium)? Just thinking out loud. Smile


There will be an inspector Modus (triggered with an URL-parameter "?inspector=true").

When activated, you see the references of the Scout model classes name and ids in the DOM:

index.php/fa/21998/0/

This is a possibility for you to plug a testing tool like Selenium or Jubula.

Jubula is not the recommended testing tool for Eclipse Scout, but it is a nice open-source tool (also hosted by the Eclipse Fundation). We did some prototype and presentation together (see EclipseCon archive).

If you have a Jubula Testing Suite, reusing your suite to test the new web-ui seems a good approach. I have no idea how much it will be to get there.
Do not hesitate to share your findings. Maybe other members of the Scout/Jubula community will be interested.
Previous Topic:Problem with docx4j
Next Topic:RAP FileChooser
Goto Forum:
  


Current Time: Sun Nov 19 12:43:03 GMT 2017

Powered by FUDForum. Page generated in 0.02354 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software