Servoy 3.0 Beta 1

Classic Servoy
1

We announce the immediate availability of Servoy 3.0 Beta 1

This version is available through download page on Servoy website (developer section)

NOTES:
-This is pre release SOFTWARE, use with caution and make BACKUPS before you start.
-Perform a clean installation into a new directory, do not install on top of 2.2.x releases (directory)
-Servoy 3.0 will upgrade your repository (after which 2.2 releases will not be able to work with it)
-The new development filters from View menu help you to prevent usage of thing which do not (yet) work in webclient

Enhancements:
[enh]-webclient (turns existing forms into webpages)
[enh]-possible to disable all the autosave with databaseManager.setAutoSave(…)
[enh]-data edits are possible to revert/cancelled without transaction databaseManager.rollbackEditedRecords()
[enh]-controller.focusFirstField() //focus the first field from tab seq in the body part
[enh]-better databaseManager.switchServer sample code
[enh]-support for getNameAt/getFormNameAt/getTitleAt on tabpanel
[enh]-printing keeps JavaScript changes
[enh]-application.setNumpadEnterAsFocusNextEnabled(…)
[enh]-application.getApplicationType(…) [enh]- application.getValueListDisplayValue(…)
[enh]-application.getValueListArray(…)
[enh]-batch processors can now be deleted
[enh]-utils.getUnicodeCharacter(…)
[enh]-development filters under view menu
[enh]-server update function

Changes:
[chg]-dataset returns the columnsnames as provided by database http://forum.servoy.com/viewtopic.php?p=27509#27509 (this might influence your code if depending on lowercase string compare!)

Issues:
If you are unsure something is a bug, please discuss it on the forum, if something is a bug please file it at:
http://crm.servoy.com/servoy-webclient/ … oy_support (also file your feature requests here)

----Web Client Info---- see also webclient forum http://forum.servoy.com/viewforum.php?f=34

What is the Servoy Web Client:
Servoy Web Client deploys existing Servoy Forms as pure html and CSS in a standard web-browser. With Servoy Web Client you can develop pure web-browser apps without any html/css coding!
-It is built on top of the headless client API and consumes a single concurrent client license just like the current headless client
-Accessible when servoy 3.0 is running at http://localhost:8080/servoy-webclient

Differences between Servoy smart client and web client:
-There is no “auto save” of data when clicked on the form, you (or your developer) need to place ‘save/submit’ button which executes the command: controller.saveData()
-Interactive beans/applets can not be used, charting beans are supported(converts the bean UI to image for display in browser)
-Shapes, pen drawings and such will likely not be supported
-RTF cannot be supported
-Listview/multiline portal will not be supported in first version

Current Limitations: (when using the web developement filter, servoy does not show the properties/methods below)
-ANY dialogs, using them stalls the Web Client
-Not all events are supported like onFocusGain
-Rectangles with title border
-Editable HTML area field (non editable HTML fields are working)
-Anchors are not currently working in webpage
-JavaScript manipulation of form elements (visible/read-only is working)

HTML Templates:
-Servoy Web Client generates HTML templates from a Form, which can be edited by a web designer
-Templates are editable via WebDav (like windows web folders) or can be viewed in the browser at http://localhost:8080/servoy-webclient/templates
-The templates are always generated from the latest changes on a form until manually edited and saved
-After deletion of edited files, the templates are generated again.
-Restrictions to the templates, you cannot remove the “servoy:xxxx” parameters in the html tags
-Webdav access is restricted with admin-user rights

Will default only work on Java 5!
To run Servoy 3.0 under Java 1.4.x use: java - Djava.security.policy=“./server/conf/catalina.policy” -jar servoy_developer.jar

2

Jan & Team:

Yeah! I’ve been waiting for this release patiently.

Can you confirm two things for me.

  1. Support of SQL Views.

  2. Support for active directory in security. This was mentioned at training last year in Phoenix, but I heard this might be handled in the form of an add-on/plugin.

These are two very important issues for us, and part of the reason I’ve been hanging on the fence for so long.

Thanks!
Lee

3

I might not bee seeing something, but where ont he developer website can you donwload this beta?

I seem to end up in a WebClient solution of Servoy ( :D ) where I can only download the latest 2.2 final and 2.2 beta’s, or so it seems to me.

What happened to the option that was there for a while to also be able to download older releases and beta’s?

Paul

4

bubba:
Jan & Team:

Yeah! I’ve been waiting for this release patiently.

Can you confirm two things for me.

  1. Support of SQL Views.

  2. Support for active directory in security. This was mentioned at training last year in Phoenix, but I heard this might be handled in the form of an add-on/plugin.

These are two very important issues for us, and part of the reason I’ve been hanging on the fence for so long.

Thanks!
Lee

  1. Views are supported in 3 (also in the current beta)
  2. This is in progress. Most likely this will be avail in 3, either built by Servoy or a third party plugin.
5

pbakker:
I might not bee seeing something, but where ont he developer website can you donwload this beta?

I seem to end up in a WebClient solution of Servoy ( :smiley: ) where I can only download the latest 2.2 final and 2.2 beta’s, or so it seems to me.

What happened to the option that was there for a while to also be able to download older releases and beta’s?

Paul

Currently you can download 2.2 and 3.0beta from the download page. We are working on making older builds available as well.

6
  1. Views are supported in 3 (also in the current beta)

Jan, can you shine your light on this one?

Is it possible to make views from inside Servoy?
How can we work with this feature? maybe some examples?

thankx

7

It just works. Launch 3 and it will show all views. You cannot create views from within Servoy. Currently views are displayed as tables but we will most likely put them under a subheader in final.

8

jaleman:

bubba:
Jan & Team:

Yeah! I’ve been waiting for this release patiently.

Can you confirm two things for me.

  1. Support of SQL Views.

  2. Support for active directory in security. This was mentioned at training last year in Phoenix, but I heard this might be handled in the form of an add-on/plugin.

These are two very important issues for us, and part of the reason I’ve been hanging on the fence for so long.

Thanks!
Lee

  1. Views are supported in 3 (also in the current beta)
  2. This is in progress. Most likely this will be avail in 3, either built by Servoy or a third party plugin.

Jan:

Do you have any more info. on the Active Directory support? Approximate time frames? Sorry, but this is important, and I’m worried that it seems to be up in the air at the moment. I was anticipating this would be part of V3. I don’t mind if it costs a few bucks more, but I would appreciate some assurances that it will be available in the not too distant future. Otherwise, deployment becomes a very big headache for me, as I will be in a mixed FM, Oracle and Servoy environment for quite some time.

Thanks again!
Lee

9

LDAP will be available either by default or as a (paid for) option in 3, so nothing to worry about.

10

In general, how will the performance of Web Client compare with a similar solution in 2.2.4?

As I understand it, Web Client runs a virtual client on the server feeding JSP code to the user’s browser. In performance terms this could cut two ways. Loading, searching and sorting functions could be faster, just as they are under Localhost, in contrast to the user’s Java applet drawing data from the server. On the other hand, there may be a performance hit in generating JSP pages for the user’s browser.

I’ve not yet seen any version of 3.0, so I’m speculating somewhat blind.

11

Hi Morley,

The performance should be in the range of Headless Client, thus pretty fast.
Also the pages are not JSP (as this is server side code) but HTML.

You hint that the richt client is slower in fetching data from the server.
But it’s in fact more efficient than any HTML solution since it caches already retrieved data on the client. Not so with any pure HTML solution (which Web-client is)

Hope this helps.

12

ROCLASI:
The performance should be in the range of Headless Client, thus pretty fast.
Also the pages are not JSP (as this is server side code) but HTML.

You hint that the richt client is slower in fetching data from the server.
But it’s in fact more efficient than any HTML solution since it caches already retrieved data on the client. Not so with any pure HTML solution (which Web-client is)

The existing Rich Client is more efficient than the forthcoming Web Client? Am I reading you correctly?

In my solution Rich Client via a server is about three to four times slower than Servoy Developer via localhost. Thus, coding which seems fine in Developer can be found unacceptable when served to users.

I have no comparison benchmarks for Headless Client performance.

13

Morley,

Are you comparing speeds between apps running locally and apps running over a network ?
Apps running locally are most likely faster then apps running client-server, period. The network is the bottleneck.

But yes, the rich client is more efficient in traffic than any pure web client. Although with AJAX things can be way more efficient.

14

Hello,

what does this position mean:

[enh]-printing keeps JavaScript changes

Is it now possible to set the page setup by scripting?

Thanks
Hans-Peter

15

Hello Hans-Peter

Yes this is now possible.

When you change element properties they are printed as they are currently set on the screen in stead of how they were set in developer.

See also:

Kind regards Rene

16

Hello Rene,

Thanks for bringing some light to me about this feature. In this context I have to questions:

  1. How are you dealing with dynamic things like “element.settings based on a field value” ?

For example like the following code which is used on a record view report:

if ( pobox_status )
{
 //set label pobox visible
 elements.fl_label_pobox.visible = true;
 elements.ffxtxt_label_pobox.visible = true;
}
else
{
 //set label pobox invisible
 elements.fl_label_pobox.visible = false;
 elements.ffxtxt_label_pobox.visible = false;
}

This code works as long as only one record should be printed. But if I 'm printing multiple records which have different values in “pobox_status”, I need an event like “onPrintRecord” or better “beforePrintRecord” :). This event has to work on a print preview, doesn’t it?

At the moment the settings are based on the “pobox_status” from the first record, and the code has no effect on the following records because it is executet before the print preview is shown.

At the moment the only solutions I’m seeing, are a html area (I don’t like html for printing → pagebreaks, etc.) or calculation fields (in this case ends up in two more calcs only for a gui effect → label and field).

  1. How can I set page settings like: size, orientation and margins by scripting?

Thanks for help
Hans-Peter

17

Hi Morley,

I just happened to notice this post of yours of a week ago or so.

In my solution Rich Client via a server is about three to four times slower than Servoy Developer via localhost. Thus, coding which seems fine in Developer can be found unacceptable when served to users.

Based on this I would definitely say that there is some network bottleneck going on there as Robert suggested. The regular Servoy client is always faster than Developer in my experience unless the client has some network issue. This stands to reason as there is so much more going on in Developer. Sometimes, when I notice a little pause running some method on Developer, I look at it using Client (with the same network access) and it is always instantaneous. If you ever notice things are faster in Developer than the client there is definitely something going with the network setup.

18

john.allen:
Hi Morley,

I just happened to notice this post of yours of a week ago or so.

In my solution Rich Client via a server is about three to four times slower than Servoy Developer via localhost. Thus, coding which seems fine in Developer can be found unacceptable when served to users.

Based on this I would definitely say that there is some network bottleneck going on there as Robert suggested. The regular Servoy client is always faster than Developer in my experience unless the client has some network issue. This stands to reason as there is so much more going on in Developer. Sometimes, when I notice a little pause running some method on Developer, I look at it using Client (with the same network access) and it is always instantaneous. If you ever notice things are faster in Developer than the client there is definitely something going with the network setup.

Hi John,

Let’s be clear we’re talking about the same thing. With Developer I’m running two ways. Principal development is via Servoy’s default environment using localhost, i.e. no network at all. The advantages being I don’t worry about mangling my development test data and I don’t disturb the production server. Performance is always almost instantaneous.

I also test with Developer pulling data from the production server via the internet. This is always slower than via localhost. For instance, the loadRecord() function can take a second or two, occasionally more, instead of a few milliseconds. This form of testing gives me a preview of performance bottlenecks without having to commit a new release to the server. Servoy Client over the net, on the other hand, is somewhat faster than Developer over the net. I’ve not performed an exact comparison, but that’s the impression.

In my original posting I was hypothesizing the possibility Servoy3 could move towards the performance of Developer localhost. For the following reasoning. By running a virtual client locally on the server, Servoy3 may be more efficient than the dialogue of Servoy2 client to server to client. I emphasize “may” because there are several other factors at work here as well, such as the new additional task of generating HTML and then drawing the screen. So, in some ways, my speculation was also a hope.

Robert seems to think Servoy3 will be slower than Servoy2, all other things being equal. I’ve heard nothing to confirm or deny his expectation. I’d be very interested to know the results of some field testing.

Let me know if I was understanding your points correctly.

Kind regards,

19

Hi Morley,

By running a virtual client locally on the server, Servoy3 may be more efficient than the dialogue of Servoy2 client to server to client. I emphasize “may” because there are several other factors at work here as well, such as the new additional task of generating HTML and then drawing the screen.

Leaving aside the HTML/screen redraw for a moment, as far as my understanding of how 3 works as a web client is that there is no possibility of it being faster than the regular client. Communication still has to go via the Servoy server and then to the database server back the same way and then to the local browser. And I can’t imagine that there could be ‘less’ network traffic even with AJAX than with the regular client. When you bring in the screen redraw stuff - again even with AJAX - I think it is bound to be slower. I’m a little prejudiced admittedly because of a constant battle going on here over browser based solutions. And I love the fact that Servoy is doing the web client because there is a real need for it. But for a solution that will have users doing constant data entry, my feeling is that the regular client will always be the way to go. A browser is built for browsing: great for offering clients who need access anywhere, anytime and who aren’t having to use it all day long entering data. But those needing to use a solution constantly, the control, richness and speed of a regular application is always better: it doesn’t have to get funneled through a browser.

We do have very fast connections here but I find with my solutions that the client solutions via the internet are still faster than Developer running locally. Both are very ‘fast’ - no problems at all - but my experience is that the client on a fast network is even faster than Developer locally.

John

20

john.allen:
We do have very fast connections here but I find with my solutions that the client solutions via the internet are still faster than Developer running locally. Both are very ‘fast’ - no problems at all - but my experience is that the client on a fast network is even faster than Developer locally.

John

Thanks for your comments, John. They clarify the lay of the land considerably. In light of your remarks I’ll be tilting my users towards the rich client rather than the web client. It’s easy for the timid to opt for the familiar web browser route but performance is always a significant issue.

Overall (excepting a few functions) my solution performs well via Servoy Client over the internet but Servoy Developer localhost always trumps it – the direct opposite of your experience. I’m guessing you’re not going out to the internet cloud on your connections.

Kind regards,