Web parameters

[Richard]

Hi. Do you have a write up of the web parameter facility of your demo software, i.e., the part of the web server that deals with "£" embedded in the html pages it serves?
Thanks,
    Richard

[mark]

Hi Richard

There is no document expaining this but I do have the following which seems to have helped a number of users in the past - you should find that it is in fact quite easy and flexible enough to do most things with. The parser is in fact project specific and not a part of the stack so can be manipulated as much as you desire and require:


All interfacing between the Browser and the application takes place in the file webinterface.c. There are the following calls from the web server part (which doesn’t need to be understood in itself):

- fnIsSelected()   the web server asks the application whether a check box or other such field is to be displayed as active or not (eg. Whether a port input is high or low)

- fnHandleWeb()  the web server passes received parameters to the application (eg. A change of a setting such as a port output level)

- fnInsertString()  the web server asks the application to fill out text to be displayed on the web side (eg. Display a counter value, define a colour, size, etc.)

The rest is basically defined in the html files which can be loaded by ftp and modified as required (they are not compiled into the code as performed by most embedded suites and so can even be changed by users without means to compile the project (eg. To translate the web pages into other languages etc. or to personalise them for a specific customer).

An example: Look at the source to the file “0Menu.html” where you will see the following lines:

<form action=/0 name=r>
Email address <input maxLength=40 size=40 name=M value="£vE0" £Dm0><input type=submit value="Enter" name=r £Dm0></form>

"£vE0" informs the web server that this field is to be filled out by the application and so it will cause fnInsertString() to be called and the application returns in this case an email address to be displayed.

£Dm0 informs the web server that it must request the application as to whether the field should be displayed as enabled (can be changed and not grey) or disabled (can not be modified and is grey). This causes fnIsSelected() to be called so that the application can decide how it should be displayed.

name=M is a reference to the form which is sent when the user clicks on the “Enter” button (when enabled). This causes the web server to call fnHandleWeb() so that the data received (in this case a new email address) can be passed to the application.

By simply adding new references in the html and supporting them equivalently in the application it is very easy to built interactive and dynamic web browser interfaces.

If you use the simulator you can simply put a break point in these routines and see how it all interacts. Then it is simple to modify and test new parameters – simulate it to ensure it all works well and then compile with your cross-compilerand load to the target – it will then work without any debugging effort on the hardware…



Regards

Mark

[Richard]

Hi, Mark.

Thanks for your prior reply; it was a big help.

I am finally working on displaying data to a web page.  I have figured out the various levels of indirection that ultimately invoke fnInsertString(ptrBuffer, usTxLength, usLengthToSend).  As written, in fnInsertString(), the value of usTxLength is used only to see if it's zero or not, to decide whether the function was called as a result of £v or £H.

I have a situation where I have several identical objects of a couple of different types to monitor, with a couple of different kinds of values, so I'd like to have the HTML embed the ID of the object and its parameter following the £ that indicates a field to be replaced with data.  I understand that I could use £HXY for this, but I'd like to have additional possibilities, not just H.  I'd like to use £JXY to display the Y parameter of the object number X of type 1 and £KXY to display the Y parameter of the object number X of type 2, etc.

My suggestion is this: why not change usTxLength to usFieldCode, where the various field codes are
    v - for value (i.e., as currently used)
    H - for dynamic content (the current stub)
and then any other codes I care to insert that are not already used.

I could simply add

Code: [Select]


    #define WEB_INSERT_OBJECT1        'J'
    #define WEB_INSERT_OBJECT2        'K'
    // etc.
to config.h just after the definition of WEB_PARSER_START.

This collapses the two calls to fnInsertValue() that invoke fnInsertString() in fnWebParGenerator() to one, giving

Code: [Select]

unsigned short  usFieldCode; // character following £ identifies type of field, e.g., v for value
// ...
usFieldCode = (unsigned short)*ptrBuffer++;

switch (usFieldCode) {     // check which of our fields this is
  // ...
  case WEB_INSERT_STRING:  // to insert value string field
  case WEB_INSERT_DYNAMIC: // to insert dynamic HTML
  case WEB_INSERT_OBJECT1: // insert string for objects of type 1
  case WEB_INSERT_OBJECT2: // insert string for objects of type 2
  // etc.         
    if (fnInsertValue) {
        cInsertString = fnInsertValue(ptrBuffer, usFieldCode, &usInsertLength); // allow application to insert its own string
    }
    break;

and the test near the top of fnInsertString() is based on the code of the field, usFieldCode, rather than whether usTxLength is zero.

I've programmed this, and it appears to work.

What I don't know -- and this is the reason for this lengthy query -- is whether it's necessary to worry about the length of the resultant string.  I'd even be willing to guarantee that it remains shorter than MAX_SIMPLE_INSERT.  Specifically, will fnWebParGenerator() handle the possibility that the result will not fit in the space available in the current TCP frame?  I note that in the case of £vXY, this must already be the case.  Put another way, why was the value usTxLength passed in to the function fnInsertString() beyond acting as a flag for one of two behaviors?

Thanks,
    Richard

P.S. in the various places where the code returns cNoEntry, the length is set using *usLengthToSend = sizeof(cNoEntry) - 1;.  This has the effect of chopping off the final '-' from the message.

[mark]

Hi Richard

The value usTxLength is indeed 0 when strings are to be inserted. In this case the string is inserted into a local buffer (the size that the buffer actually requires is determined by the user) and if the string doesn't actually fit in the present TCP frame it will be repeated later. The routine fnInsertHTMLString() handles this. This routine has the job of actually inserting the string into the output buffer, which means either making space for it or, in some situations, closing the hole left by a very short string. It also decides whether there is actually space for it in the present frame. So, the fnInsertString() code doesn't have to worry about these details.

In the case of inserting dynamic HTML the value of usTxLength informs of the space available in the TCP frame so that the user routine knows how much it may insert and when to stop. Presently there is in fact no dynamic HTML example in the project (see the following for a short discussion of this:
http://www.utasker.com/forum/index.php?topic=97.0 )

But an example would be when a web side should display a table of results, where the length of the table is not fixed but instead depends on the available data (which could vary from 0...max). In this case WEB_INSERT_DYNAMIC is foreseen. The code can generate lines of HTML table code - as many lines that fit in each TCP buffer - until the table has completed. In this case it is necessary to have the value usTxLength . This could be considered to be a simple php like function.

If no WEB_INSERT_DYNAMIC support is required, the value can be used as you have suggested, but I think that it is best instead to extend the use of the $v as discussed in the following (towards bottom of thread):
http://www.utasker.com/forum/index.php?topic=89.0


static const CHAR cNoEntry[] = {'-', ' ', '-', ' ', '-'};
*usLengthToSend = sizeof(cNoEntry) - 1;
Yes, you are right. I suspect that it was once declared as a string, where the -1 would have been needed. I will remove the  -1 in the development version.

Regards

Mark