Updating webapp & clearing cache

Targets Web
1

I tried searching this forum to see if anyone had experience with this. If there is a post explaining this please point me in the right direction.

So I updated a webapp and all I added from previous was a “Webradio Group.” In order to run the app without error is to clear the cache. Is there a way around this so users wouldn’t have to clear their cache? Am I doing something wrong?

Here’s the error I get…

Could not execute returned javascript: radiogroup is not defined Source: new frameworkObject('PLWwhtOY',[]); Xojo.controls['PLWwhtOY'].setEnabled(true);

2

Well if you look at the source they have solved this problem with CSS. They use your Session.Identifier as the CSS name. However they still use /framework/framework.js for each session. So when the page reloads its assumes that file is the same. They should change /framework/framework.js to /framework/Session.Identifier.js.

In regards to how to fix it… My first thought is to configure the web server to ask the browser not to cache it.

3

So you can see what is happening by creating a web project, drop some controls on a page BUT NOT a radio group. Run the project and view source. Scroll all the way to the bottom. Note it ends with some functions related to one of your controls. Now add a radio group and do it again. You will see radio group functions show up.

However your browser does not know they were added so it assumes they weren’t.

4

So does anyone have a solution for this…??

It’s going to be really hard to tell users to clear their cache everytime an upgraded web app is deployed…

5

I am looking into server side options. The easiest way to fix this right now is to add the UI elements to your page you aren’t using yet. Just put them off screen or invisible somewhere. This will force the compiler to output all the necessary javascript the first time.

6

Good idea, thanks Phillip

7

One reason I like that over asking the browser not to cache via server is you really want to cache all that JS.

8

True, but if I’m going from Version 1.0 to Version 2.0 of a webapp, there could be alot of controls added to an existing page thus causing this problem. I’m assuming that would happen to pages that are created new right??

9

Sign on to <https://xojo.com/issue/29362>

10

I don’t believe so. The javascript that is referenced is not on a per-page basis. So as long as the controls exist somewhere in your project the compiler should output them.

11

Ok yes. You can add a page you never use and just dump all the controls on it. Then the javascript will be set up properly.

12

@Phillip Zedalis
Just FYI, your case will get more attention if you file it under Framework->Web instead of Compiler.

13

[quote=32038:@Greg Olone]@Phillip Zedalis
Just FYI, your case will get more attention if you file it under Framework->Web instead of Compiler.[/quote]

Thats cool. Since it’s closed. Is there some mechanism to update apps that doesn’t have this problem we aren’t aware?

14

Greg -

I must be missing something here. I have run into this issues several times, and I am glad I finally understand what it causing it.

In my opinion, the workarounds are completely unacceptable. Changing the CGI path means the users need to change their bookmarks - doesn’t it? Loading up all the controls before you know you need them - to me that sounds ludicrous.

Can you please help me understand why the response is nothing more than a terse: will not implement. That just doesn’t sound customer friendly to me.

Thanks.

15

It’s not. Did you read the message that I filed?

This case has been closed because it has been decided that this feature will not be implemented.
See case #29288

The problem with Philip’s request is that the framework would be downloaded every time the browser asks for it, regardless of whether or not it had changed. As the web framework grows, that will be hugely inefficient.

The reason that your users are having trouble is that their browser isn’t even asking if the file changed. That’s what was fixed in <https://xojo.com/issue/29288>

17

Excellent - thank you, and pardon my misunderstanding.

18

Yeah I agree its inefficient. I guess I don’t understand how much data is saved by not appending all the controls from the get-go.

Anyway thanks.

19

We DO append all of the controls that were used in the project. But even if we included all of the controls that exist, that would only work until we introduced a new control. We’ve got a solution that we believe should work.