Ticket #12 (closed enhancement: fixed)

Opened 10 months ago

Last modified 9 months ago

Implement action based selection of IWrappers on submit (deprecate SELWRP)

Reported by: JensLautenbacher Assigned to: martin.leidig@1und1.de
Priority: major Milestone: 0.13.0
Component: Core (general) Version:
Keywords: Cc:

Description (Last modified by JensLautenbacher)

We want to get rid of all the SELWRP stuff in the UI, instead use a single "action" attribute for pfx:button / <pfx:xinp type="submit|image">. This attribute references a group of wrappers in the configuration.

We need to change the pagerequest configuration for this. If the old form is used, the SELWRP will still work, but it will not be allowed for new style configuration (hope this is possible at all...)

<pagerequest name="...">
  <input>
    <wrapper prefix="..." class="..." activeignore="true|false"/>
    ...
    </input>
  <processing>
    <action name="...">
      <inout>
        <wrapper ref="a_prefix_1"/>
        ...
      </inout>
      <out>
         <wrapper ref="a_prefix_2"/>
         ...
      </out>
  [   <in>
         <wrapper ref="a_prefix_3"/>
         ... 
      </in>   ] <- do we need this???
    </action>
  </processing>
  <output>
    <resource node="..." class="..."/>
    ...
  </output>
</pagerequest>

<inout> are all the wrappers that are used for submitted data, and which will be used in retrieveCurrentStatus() after successful handling of the data.

<out> are all wrappers who don't get to handle data, but who are called in retrieveCurrentStatus() if the whole submit has been handled sucessfully NOTE: this is the new way to achieve that. The old configuration had a alwaysretrieve attribute on the "<input>/<interface>" node (now called "<input>/<wrapper>").

<in> would be wrappers who handle input, but who are not called in retrieveCurrentStatus() after a successful submit. We need to know if this is needed at all...

An alternative configuration format might look like this:

  <processing>
    <action name="">
      <wrapper ref="a_prefix_1" mode="submit"/>
      <wrapper ref="a_prefix_2" mode="retrieve"/>
      <wrapper ref="a_prefix_3" mode="submit-retrieve"/>
      <wrapper ref="a_prefix_4"/>
      <!-- mode attribute could default to either submit or
           submit-retrieve -->
    </action>
  </processing>

RESOLUTION: finally I settled for the form with two lists, one for submit and one for retrieve (see #23 and #27 for the background)

  <process>
    <action name="A_Name" MORE_ATTRIBUTES>
      <submit>
        <wrapper ref="a_prefix"/>
        <wrapper ref="..."/>
        ...
      </submit>
      <retrieve>
        <wrapper ref="a_prefix"/>
        ...
      </retrieve>
    <action>
  </process>

MORE_ATTRIBUTES stands for additional attributes that will have to be implemented for pageflow, jumptopage, jumptopageflow, forcestop selection based on actions. See #31 for this.

Change History

03/28/08 01:36:26 changed by JensLautenbacher

See #23 for more info on the "manual" fallback solution with SERWRP and RETRWRP

03/28/08 16:36:53 changed by JensLautenbacher

  • description changed.

By the way: current thinking goes along the line that <in> nodes are completely useless. Feel free to add a usecase, if you find one :-)

04/03/08 21:46:35 changed by JensLautenbacher

  • description changed.

..or not: I implemented the matching manual command for <in> nodes already - see #23, also for an explanation of the usefulness. So we'll also implement the <in> part of the action stuff.

04/04/08 08:31:26 changed by SebastianMarsching

  • description changed.

I think we should change the tag names: While <in> might be okay (although I think <input> might be better), <out> is a bad choice as wrappers are not designed for output, but input. Instead, the tag name should reflect what retrieveCurrentStatus(...) really does. Therefore something like <fill> <fill-form> or <autofill> might suite better.

04/04/08 08:41:37 changed by JensLautenbacher

  • description changed.

input is already used - all of the wrappers are below <input>, and the actions are under <processing> so it somehow reflects the fact that what we are talking here is about the input processing forms

What I would like to see are names that reflect that there are two different actions combined in different ways, and these are handleSubmittedData() [HSD] and retrieveCurrentStatus() [RCS]

  1. Call [HSD] && [RCS]
  2. only call [RCS]
  3. only call [HSD]

using the words "in" "out" and "inout" combines this nicely. But I am of course open for other words here, just try to make it like "foo", "bar" and "foobar"

04/04/08 08:44:21 changed by JensLautenbacher

the long form of course could be

<submitandretrieve> <submit> <retrieve>

but this is very long for the most common case compared to <inout>. Also because of the familiarity of the word submit, it may lead to the impression that submit does in fact what submitandretrieve does.

04/04/08 14:27:40 changed by SebastianMarsching

  • description changed.

In most cases the "submit" action will be sufficient. Only if the handler changes some data (e.g. normalization of addresses) retrieve after the submit is needed. Therefore we should think about making "submit only" the default.

Either way the alternative configuration scheme proposed in the description of this ticket might be cleaner and even shorter than the original draft.

Besides the <action>-tag should be extended with other commands that are triggered by attributes on the <pfx:xinp> submit button (jumptopage, jumptopageflow, pageflow and forcestop) at the moment.

04/04/08 19:28:51 changed by JensLautenbacher

I opened #27 for a decision if we really can drop the retrieveCurrentStatus() call after handleSubmittedData() by default. If yes, we would go with only two "modes" or two subtags.

04/09/08 16:17:29 changed by JensLautenbacher

  • description changed.

04/09/08 16:18:16 changed by JensLautenbacher

  • description changed.

04/09/08 16:19:30 changed by JensLautenbacher

  • status changed from new to closed.
  • resolution set to fixed.
  • description changed.

04/09/08 16:23:01 changed by JensLautenbacher

  • description changed.