Servoy 6.1

Servoy announcements

Re: Servoy 6.1

Postby david » Wed Jul 11, 2012 12:11 am

Hammered through 6.1 testing last few days. A major bug (for us anyways) that is still outstanding (resizing tab panels not in sync with window resize):

https://support.servoy.com/browse/SVY-2588
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby rossent » Wed Jul 11, 2012 3:46 pm

jcompagner wrote:Rossen,

At the moment this freeze happens, can you go to the admin page and dump the stack? So that we can say what it currently does?

This is also a tip for everybody reading this, if in developer (or webclients/server) something really hangs for a while (in what ever form or place, so the developer it self or any debug clients, web or smart) please go to the admin page and dump the stack. Then we can quite easily see what it is doing at that time, To have a bit more info when it takes a bit longer is have a few dumps 5-10 seconds apart.


The attached file contains several memory dumps taken 15-20 seconds apart during one of the latest "freezes".
You do not have the required permissions to view the files attached to this post.
Rossen Totev
Argos Software
rossent
 
Posts: 288
Joined: Wed Dec 31, 2008 2:03 pm

Re: Servoy 6.1

Postby jcompagner » Thu Jul 12, 2012 10:46 am

rossent wrote:
The attached file contains several memory dumps taken 15-20 seconds apart during one of the latest "freezes".


what i see there is that application.showForm() is called that results in a excecute of onRecordSelect()
and in both stack dumps (they are not memory dumps but stack dumps) it really still busy in that specific method
In the first output it is calling some method of servoy (java method) and after 15/20 seconds it is loading in RelatedFoundsets (or setting the load up, not doing an actual sql call yet)

So purely looking that these 2 dumps 15/20 seconds apart it is just doing a show/onrecordselect. And why that is so slow i don't know you have to analyse your onrecord select for that.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 7978
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.1

Postby david » Mon Jul 16, 2012 3:03 am

Another issue I'd love to get some votes on: https://support.servoy.com/browse/SVY-2678
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby jcompagner » Mon Jul 16, 2012 2:07 pm

david wrote:Another issue I'd love to get some votes on: https://support.servoy.com/browse/SVY-2678


this will not be fixed very quickly
We need to do this, because when you do recreate ui we need to have a full new CSS file applied to the current form. (because you can have changed any kind of property for any kind of ui element)
So we need to get rid of the current css file completely, and unloading a css is quite tricky i think in a browser.
thats why we do a full reload so that everything is nice and clean.
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 7978
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.1

Postby david » Mon Jul 16, 2012 4:55 pm

jcompagner wrote:
david wrote:Another issue I'd love to get some votes on: https://support.servoy.com/browse/SVY-2678


this will not be fixed very quickly
We need to do this, because when you do recreate ui we need to have a full new CSS file applied to the current form. (because you can have changed any kind of property for any kind of ui element)
So we need to get rid of the current css file completely, and unloading a css is quite tricky i think in a browser.
thats why we do a full reload so that everything is nice and clean.


Can't you just tag on a random string to the end of the css file name to force reload of the style sheet when recreateUI() is called?

Code: Select all
http://url:8080/servoy-webclient/formcss/moduleName/formName_t1342416223947t.css becomes
http://url:8080/servoy-webclient/formcss/moduleName/formName_t1342416223947t.css?v=randomStRiNG


Seems to be what everyone else has been doing for a few years now.

Full browser refresh for a single page AJAX web app?! That's crazy talk.
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby jcompagner » Mon Jul 16, 2012 5:28 pm

That is ofcourse already in place...
Else a browser refresh wouldn't help either.. Because then the browser would cache the css anyway
What do you think that "_t1342416223947t" is?

the problem is that just having a new css, but with the same content (same element id's and so on) will not help because then that new css is just loaded and appended behind the rest (and we hit the Internet Explorer 30 css limit even sooner)
but if the new css has the same selectors as the old on, nothing will change because the browser will just see the old one.
So i guess then every element must have a new unique id, but it could be that we kind of support that now in 6.1, so that could help. But there are just a few issues to solve here
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 7978
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.1

Postby david » Mon Jul 16, 2012 5:49 pm

jcompagner wrote:That is ofcourse already in place...
Else a browser refresh wouldn't help either.. Because then the browser would cache the css anyway
What do you think that "_t1342416223947t" is?

the problem is that just having a new css, but with the same content (same element id's and so on) will not help because then that new css is just loaded and appended behind the rest (and we hit the Internet Explorer 30 css limit even sooner)
but if the new css has the same selectors as the old on, nothing will change because the browser will just see the old one.
So i guess then every element must have a new unique id, but it could be that we kind of support that now in 6.1, so that could help. But there are just a few issues to solve here


I think changing the css file name and changing the get parameter of a css file name is not the same thing.
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby mattfrizzell » Mon Jul 16, 2012 7:42 pm

David, After a great number of "hallway sessions" at Servoy World this past year I think the issue of refreshing an entire page in the web client is part of a larger discussion that needs to take place between the community and the devs. There were a lot of ideas on how to get around this behavior, but I think we all are looking for a way to perform actions in the web client without a round trip and a full reload through the use of native Servoy functionality (I know I am). If this a separate thread someone tell me where to put it (watch yourselves!) and we can start sharing ideas on how to make our lives in web client perform as a web page should.
Matt Frizzell
adBlocks
www.adblocks.com
mattfrizzell
 
Posts: 51
Joined: Mon Aug 21, 2006 4:00 pm

Re: Servoy 6.1

Postby david » Mon Jul 16, 2012 7:56 pm

david wrote:I think changing the css file name and changing the get parameter of a css file name is not the same thing.


Now that I have a sec, additional clarification:

Changing the css file name has all the issues you brought up. However, as I understand it changing the get parameter forces the browser to think the css file name has changed so it goes to the server for the "new" css file and reloads the css file with the same name as the file name really hasn't changed.

When web client starts up for the first time, Servoy creates all of the css files with new "_t1342416223947t" in the names, I get that. This works great for clearing out CSS caching between solution updates. However, you don't change the name of the css files on the server when recreateUI() is called -- you change the URL which forces a reload of any new css that has been changed in the css files already created on the server because you're on a new page.

What I'm suggesting is tacking on a random get parameter every time recreateUI() and keep the same URL. These get parameters exist only for that user and session in the client-side code that you output. No page refresh and the browser reloads the "same" css files.
Last edited by david on Mon Jul 16, 2012 8:24 pm, edited 1 time in total.
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby david » Mon Jul 16, 2012 8:19 pm

mattfrizzell wrote:David, After a great number of "hallway sessions" at Servoy World this past year I think the issue of refreshing an entire page in the web client is part of a larger discussion that needs to take place between the community and the devs. There were a lot of ideas on how to get around this behavior, but I think we all are looking for a way to perform actions in the web client without a round trip and a full reload through the use of native Servoy functionality (I know I am). If this a separate thread someone tell me where to put it (watch yourselves!) and we can start sharing ideas on how to make our lives in web client perform as a web page should.


I was waiting to get through fixable stuff in 6.1 before unloading with some major feature requests along these lines. Like being able to define a method server-side and run it by name/reference client-side instead of having to send a string of javascript through via the WebClientUtils plugin. And getting the client-side results directly back to the server-side calling method before moving on.

That's just a start. Ability to flag code to cache client-side instead of ajaxing every time, figuring out ways to combine and compress and CDN resources that don't change often, etc. So be very happen to join the hallway discussions :)
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby jcompagner » Tue Jul 17, 2012 12:25 am

david wrote:Changing the css file name has all the issues you brought up. However, as I understand it changing the get parameter forces the browser to think the css file name has changed so it goes to the server for the "new" css file and reloads the css file with the same name as the file name really hasn't changed.

When web client starts up for the first time, Servoy creates all of the css files with new "_t1342416223947t" in the names, I get that. This works great for clearing out CSS caching between solution updates. However, you don't change the name of the css files on the server when recreateUI() is called -- you change the URL which forces a reload of any new css that has been changed in the css files already created on the server because you're on a new page.

What I'm suggesting is tacking on a random get parameter every time recreateUI() and keep the same URL. These get parameters exist only for that user and session in the client-side code that you output. No page refresh and the browser reloads the "same" css files.


Please david, instead of making all these statements, just test for once your statements..
recreateUI will create a new url to your css, giving it a random uuid to the get method will bring nothing new to your output.
just make simple form with a simple method that only does 1 thing: controller.recreateUI()
and make a copy of the css link first and then compare it with the second

../servoy-webclient/formcss/string_to_uuid_issue/main_form_t1342477003659t.css
../servoy-webclient/formcss/string_to_uuid_issue/main_form_t1342477038475t.css

hmmm different time!!

Problem is that the content of the css file (when you just do controller.recreateUI()) doesn't change, at least not in the developer instance
It still has the same element/cssid and that is a big problem, we need to recreate completely new cssid over all the elements and the css so that really everything is new..
This could be done by also has a side effect that it will eventually blow up the browser

So what we need to do is really unloading that specific css and then reloading it.. So something for that must be investigated how to do that nicely and crossbrowser
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 7978
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.1

Postby david » Tue Jul 17, 2012 1:37 am

I've been testing my *ss off :) But I stand corrected, the file name change was only a few numbers and I didn't notice.

I still don't understand why changing a meaningless parameter at the end of css file names instead of renaming the file names and changing the url wouldn't solve the issue.
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

Re: Servoy 6.1

Postby jcompagner » Tue Jul 17, 2012 2:53 pm

you seem to think when you do this:

<html>
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css?x=1" />
<link rel="stylesheet" type="text/css" href="mystyle.css?x=2" />
</head>

the browser is really loading in one of that file. But for the browser it are just 2 files, both css files are applied (and in this case if it is purely static it is the same)
But both are loaded.

So to really have this working you have to really delete the link node from the dom or set the href property of the right node to zero (or maybe update it to a new one)
But this is quite change in a specific behavior that we have to implement then
Johan Compagner
Servoy
User avatar
jcompagner
 
Posts: 7978
Joined: Tue May 27, 2003 7:26 pm
Location: The Internet

Re: Servoy 6.1

Postby david » Tue Jul 17, 2012 6:19 pm

jcompagner wrote:you seem to think when you do this:

<html>
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css?x=1" />
<link rel="stylesheet" type="text/css" href="mystyle.css?x=2" />
</head>

the browser is really loading in one of that file. But for the browser it are just 2 files, both css files are applied (and in this case if it is purely static it is the same)
But both are loaded.

So to really have this working you have to really delete the link node from the dom or set the href property of the right node to zero (or maybe update it to a new one)
But this is quite change in a specific behavior that we have to implement then


Well yes, you do need to replace old link with new link -- this is how everyone does this technique. How is this a major change? You control all the code that is getting generated (and you're replacing that style sheet link already but with a different name), for recreateUI() do it this way instead of your current way (which I assume you'd still use when you first show forms). From a coders perspective, recreateUI() hasn't changed functionality (except that it doesn't refresh the page, just re-renders that form). "So i guess then every element must have a new unique id" is a major change.

The reason we've finally moved to web client with 6.1 is that this is the first version that allows the developer a good amount of control over the web code that Servoy generates. Which is always the danger when relying on other tools to generate code for you -- what happens when you reach the limits of what the tool generates?

Through the RC period you guys have fixed a bunch of stuff for us and in other situations we've created our own workarounds. Solution Model isn't something we can fix with some client-side tricks. Well, we can sort of: we just went back to code from Servoy 3 days that renders our main navigation pane with html instead of our slick Solution Model navigation pane that we replaced our hand built html with in Servoy 5. This is not progress.

Solution Model is an iconic Servoy feature and is the one tool we have to make up for Servoy's relative lack of advanced UI widgets. Not trying to start a holy war or anything here -- trying to think of a solution. We love and rely on Solution Model so much that this behavior seriously gimps what we're able to accomplish with Servoy.
David Workman, Kabootit

Image
Everything you need to build great apps with Servoy
User avatar
david
 
Posts: 1724
Joined: Thu Apr 24, 2003 4:18 pm
Location: Washington, D.C.

PreviousNext

Return to Announcements

Who is online

Users browsing this forum: No registered users and 1 guest

cron