There may be some good reasons why the request parameter map received directly from the client does not match the Map expected by the rest of RSF. The normalizeRequestMap member of the RenderSystem interface gives the dialect-specific portion of the code a chance to process this map before RSF actions begin.

Currently the only "good reason" known of relates to form submission controls. Since the <button> control is permanently broken by decree of Microsoft (even recent IE versions do not agree to encode the name of the actual control used for a submission), the RSF BasicHTMLRenderSystem must use the name of the submission control to encode all EL and component binding information, and what is more the Action name to be triggered by the control. This is packed into a long string consisting of a stretch of URL attribute stanzas separated by & and =.

The BasicHtmlRenderSystem unpacks such encoded information and returns it into the supplied writeable Map, sot it may appear as if it had been submitted normally. The main benefit of this approach is to allow RSF applications to function correctly in non-Javascript enabled clients.