Jump to content

Public Content for Web Services


Recommended Posts

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.

Link to comment
  • 10 months later...

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

Link to comment

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.

Link to comment

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  :thumbup1:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.