Skip to Content

Things that may seem rather obvious to experienced users/developers, may be rather less obvious to the less experienced amongst us in the SAP Developers Network community. One reason could be a lack of information. It’s a fact that (online) bookshops have loads of books on Java, for example, but not many are available on Web AS. Of course there is always the F1 key on your keyboard and to consult as a first resort, but here one needs to know what to look for in the first place. Sometimes help is limited to a syntax description, and good examples or best practices aren’t always provided. The SAP Developers Network with its sharing of information and experience is very handy in this case. But this community is constantly growing (the Web Application Server has > 1000 posts in a week) and information is widely scattered some times. This series tries to concentrate information in small, quick win code samples. Some topics have already been touched on in spread forum posts, some haven’t.

My first example deals with the request->get_form_field(s) method. This method lets you retrieve HTM form fields in name/value pairs. It seems a bit like going back to the olden days where one needed to investigate the HTTP header in order to know how to fill in a form. Working with page attributes for example, is indeed the more advanced and best method in most cases. But there are some circumstances where page attributes aren’t needed and the request->get_form_field(s) method is nice and handy. A search on SDN gives you some sample uses. Most people are using it as a kind of debugging tool in order to see how a field is filled

DATA: somevalue type string.
somevalue = server->request->get_form_field('somefield').

Craig Cmehil used it to devise this nifty way to redirect a page. Check this forum thread for details.

We use the request->get_form_field method for large lists which need to be processed in a fast and easy way. There are situations where the (unknown) amount of data prevents the use of page attributes. Let’s take an online bookshop as an example. We want to provide a search function where the user can select multiple books for processing (comparing/viewing details, ordering, etc.) in bulk. Whatever we show, we are only interested in the ISBN numbers of the selected books. That’s easily done.

DATA: table_fields type TIHTTPNVP,
wa_fields type IHTTPNVP.
* clear our previous selections.
clear application->WEB_TAB_ISBN.
clear application->WEB_TAB_ISBN[].
* retrieve the form fields
call method request->get_form_fields
fields = table_fields.
* and put them in our table
loop at table_fields into wa_fields.
        case wa_fields-name.
                when 'isbn'.
                     append wa_fields-value to application-> WEB_TAB_ISBN.

After this you can supply this table to a/multiple FM, store it in a server cookie, …

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

    1. Former Member
      If it has to be quick, let us cut a few lines of code ๐Ÿ™‚ By using the where condition, you don’t need the case statement. Probably in the end the same, but here the message is clear: find all isbn fields. With the case statement, I always wonder what other when blocks are missing.

      loop at itab into wa where name = ‘isbn’.
        append wa_fields-value to WEB_TAB_ISBN.

      1. Eddy De Clercq Post author
        You’re right. It was inteded for possible extra fields (a habit of mine, writing code for future possible extensions). But it this example, it’s indeed rather useless.

Leave a Reply