Servoy 8.0.0 beta 1

Classic Servoy
1

We are pleased to announce the availability of Servoy 8.0.0 public beta release (releaseNumber 3016)

This version is available through the download at the Servoy website.
Or update your existing Servoy 8 install by checking for updates in your developer.
Note: under windows you could get an error when updating this way because it can’t rename or delete the servoy.exe, this is an eclipse bug.
To fix this just before you do the actual (check) for update rename the servoy.exe to servoy_bck.exe.

Servoy 8 brings a new client type called NGClient, which is based on HTML5 and webcomponent specifications.
For more details see: New in 8.0

This release has the first cut of the responsive design editor including palette items supporting this

In the 12grid category we have the bootstrap 12 grid system
First you need to create a form in relative layout (new form wizard)
then you can place a container div on that, and in a container div you can place rows (and columns again in row)

We also added a basic set of bootstrap components that work better in a relative/responsive layout.
Our default component won’t fully work correctly in such a layout because they are build for absolute positioning.

The new NGClient has many (speed)improvements over the alpha version also the backwards compartible with existing solution should be greatly improved.

Do checkout this page for converting the current style css to a solution css (now stored in media)

Known problems:
Tableview form or portals in relative layout are not fully supported.

Note:
-It is possible to revert to the old form editor for smart/webclient solutions in the developer preferences

2

Congratulations on reaching this beta 1 milestone. The efforts of everyone that has made this possible are appreciated.

Dean Westover

3

I’m having a difficult time getting any sort of responsive form creation to work.

If I try and make a 12grid I can get about as far as putting the Container on the form (sometimes), but I don’t think I ever successfully get a row on the page (I see an outline for it at first, but then it goes away if I try and place a column in it)

Are there any sample solutions or documentation I’m missing?

Windows 7
Java 1.7.0_76

4

Creating a responsive form, then adding a container, rows with up to twelve columns, and fields, seems to be working for me. However, I need to stay in Outline mode in order to keep track of all the elements. Making each type of element automatically appear by default with a different background color would make them easier to work with.

Dean Westover
Choices Software
http://acords.com

Windows 10 Pro - Build 10041
Java 8 update 31

5

jgarfield:
I’m having a difficult time getting any sort of responsive form creation to work.

If I try and make a 12grid I can get about as far as putting the Container on the form (sometimes), but I don’t think I ever successfully get a row on the page (I see an outline for it at first, but then it goes away if I try and place a column in it)

Are there any sample solutions or documentation I’m missing?

You have to place a container component on the form first thing. If you don’t, delete the form and start over. Place rows inside of the container, and columns inside of rows — and then finally various bootstrap CRUD components inside of columns.

That much works. Tab panel functionality is kinda sketched in. No grids of any sort yet.

6

Is there any tutorial about developing NGClient?

Regards,

7

We will be making ServoyU videos once the designer for the 12grid Bootstrap system gets closer to completion.

We are also working on a converter to convert standard Bootstrap templates to Servoy Forms: https://www.youtube.com/watch?v=4Zdq6OtNpIU

8

Ok, thanks, Scott!

9

Hi Scott, Your converter looks great!

Dean

10

goldcougar:
We are also working on a converter to convert standard Bootstrap templates to Servoy Forms: https://www.youtube.com/watch?v=4Zdq6OtNpIU

Start with html (DOM), convert it to Servoy .fm format (SOM), Servoy converts it back to html (DOM). Irony. I could write an Onion article on this. “Decepticon Browsor VIII is to blame…”

I’m all for “Easy” and I think Servoy 8 is stumbling its way to this point (the bootstrap editor needs to get a lot better). “Easy” is really useful for scaffolding or prototyping phase of development. In many situations, this is all you need (internal business apps, learning, data analysis, management screens). Easy == Rapid typically and leveraging this is an important part of application development.

Rarely does Easy == Great Code though. It doesn’t matter as long as you stay within the bubble/capabilities/demands you can accomplish with “Easy”. It does matter when you need to step up to the plate and deliver public facing professional apps. This would be ISV’s, business workflows that interface with customers, high traffic websites, etc. Easy is not the prime requirement here — flexible, simple, performant, pluggable, scaleable, refactorable — these suddenly become way more important than “easy”.

And rated against these criteria, Servoy NG Client is a horror show. Let’s just agree on this for a moment as my point is that it shouldn’t matter.

To Servoy’s credit, “Easy” is really really…REALLY…hard to do. FlexibleSimplePerformantPluggableScaleableRefactorable is even harder (Meteor, Angular 2, RactiveJS, ReactiveJS, Ember 2, Ext, Kendo, Knockout, Aurelia, Sails — just off the top of my head — all with varying degrees positives and negatives).

Easy and FlexibleSimplePerformantPluggableScaleableRefactorable?!? I don’t care what Servoy marketing says or smoke-and-mirror demos…I’ll also sell you a bridge in the desert.

Solution

Instead of trying to do it all in one development workflow, Servoy needs a FlexibleSimplePerformantPluggableScaleableRefactorable Mode. The same recommendation I made for Servoy 7 beta still stands: provide a standalone client-side data proxy of Servoy foundsets and records. (All of the code is in Sablo already, just needs to be untangled from the Angular/Component assumptions.) Adaptors (a representative example: https://github.com/ractivejs/ractive-adaptors-backbone) would be the final link from Servoy’s data proxy to any client-side framework. A new super cool framework gets released, just write an adaptor in a few days — instead of creating a new version of Servoy in a few years — and keep on rolling with your current code base.

In the hands of experienced developers, this mode provides a sane approach to handling complexities that require a lot of nuance and optimization, insulates us from Servoy bug dependency, and allows us to keep up with current tech progress.

Easy Mode is then no longer defined by what it can’t do or how bad it is or the special workarounds it requires to make better — but by how much leverage and efficiency it brings to the entire application development picture. Junior developers (non-programmers even) and experienced developers can be productive alongside each other. Workflows can be sketched in fast and iterated on many times with no efficiency loss. Risk is mitigated because the hard stuff (typically advanced client-side UI’s) isn’t tackled until an exact picture of what is required has been worked out. Advanced client-side UI’s are developed faster because a lot of the server-side code and data modeling is already done when you get to this stage.

I’m not making this stuff up because this is what we’ve been doing for a couple of years now using another tech as our RAD base tool. It is a crazy productive approach — Servoy needs this “development pipeline” approach as well. NG Client by itself isn’t enough. Browser development tech is moving way too fast for one monolithic approach to keep up.

Concentrate on making NG Client as easy and fast as possible to do stuff with and pair with a FlexibleSimplePerformantPluggableScaleableRefactorable outlet. (The latter should have been done in Servoy 7.) Without something like this in place Servoy’s potential and capabilities are hard capped.

11

David in servoy 8 you have the foundset type. that is a client side data proxy over the foundset and its records…

Thats how our portal works (but thats more complex because that also uses the “component” type in combination with the foundset type)

12

jcompagner:
David in servoy 8 you have the foundset type. that is a client side data proxy over the foundset and its records…

Thats how our portal works (but thats more complex because that also uses the “component” type in combination with the foundset type)

That’s the idea. But the only way to get this data proxy to a page is through all of your Angular wiring.

Would like the ability to include the sablo session/websocket/server communication stuff and foundset client-side data proxy to the client independent of any client-side framework implementation. Then we can write our web clients any way we choose (by hand of course).

You are throwing the kitchen sink at the client currently. Even if this works for 80% of cases, the remaining 20% of cases have REST (and headless client) as the only fallback. Being able to work with Servoy foundsets directly on the client with all the websocket wiring would be a pretty cool power user tool.

13

While I agree it would be “cool” for Servoy to expose those extra layers so you can build your own custom front-ends on any framework you want, I disagree that its what they should be focusing on. Servoy is about RAD. As with most RAD tools, the deployment frameworks are chosen for you by the RAD tool. Folks that know enough to write their own custom front-ends in the latest/coolest frameworks aren’t really Servoy’s target customer. There are few that would really use it. So, yes, it would be cool, but at what cost, and who would really use it?

The .frm/.html thing is quite annoying (at first). As a developer, I would prefer to edit the HTML of my front end manually, not with a WYSIWYG form designer. However, Servoy stores metadata information about the form design in a JSON structure in the .frm files, so it just isn’t possible. While it is annoying, I get why they do it. If you were an ISV that decided on Servoy many years ago, you had a nice RAD tool to build Java Web Start apps (smart client). Then the web came along, and they gave you Wicket (web client). Then the web 2.0 came along, and now you get AngularJS (ng client). As an ISV, Servoy is future-proofing for you. You only had to build your app once, and Servoy made it work as new technologies came out. Not a lot of tools have successfully pulled that off, but Servoy, to their credit, has done a great job of that!

Should they make it so you can deploy on any framework you want…sure, that would be cool, but its not really why people choose Servoy…IMHO.

14

Should they make it so you can deploy on any framework you want…sure, that would be cool, but its not really why people choose Servoy…IMHO.

Very much +1

15

goldcougar:
Servoy is about RAD. As with most RAD tools, the deployment frameworks are chosen for you by the RAD tool. Folks that know enough to write their own custom front-ends in the latest/coolest frameworks aren’t really Servoy’s target customer. There are few that would really use it. So, yes, it would be cool, but at what cost, and who would really use it?

I agree with the RAD part. But in your history lesson, you completely missed a very important dynamic change: there used to be a huge gap between the RAD/4GL tools and — for lack of a better characterization — “traditional” programming. Personal example: I went directly from a job doing COBOL/JCL on 360’s to a many multi-million $$ company running entirely on FilemakerPro apps the owner had built entirely on his own — a salesman who didn’t graduate high school.

Browser development has narrowed this gap between RAD/4GL and “traditional” down to a few extra days of study instead of an entire college degree (ex: Meteor). In a couple of years, even this gap will be gone (ex: Jetbrains IDE Meteor integration, MS .Net tools, Telerik App Builder) — browser development is the new 4GL.

goldcougar:
As an ISV, Servoy is future-proofing for you. You only had to build your app once, and Servoy made it work as new technologies came out. Not a lot of tools have successfully pulled that off, but Servoy, to their credit, has done a great job of that!

I very much don’t agree with this. Browser development has exploded in the last five years and the next two years will make the last five look like a small blip — Servoy’s NG Client is already well behind the curve. I would describe it more as a not-easily-hackable impossible-to-tune not-close-to-being-polished RAD tool based on obsolete technology. “Over engineered” comes to mind.

As a RAD tool though, NG Client provides one important leverage point. But it needs the 2nd leverage point I outlined above to really be future proof.

People choose tools like Servoy because of the RAD aspect. They leave these tools because of their limitations. NG Client by itself has a lot of limitations.

16

Are you planning to include sample webcomponents and sample NG solutions in the installer?

17

+1

18

Should they make it so you can deploy on any framework you want…sure, that would be cool, but its not really why people choose Servoy…IMHO.

I agree.

Also:

#1. currently, there is a whole lot of demand for front-end design/production and a scarcity of resources, so you might have trouble finding good people who are free and available to help you build the front-end. Servoy takes that problem away -not to mention the cost to develop a front-end.

#2. David: the Velocity Report plugin/Velocity Web client can help you. Configure it, and you’ll get just JSON objects that you can use. You did’t need to wait for Servoy 8. Velocity can be your data proxy of Servoy’s foundsets and records!

19

jcarlos:
#1. currently, there is a whole lot of demand for front-end design/production and a scarcity of resources, so you might have trouble finding good people who are free and available to help you build the front-end. Servoy takes that problem away -not to mention the cost to develop a front-end.

#2. David: the Velocity Report plugin/Velocity Web client can help you. Configure it, and you’ll get just JSON objects that you can use. You did’t need to wait for Servoy 8. Velocity can be your data proxy of Servoy’s foundsets and records!

+1

The good thing about #2 is that it is highly configurable, so you can basically choose how your back-end will behave:

3 levels of headless client instantiation (per solution):
 application (one headless client to rule them all!)
 pool (just like the REST plugin, but much better!)
 session (one headless client per HTTP session)

 In session mode, your session is stateful
 (Actually it can be stateful also in any mode…

source: http://www.servoycamp.com/images/camp14 … ypower.pdf

20

Just so we’re talking about the same things, a digression:

1. Velocity Web Client is an apple — the server is the lead:

a. browser sends request
b. logic runs on server: context/data + template + code to combine
c. entire response sent back to browser (html merged with data) is sent back to the browser

There is no data broadcasting between clients like you’re used to in standard Servoy clients (other realtime: RethinkDB, Firebase, Meteor, Derby). You have to roll your own AJAXy stuff like any other web technology to update your UI when data changes.

2. NG Client is an orange — the browser is the lead:

a. browser sends request
b. server responds with lots of html templates and lots of code
c. browser runs the returned code: requests data from server, combines data results from server with the html templates, and finally renders the results results

NG Client uses the Angular (v1) framework for helping to construct everything client-side. There are a LOT of other frameworks but a couple of years ago Angular caught on in a big way and pulled somewhat ahead of the pack. Today the scene has normalized quite a bit and with ES6 and ES7 there are a host of others incoming. All of which are more powerful and easier to use than the last.

The new thing with NG Client is how the browser is sending and receiving data from the browser after the initial load of a page. Instead of REST/AJAX/Polling it is using web sockets. Servoy is using this to “data broadcast” between all clients very efficiently. Browsers have had this for a while now and Servoy has now implemented this on their server.

Realtime web with any JDBC database with Servoy foundsets. This__is__a__big__deal.

3. Apples and oranges

There is a “combo” approach to delivering web apps and that is by delivering an apple when a page first loads and then switching over to being an orange for all interaction thereafter. The idea here is that a pre-rendered html page (with initial data) is faster to load up. This approach was made famous by Twitter (~2010?).

Recently, client-side frameworks come with the ability to run server-side as well (typically with Node server). This allows server pre-rendering at the component level using the same code written for the client. So for example, when you switch to a tab panel that has a grid of records — a pre-rendered view of records is presented initially (no multiple trips to the server, no code run client-side == very fast) and then as you scroll, websockets + client-side framework code takes over to load additional data into the grid.

But I digress…

  1. Velocity has its place but it is only one tool in a power user’s toolbox. In Sutra CMS, we use Velocity to produce the reports that we deliver to the web client even though we use JSP and Servoy headless client for the web server tasks. Velocity is a great mix-and-match tech and does some neat stuff server-side that would be a royal PITA otherwise. (Back in Smart Client days, Velocity was a life saver.)

  2. I’m not arguing against the east-of-use approach Servoy is taking for NG Client. I’m just saying NG Client has a lot of limitations — the kind of limitations an equivalent to Velocity would solve. My argument then is that Servoy should make their session/websocket/foundset piece a discrete API that can be use to put realtime data in any web application using any front-end tech.

And with your front-end tech of choice, Velocity doesn’t go away either: it gets used for pre-rendering and other template-based server-side tasks (we use server-side templating all over the place).

This does not take anything away from NG Client. If NG Client is all you need, perfect.

Next post all is solved…