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):
jcompagner:
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”.
server_dump.txt (54 KB)
rossent:
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.
Another issue I’d love to get some votes on: https://support.servoy.com/browse/SVY-2678
david:
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.
jcompagner:
david:
Another issue I’d love to get some votes on: https://support.servoy.com/browse/SVY-2678this 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?
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.
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
jcompagner:
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, 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.
david:
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.
mattfrizzell:
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:
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
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.
you seem to think when you do this:
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
jcompagner:
you seem to think when you do this: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.
jcompagner:
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
Tested the following code snippets with Chrome developer tools:
// store style sheet link
var x = $('link[rel=stylesheet][href*="CRM2_0F_companies_0_"]')[0]
// remove style sheet from the dom
$('link[rel=stylesheet][href*="CRM2_0F_companies_0_"]').remove()
// add style sheet back to the dom
$('head').append(x)
// define link for slightly modified css style sheet
var y = '<link rel="stylesheet" type="text/css" href="http://localhost:8080/testing/style_test.css">'
// add modified style sheet to the dom
$('head').append(y)
Works pretty slick – no page flicker, instantaneous style application, no complete blanking out the window. Depending on how much dom manipulation is going on when recreateUI() is called, I would expect recreateUI() to be about as fast and smooth as changing records on the one hand (very little browser re-render happening) to changing tab panels on the other (quite a bit of browser re-render happening).
Another case to vote for please! Anchoring in web client produces a ton of synchronous UI blocking ajax calls. Biggest web client UI performance issue we’ve found so far – see video attached to the case:
https://support.servoy.com/browse/SVY-2748
As no results are returned from these calls, I don’t think that a particular call is dependent on the previous one’s information. Seems possible then to fire one ajax event to send the anchoring information for all the objects instead of each object sending its information to the server.
Rename of media items in media subfolders seems not to be functioning ?
kvanacker:
Rename of media items in media subfolders seems not to be functioning ?
Indeed, there is already a case for it:
SVY-2638
Renaming media inside a media folder does not work
Will be fixed in 6.1.1 .
We like a lot the option to mark specific tables as metadata tables and to be able to include system data in the deployment.
Can this be extended a bit further and expose the data serialization to/from xxxxx.data file as methods? For example something like:
databaseManager.exportFoundsetDataToFile(foundset, fileName);
databaseManager.importFoundsetDataFromFile(foundset, fileName);