• No se han encontrado resultados

Análisis de las categorías de opciones entre Perspectivas

L PLP

11.3 Análisis de las categorías de opciones entre Perspectivas

This chapter discusses some of the more complex, yet common aspects that a programmer might encounter when developing WBM code. It is advised that you first read the

comprehensive example in Chapter 5 before proceeding to issues raised in this section.

10.1 Links

Suppose that you want the user to be redirected to a device properties page when he clicks on the device name link. You should use the p_link_mimic_button() function:

void p_scr_conn_list(html_t **handle) {

...

link = p_link_mimic_button(cell, g_btn_edit, dev->name, NULL);

p_text(link, "

...

}

This function mimics a button. When the link is pressed, the page scan function is

automatically called, as if a virtual button (g_btn_edit in this case) was pressed. Note that this function does not write the text that appears on the link - it can be thought of as just a place holder for the text, that sets the properties of the link.

The next line (p_text()) is the actual setting of the text. The scan function should intercept a click on the button using button_num():

void s_scr_conn_list(void) {

int btn = button_num();

...

if (btn == g_btn_edit) {

/* Redirect to device properties page */

active_page_set(PAGE_CONN_BASIC);

} ...

}

10.2 On-change Events

Section 28.3 mentions the btn_onchange button. There are some objects in certain pages that changing their state causes re-submission of the form, due to an event-driven Javascript code invoked on the browser, and that such a re-submission event is equivalent to clicking btn_onchange.

Such events allow displaying more accurate information for the user. Suppose that there is a drop-down menu for manipulating Remote System Notify Level (syslog). If the selection is one of "Error", "Warning" or "Information", the user will need to input an IP address (Remote System Host IP).

Figure 10.1 System Logging

However, if the user selects "None" in remote syslog level field, the IP address field must disappear.

Figure 10.2 System Logging

If you want the appearance and disappearance of the IP address to be executed without the user having to click the "OK" button, but only changing the value in the drop-down menu, do the following:

void p_remote_log_section(html_t **handle) {

...

p_combo_box_list(cell,

combo_info_create(sym_notify_level, 1), set_get_path_int(tmp, Sseverity_threshold), notify_level_list);

if (int_entry_get(sym_notify_level) != LLEVEL_MASK) {

p_edit_ip_addr(cell, sym_ip, inet_addr(ip));

...

} }

Line 5 Change the onchange_activated argument from 0 to 1 when creating the drop-down menu (combo_info_create() call) in the page print function.

Line 8 In the page print function, put the IP address field under a condition (so it will be printed only if the remote syslog level is not "None").

Line 10 Notify level is other than "None", so print the IP address field.

10.3 Passing Parameters Between Scan and Print Functions

Sometimes the WBM programmer needs to convey data from within a scan function to a print function or vice versa.

From scan to print Use the attrib_t *param argument of the p_page(). This argument will reside in g_request->param for accessing it from the print function. The attrib_t data structure allows passing multiple attribute-value pairs. If the passed parameter is allocated dynamically in the scan function, the scan function is responsible for freeing its allocation.

This can be done safely after the call to p_page().

From print to scan This direction is more complex. Use hidden parameters. A hidden parameter is a hidden HTML field that is sent to the browser. When the user submits the form on the browser, all the hidden parameters are automatically posted to OpenRG.

Suppose you are adding two pages. In the first page, the user should select a device from a drop-down menu of devices. In the next page the user should select a description for the selected device. After submitting the form with the new device description, the system is expected to store the device description in rg_conf. The scan function that must do this task should know the device to which the description must be written.

Figure 10.3 Passing Parameters Between Scan and Print Functions

As you can see in Figure 10.3, you need to convey information from (2) to (4). This is done in two steps—first you need to convey information from (2) to (3), and then from (3) to (4).

The first step is easy—the scan function directly calls the print function (recall that every scan function ends with a call to p_page()). For the second step you need to hide the device identifier in the page that you send to the browser. When the user submits the the device description, this piece of information is posted to OpenRG and scanned (4).

(1)

void p_scr_device_dropdown(html_t **handle) {

...

}

(2)

#define PARAM_DEV_NAME "param_dev_name"

void s_scr_device_dropdown(void) {

char *dev_name;

attrib_t *a = NULL, **attrib = &a;

extract_data_t extract[] = {

{SYM_DEVICE_DROPDOWN, {str:&dev_name}, TYPE_COMBO_BOX_STR, ""}, {NULL}

};

/* Extract the drop-down menu selection */

extract_data(extract);

/* Set the next page */

active_page_set(page_device_description);

/* Pass the device identifier (dev_name) as an argument to the next page */

attrib_set(attrib, PARAM_DEV_NAME, dev_name);

p_page(a);

attrib_free(&a);

}

attrib_t **attrib = &g_request->param;

frame = p_page_header(handle, ...);

if (g_request->param)

dev_name = attrib_get(attrib, PARAM_DEV_NAME);

else

dev_name = entry_get(SYM_HIDDEN_DEV_NAME);

/* Save the device identifier (dev_name) in the page for two reasons:

* - s_scr_device_description() will know what device to manipulate * - If p_scr_device_description() is called after an error was * discovered in s_scr_device_description(), then 'param' is NULL, * so the hidden parameter is used as a backup

*/

p_hidden_param(frame, SYM_HIDDEN_DEV_NAME, dev_name);

...

}

(4)

void s_scr_device_description(void) {

char *dev_name, *description;

set_t *dev_set;

extract_data_t extract[] = { {SYM_DESCRIPTION, {str:&description},

TYPE_STR_WITH_SPACES|TYPE_OPTIONAL, Tname}, {NULL}

};

/* Extract description */

extract_data(extract);

if (g_request->errors) goto Exit;

/* Retrieve the device identifier (dev_name) from the posted data */

dev_name = entry_get(SYM_HIDDEN_DEV_NAME);

/* Get the device set_t ** struct given its name */

dev_set = dev_if_set(dev_if_get(dev_name));

/* Write device description to rg_conf */

set_set_path_str(dev_set, Sdescription, description);

openrg_reconf(FLASH_DELAYED_TOP_PRIORITY);

/* Return to the "parent" page */

active_page_set(navigator_pop());

Exit:

p_page(NULL);

}

A print function that receives a parameter should save its value as a hidden parameter, not only for the corresponding scan function usage, but also for its own usage, when 'param' is NULL.

When could this happen? If the validity checks in s_scr_device_description()

fail, this causes an error page to be displayed. When the user returns from the error page to p_scr_device_description(), the error page has no knowledge of the value that is needed to be passed to page p_scr_device_description(), so NULL is passed.