Public Content for Web Services

[Neil Pate]

Hi All,

 

Can anybody shed some light on some strange behaviour I am seeing when deploying an executable with Web Services and Public Content.

 

I have an HTML page that gets served up as part of my application. My LabVIEW application interacts with a browser via Web Services.

 

Everything runs (mostly) fine, I can browse to localhost/ws/index.html and I get my web page.

 

However, I would have expected that HTML (and JavaScript etc) would remain on disk in source form so I could edit it after the LabVIEW application has been built, but this does not appear to be the case. Changes I make to the source do not get reflected until I rebuild my LabVIEW application.

Does the Public Content in the Web Service get packaged into either the .exe or the .lvws up as part of the build process?

 

I am really perplexed by this. I have tried all the obvious things like clearing browser caches etc. I even tried using a brand spanking new browser that had never been installed on my PC and I got the same symptoms.

[Neil Pate]

OK, confirmed this is what is happening.

 

The .lvws is actually just a zip containing the Public (and I suppose Private if I had any in my project) Resources as well as the Web Service VIs packed into an LLB.

 

 

[Deep_Blue]

Hi Neil,

 

google brought me here as I bumped to this feature, and I too expected being able to change the behavior just by updating the source HTML.

I do know it is possible, but haven't found the way just yet.

Did you find any good solution to what you were doing?

[Neil Pate]

Hi Neil,

 

google brought me here as I bumped to this feature, and I too expected being able to change the behavior just by updating the source HTML.

I do know it is possible, but haven't found the way just yet.

Did you find any good solution to what you were doing?

 

I don't think it is possible to just change the source.

 

However, as the .lvws is just an zip I was able to create a quick and dirty application (source and build attached) that can be run after any changes have been made to the source files and re-create the .lvws file. I ended up not using the LV web service to host the web pages, so did not use this application it in the end, but I believe it works but don't blame me if your PC bursts into flames.

Web Service Resource Combiner.zip

[smithd]

Another neat option depending on the platform (ok everything except vxworks and pharlap) is to use a traditional web service (apache, etc) to host public content and proxy requests to a given url pattern (like /myLVApp/*) over to the LabVIEW web service. That way static http pages are served up in the normal way by a standard, generally pretty fast web server and anything you need to run code for can still be handled by your labview service.

I kind of vaguely describe this over here: https://lavag.org/topic/19260-dynamic-content-in-other-web-servers/

I'm sure Neil's way works well but if this option sounds interesting to you I can probably help out a bit or at least get you going in the right direction.

[Neil Pate]

Another neat option depending on the platform (ok everything except vxworks and pharlap) is to use a traditional web service (apache, etc) to host public content and proxy requests to a given url pattern (like /myLVApp/*) over to the LabVIEW web service. That way static http pages are served up in the normal way by a standard, generally pretty fast web server and anything you need to run code for can still be handled by your labview service.

I kind of vaguely describe this over here: https://lavag.org/topic/19260-dynamic-content-in-other-web-servers/

I'm sure Neil's way works well but if this option sounds interesting to you I can probably help out a bit or at least get you going in the right direction.

 

I definitely do not recommend the way I demonstrated. It is a terrible developer experience and I only prototyped it to see if my hunch was correct...

 

Your method sounds much better