Closed qzminski closed 7 years ago
Okay I think all changes have been implemented now.
Yanick told me you discussed the question whether the thing should only support content elements and module. Now looking at your code, I wonder why there is a separation between the two? Wouldn't it be way easier to just have a general "storage" that can store and receive the content by a unique ID? Then someone could store something else as well and handle the respective events.
I don't think we should support that. It's a very unique use case. Building something more general should be something for Contao 4.
I totally agree with Yanick.
I should better explain. My thoughts were not about supporting more use cases in the first place, but about making the whole storage thing simpler. There is a lot of code duplication because exactly the same functionality is implemented for frontend module or content element twice.
Hmm, I agree.
Me too
Okay, I think it should be fine now. If the event is triggered once again then the current request is aborted.
The elements that are in progress work a little bit different though. Given the example:
element-a –> event-a, event-z
element-b –> event-b, event-z
If the the event-z
is triggered then both elements are being updated. Now if we trigger the event-a
, we can't obviously abort the event-z
due to element-b
so I let the event-z
continue and start the event-a
in parallel. At this point however element-a
will know that it should get the content from the last triggered event which is event-a
and not from event-z
.
Looks great, imho 👍 @aschempp LGTM?
Okay all recent change requests applied.
My thoughts/suggestions:
dispatch()
it should already be stored from the case where it was generated and the helpers were injected.