Recommended structure for web pages?

[Andrei Chichak]

Posted on November 26, 2014 at 00:24

This might be a question for Salvatore Capobianco, since his name is on the Dynamic Web Pages ap note. (no good turn goes unpunished)

The context of my questions is a smart device using an SPWF01S as a miniAP, bring up some web pages for configuration setting and status retrieval.Could you give me an idea of how you would recommend putting together a set of web pages to control a device from an SPWF01S? I am having some troubles getting my mind around the HTML page transitions that are built into input.cgi and output.cgi and I think I might need an example of how you would put together 3 or 4 pages using the existing code.Assume you had one landing page (index.html) that branched off into, say, two sub pages that would gather configuration information for the device hosted by the micro. For configuring a device, the pages would be preset with the parameters in the device, so all of the checkboxes and sliders are set according to device parameters. Each of the sub-pages would use #input or input.cgi to get input from the micro, but input.cgi seems to always return to a page called input_demo.shtml. For the system to be useful in a product, the pages should return some output to the micro over the serial port. To do this you use output.cgi. But when you use output.cgi, it always returns to output_demo.html.Does every sub-page that takes input need to be called input_demo.shtml, or is #input only the useful way to get input?Since each page that uses output.cgi returns to output_demo.html, did you architect this system so that I must use output_demo.html as my landing page, since that is where all the subpages will return to by their nature?Can you walk me through the steps you would use to go from the landing page to, say, config.html with some values from the micro, return some output through the serial port, bring up timing.html, get some input, return some output? Or even how you would put a password screen up so that I can provide some security?Or do I have a total of two pages, output_demo.html as a home page and input_demo.shtml to get my data, display it, and send it to the serial port? How would I predetermine the next page that the user might select and generate the new input_demo.shtml before they hit an unknowable button?I follow the examples in the ap note and the stuff that is stored in ROM, but has anybody actually built anything past input_demo and output_demo?Other questions:Why does the module insist on defaulting to firstset.html rather than the normal index.html? Should I just override firstset.html? Is there a configuration option so that I can set the default web page to index.html? If I was to give this to a customer, the first thing that they would do is call me to see what to fill in on firstset.html, and then brick the system.Would it be possible for you to define a couple of customer SSI tags like #custom1 and #custom2 so that I can create files like custom1.txt and custom2.txt and the SSI system would paste them into place? It's wonderful that you have a few SSI tags defined, they show us the potential of the module, but the content of those tags really isn't that useful outside of ST demo days.Is there more facilities built into input.cgi and output.cgi that aren't used in the demo code, like setting the next page to go to? It might be nice to be able to return to my own page to show the user that their data has been saved in FLASH, or that there is a problem with the micro and their settings weren't set.In the ''wifi Training - Hands On - FW3.3.pdf'' file, there is a mention of ''CGI&SSI Application Notes'' on page 120. Is it possible to get ahold of these ap notes? Perhaps they answer my questions.

[Nickname3786_O]

Posted on December 02, 2014 at 17:24

Below the answers to your questions. The only AN available is attached in a previous post. Nothing else at the moment.

Subject: Recommended structure for web pages?

This might be a question for Salvatore Capobianco, since his name is on the Dynamic Web Pages ap note. (no good turn goes unpunished, true but no risk no reward)

The context of my questions is a smart device using an SPWF01S as a miniAP, bring up some web pages for configuration setting and status retrieval.Could you give me an idea of how you would recommend putting together a set of web pages to control a device from an SPWF01S? I am having some troubles getting my mind around the HTML page transitions that are built into input.cgi and output.cgi and I think I might need an example of how you would put together 3 or 4 pages using the existing code.Assume you had one landing page (index.html) that branched off into, say, two sub pages that would gather configuration information for the device hosted by the micro. For configuring a device, the pages would be preset with the parameters in the device, so all of the checkboxes and sliders are set according to device parameters. Each of the sub-pages would use #input or input.cgi to get input from the micro, but input.cgi seems to always return to a page called input_demo.shtml. For the system to be useful in a product, the pages should return some output to the micro over the serial port. To do this you use output.cgi. But when you use output.cgi, it always returns to output_demo.html.Does every sub-page that takes input need to be called input_demo.shtml, or is #input only the useful way to get input?Since each page that uses output.cgi returns to output_demo.html, did you architect this system so that I must use output_demo.html as my landing page, since that is where all the subpages will return to by their nature?Can you walk me through the steps you would use to go from the landing page to, say, config.html with some values from the micro, return some output through the serial port, bring up timing.html, get some input, return some output? Or even how you would put a password screen up so that I can provide some security?Or do I have a total of two pages, output_demo.html as a home page and input_demo.shtml to get my data, display it, and send it to the serial port? How would I predetermine the next page that the user might select and generate the new input_demo.shtml before they hit an unknowable button?I follow the examples in the ap note and the stuff that is stored in ROM, but has anybody actually built anything past input_demo and output_demo?>>>>> As the name says, the input_demo and the output_demo are simple pages that take advantage of the CGIs and SSIs integrated in the code. When you call a CGI page or a SSI, you are running some steps defined in the code of the module (the input_demo returns the input_demo, the output_demo returns the output_demo, no way to change this behavior but you can bypass it using the Jquery, as shown in the APPENDIX).The input and output pages have been created for DEMO purpose.Other questions:Why does the module insist on defaulting to firstset.html rather than the normal index.html? Should I just override firstset.html? Is there a configuration option so that I can set the default web page to index.html? If I was to give this to a customer, the first thing that they would do is call me to see what to fill in on firstset.html, and then brick the system.>>>> Because the module can be remotely configured using the firstset, we decided to make available this page by default opening the ip_domain_name.To overwrite it, you can rename your index.html as firstset.html and upload it in the ext flash. The module will open your index.html renamed.Would it be possible for you to define a couple of customer SSI tags like #custom1 and #custom2 so that I can create files like custom1.txt and custom2.txt and the SSI system would paste them into place? It's wonderful that you have a few SSI tags defined, they show us the potential of the module, but the content of those tags really isn't that useful outside of ST demo days.>>> At the moment, it's not possible to create new CGI and SSI tags. The module doesn't integrate a CGI engine. Maybe using the CGIs&SSIs integrated in the module, you cannot perform all you application but at the moment we didn't plan to enhance this function.Your suggestion will be highly appreciated.