codefog / contao-haste

Haste is a collection of tools and classes to ease working with Contao
http://codefog.pl/extension/haste.html
MIT License
43 stars 24 forks source link

Feature/ajax reload trigger #97

Closed qzminski closed 7 years ago

aschempp commented 7 years ago

My thoughts/suggestions:

  1. Use one event listener for all subscriptions, simply with three methods
  2. Instead of re-generating the content/module etc on dispatch() it should already be stored from the case where it was generated and the helpers were injected.
  3. I think we should start an Ajax namespace instead of placing everything in Util
qzminski commented 7 years ago

Okay I think all changes have been implemented now.

aschempp commented 7 years ago

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.

Toflar commented 7 years ago

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.

qzminski commented 7 years ago

I totally agree with Yanick.

aschempp commented 7 years ago

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.

Toflar commented 7 years ago

Hmm, I agree.

aschempp commented 7 years ago

Me too

qzminski commented 7 years ago

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.

Toflar commented 7 years ago

Looks great, imho 👍 @aschempp LGTM?

qzminski commented 7 years ago

Okay all recent change requests applied.