Event Filter: Add to storage

[designermonkey]

How awesome would that be?

[nilshoerrmann]

Would be kind of nice – but I have no idea how to create an event filter. Personally I think, that Symphony's event system is quite complicated and only half-backed.

How should the event data be added to the storage? Under an events namespace, like storage[events][my-event-name]?

[michael-e]

Maybe you are thinking too complicated.

You don't need the actual event data, do you? Why not create en event filter to simply add POST data (if available) to the storage?

[michael-e]

And why a filter? Coundn't that be an event? (Don't we already have this? I admit that I haven't tested it…)

[nilshoerrmann]

The good thing about using an event filter is that you'd know the data context (your event).
Of course you could recreate that from the POST data, but that seems to overcomplicate things.

But I see use cases for both, an event filter and a general POST to storage event.

[designermonkey]

Yeah, it would definitely need to be a filter, it would have to be added to another event as that is what we're after; Posting data from an event into the session.

I've done event filters before (stopforumspam) so could tackle this at some point soon.

How should the event data be added to the storage?

Yes, like:

storage[events][my-event-name]
storage[events][my-event-name][message]
storage[events][my-event-name][post-values]
storage[events][my-event-name][post-values][value-1]

etc

[designermonkey]

The more we can provide for this extension, the more it will be loved IMO. You two have already got the core of it working really well.

[nilshoerrmann]

Well, the most important thing is to keep this extension focussed.
One reason why it hasn't been announced or released publicly so far.

But I'm with you that a simple event filter would be a useful addition.

[nilshoerrmann]

Adding event data to the storage would be rather simple. Are there any information online how to create an event filter?

[michael-e]

Not that I am aware of. But you might use the ETM's event filter logic as a blueprint. It resides in the extension driver.

[nilshoerrmann]

I just created a filter branch that adds a filter that saves the event's field data in the storage, like so:

        <group id="events">
            <item id="contact">
                <item id="name">John Doe</item>
                <item id="mail">[email protected]</item>
            </item>
        </group>

The first item id matches the event name, the nested ones are the fields.
What do you think?

[michael-e]

Sorry, I am in a hurry. I can think about it tomorrow.

[designermonkey]

Aww, I really wanted to do that one! lol

You got it all done before I even got home!

When I discussed this on the Symphony tracker, I was aiming more at having the xml intact in the session and just reloaded into the page but with an attribute of redirected="true" or similar, but for the purposes of this extension, this is perfectly fine.

[nilshoerrmann]

I just pushed a few updates to the branch fixing bugs and adding a drop filter:
https://github.com/hananils/storage/blob/filter/extension.driver.php

[michael-e]

I am still testing this, but I have one or two questions.

1. Wouldn't it be better to use Storage: Add and Storage: Drop as event filter names? (You may have lots of event filters, and in this case the current names will be hard to find. I would always look for Storage in the alphabetical list.)

2. Why are you wrapping the data in an events group? This leads to a somehow inconsistent structure — look at the parameter:

   Params:
   
   <ds-m-storage.events>
       <item handle="save-message">save-message</item>
   </ds-m-storage.events>
   
   Data:
   
   <m-storage>
       <group id="events">
           <item id="save-message">
               <item id="name">Ted Tester</item>
               <item id="email">[email protected]</item>
               <item id="subject">Ein Test, es ist ein Test!</item>
               <item id="message">Lalala.</item>
           </item>
       </group>
   </m-storage>
   

[nilshoerrmann]

1. Yeah, that would be fine. I used the current naming scheme as this is the way Symphony names filters. But your proposal certainly works better, if your managing lots of filters.
2. I'm grouping by events to indicate where the data comes from and to make sure that I'm not polluting existing namespaces. So I'm creating one global namespace for events and not one per event. What's the inconsistency you are talking about here by the way? The parameter will contain a list of all executed and stored events which sound logical to me – if you need the data, you should match the data nodes, not the params.

[michael-e]

The thing is that the parameter is rather useless to filter other datasources. And I don't see any reason to create this global namespace. It's up to the developer to know what will happen. So I would prefer:

Params:

<ds-m-storage.save-message>
    <item handle="name">name</item>
    <item handle="email">email</item>
    <item handle="subject">subject</item>
    <item handle="message">message</item>
</ds-m-storage.save-message>

Data:

<m-storage>
    <group id="save-message">
        <item id="name">Ted Tester</item>
        <item id="email">[email protected]</item>
        <item id="subject">Ein Test, es ist ein Test!</item>
        <item id="message">Hallo Test.</item>
    </group>
</m-storage>

[nilshoerrmann]

How would you drop these individual namespaces?
You cannot use the same event to add and drop so the names will differ.

[michael-e]

I see, you are simply dropping the complete events namespace, right? Is that clear to the developer?

Hmmm, OK, but still you can't use the param for filtering.

I will have to think a bit more. Why have you added a drop-type event filter at all? Any use case?

[michael-e]

If we put the drop filter aside for a minute, wouldn't the following be better?

Params:

<ds-m-storage.event-save-message>
    <item handle="name">name</item>
    <item handle="email">email</item>
    <item handle="subject">subject</item>
    <item handle="message">message</item>
</ds-m-storage.event-save-message>

Data:

<m-storage>
    <group id="event-save-message">
        <item id="name">Ted Tester</item>
        <item id="email">[email protected]</item>
        <item id="subject">Ein Test, es ist ein Test!</item>
        <item id="message">Hallo Test.</item>
    </group>
</m-storage>

[michael-e]

Scratch the filtering argument, you can't filter on that parameter output at all. Sorry, I should try and wake up.

[nilshoerrmann]

Why have you added a drop-type event filter at all? Any use case?

I dislike systems that let me do but not undo something. This is why I wanted to have a filter to remove the content as well.

If we put the drop filter aside for a minute, wouldn't the following be better?

I understand that the parameter output offers more data but I'm not sure if this is a necessity. As mentioned above, this would introduce the conceptual flaw that two different parts of the extension would interfere with each other: the action might pollute the filter results or vice versa.

[nilshoerrmann]

Regarding dropping via the filter: it would of course be possible to also drop specific namespaces. The extension could loop over all existing events and check for those having the Storage: Add filter attached and create separate filters like the ETM does (something like Storage: Drop "Save Message" Data.

[michael-e]

I dislike systems that let me do but not undo something

Then you shouldn't use events at all. There is no undo in event logic. :-)

Regarding the parameter output, you are right (see above).

The extension could loop over all existing events and check for those having the Storage: Add filter attached and create separate filters like the ETM does (something like Storage: Drop "Save Message" Data.

That might be cool, but would increase complexity, espcially to handle errors. One example: What happens if an add filter is removed from all events? Should the corresponding drop filter be erased from planet earth?

So, as long as there is no necessity to implement this, I think that your current solution is the best.

So I say leave it as it is.

[michael-e]

How should we name the filters? Suggestion:

• Storage: Add Event Data
• Storage: Drop All Event Data

[nilshoerrmann]

Should the corresponding drop filter be erased from planet earth?

If an add filter has been removed, I'd no longer display the drop filter in the backend but won't remove it from the event files until they are resaved. This is a known behaviour across the system in my experience.

Regarding the actual dropping action of the filter: if nothing has been added to the storage by an add filter, nothing will be dropped – the extension would still execute a drop action that will not alter the storage at all. No harm.

[nilshoerrmann]

How should we name the filters?

I like you suggestions.

[michael-e]

I still think that your proposal might be more complex than it looks now.

[EDIT]: Removed nonsense.

[nilshoerrmann]

Then you shouldn't use events at all. There is no undo in event logic. :-)

Just for the record: This is more like set (events) and get (data sources). So we do have two directions.
But yes, in my eyes Symphony's event system is far from perfect – it's half-baked.

[nilshoerrmann]

we might simply add a third event filter:

We'd need the following:

• Storage: Add Event Data
• Storage: Drop All Event Data
• Storage: Drop Event Data for "Send Email"
• Storage: Drop Event Data for "Add to Basket"

And so on …

[nilshoerrmann]

The code could be copied from ETM by the way.

[michael-e]

We'd need the following:
...

Yes, I already changed my above comment. :-)

The code could be copied from ETM by the way.

So do you want to implement it?

[michael-e]

Honestly, at the moment I don't have a single use case for the event filters... Do you have one?

[nilshoerrmann]

Yes: passing event data to a success page the user has been redirected to, so you can display a summary.

[nilshoerrmann]

I'll be offline for an hour or two now – will have a look at this again later.

[michael-e]

The example is not bad. :-)

In this case, how would you delete the data from the storage?

I'll be offline for an hour or two now

No prob.

[nilshoerrmann]

In this case, how would you delete the data from the storage?

By attaching the drop filter to the success page.

[michael-e]

So on the first success page you display the data, then there is a second success page which drops the data from the storage?

[nilshoerrmann]

Yeah, kind of: I was actually thinking of something like a dismiss button on the success page which redirects to the start. So yes, it would be a two step process.

When I was walking downtown, I have been thinking about your idea of not using an events namespace and maybe it's not such a bad idea. It would allow us to use the event filter to drop any namespace available (by either adding filters for existing namespaces in the event editor – if available – or by adding these filters to the event file manually).

Ich denke heute Abend noch mal darüber nach. Wir sind alle etwas angeschlagen: Max ist seit Anfang des Monats in der Kita und wir müssen uns alle noch an die dort vorherrschenden Bazillen und Viren gewöhnen. Logisches Denken fällt auf jeden Fall etwas schwer heute :/

[michael-e]

Nevermind, there is no hurry at all.

[savosik]

Hello. I have one question. I want to store submited value to storage for use as ds-parameter... Ex. User posted coupon code... he submitted value from input (input val attribute). This val must be stored in ds-storage for fiter another one datasourse (coupons).
-------- my form

<form action="" method="post">
       <input type="text" class="form-control" name="storage[discount][data]" value="XXX" placeholder="your code"/>
       <button type="submit" name="storage-action[set]" >submit</button>
</form>

------- current output

<ds-storage.discount>
      <item handle="data">data</item>
</ds-storage.discount>

------- but i need (for filter other datasource)

<ds-storage.discount>
      <item handle="data">XXX</item>
</ds-storage.discount>

How can I make it?

[michael-e]

As explained in the README:

…will contain the ids of the group's direct child items.

So outputting values is not a feature of the Storage extension. If you need that, I am afraid that you will have to create a custom data source, getting your hands dirty with PHP.

BTW, please open a separate issue next time. Your problem is not related to this thread!