Details
Description
After reviewing the calendar component's use of the various ice.s, ice.se, ice.ser bridge APIs, we've identified the following tweaks/improvements to the bridge functionality:
1. Add additional argument(s) to the ice.ser() function to enable configuring the phases that are executed. Components using this function will almost always need to customize the phases execution that occurs in the execute=this.
2. Have the ice.s(), ice.se(), and ice.ser() functions set a standard flag in the parameter map to indicate which submit type has occurred. Components will often need to know what type of submit triggered their execution. Alternatively, if this information can be derived already from some other server-sid estate, provide a convenience method that components can use.
1. Add additional argument(s) to the ice.ser() function to enable configuring the phases that are executed. Components using this function will almost always need to customize the phases execution that occurs in the execute=this.
2. Have the ice.s(), ice.se(), and ice.ser() functions set a standard flag in the parameter map to indicate which submit type has occurred. Components will often need to know what type of submit triggered their execution. Alternatively, if this information can be derived already from some other server-sid estate, provide a convenience method that components can use.
"1. Add additional argument(s) to the ice.ser() function to enable configuring the phases that are executed. Components using this function will almost always need to customize the phases execution that occurs in the execute=this. "
How exactly are defined the phases to be executed?! Is it by by configuring partial view processing with 'render' and 'execute' options (with values like @this, @all, @none or some ID) ?
If the answer to last question is yes, then really we don't need two types of single submit functions. We can then have only one parameterized single submit function.