Implementing Block Ajax in 5.7

I recently posted the following...

...but I thought it warranted its own topic, so I'm starting this thread. (I don't know if this should be a github issue or not, as it might simply be something I don't understand about working with AJAX requests in 5.7.)

Anyway, my question has to do with AJAX requests within packaged blocks. Is there a convention to be followed when defining routes? They're easy enough to define with the new routing system, but it seems to me there's the potential for route collisions between different packages. (Actually, it would be more of a co-opting, as the last registered route would take precedence.)

While the old tools file approach is still supported, it's officially deprecated, so I'd like to use the new approach for future development efforts. Besides that, the tools file approach seems broken for non-core blocks.

Anyone have any input or insights?



jordanlev replied on at Permalink Reply
Hey Steve,
Just reading through some 5.7-related forum threads, so I haven't actually worked with any of this yet. But if you're concerned about route collisions between packages, it seems to me that the safest bet would be to create a route that mimics the old /tools/ structure. For example, the route could be /packages/your_pkg_handle/tools/your_route

Or for that matter, any route with your package handle in it should be "unique" enough to avoid collisions.

Just a thought off the top of my head.

Shotster replied on at Permalink Reply
Thanks, Jordan. That's pretty much what I was thinking - i.e. that a route should include the package handle. I posted mainly to raise awareness and propose that an official convention be adopted. It would be good to have something "official" to follow for PRB submissions, etc. Perhaps simply "include the package handle in your route" would be good enough. That's pretty much what I suggested here...

andrew replied on at Permalink Reply
These are all excellent options and suggestions. I will try and take a look at a demo block I made today that has some AJAX functionality and port it to 5.7, and will post back with some thoughts (and perhaps some minor API syntactic updates that will make it easier to generate these routes.) Regardless I imagine it'll look very similar to what Jordan and Chad are proposing.
JohntheFish replied on at Permalink Reply
Maybe there could be a 'route helper' that takes a few parameters setting out the purpose of the route and package, then generates the appropriate route, thus enforcing at least part of whatever the convention is.
andrew replied on at Permalink Reply
That's a good idea; I ended up doing something like that
andrew replied on at Permalink Reply 1 Attachment
Hey everybody, I put together a quick update of My "Likes This!" tutorial package for 5.7. I'm attaching it to this message. I try to achieve most of the same stuff that the first package has, with 5.7 compatibility and best practices (assets, the built-in overlay library) and an example of routing. You'll need the absolute latest version from Github for this to work, as well short tags enabled.

This isn't 100% set in stone but it's getting there. I'd be interested in your thoughts on directory naming, how the routes are automatically determined to be a part of the likes this package, the Router::route() method (inspired by JohnTheFish) and the URL::route() method. These methods automatically generate route names based on packages. We should also use them in the routes.php file in the core (haven't got around to doing that yet.)

Let me know what you think
RadiantWeb replied on at Permalink Reply
Thanks for this Andrew.

Yeah I like having /views and /controllers. But for larger packages that can start to get pretty messy.

For example, ProEvents has dozens of different ajax views for just the list block.

I realize we all can do it really however we want with routes...but it would be great to document and standardize this in my mind.

To me, having purposeful readable folder structure by nature seems appropriate. So /packages/proevents/controllers/blocks/proevents_list/controllername.php paired with /packages/proevents/views/blocks/proevents_list/viewname.php

But we already have a /block folder for that to me it makes more sense to keep things in that context. Otherwise you have /block in various places when there technically is no need:


Chicken or the egg perhaps. I am in favor of keeping it clean. And sense we already have to have a /block folder for each block by virtue of the app design, might as well keep things tidy imho.

How is either case overridden? User X wants to override an AJAX view?

goutnet replied on at Permalink Reply
Hi andrew, the version on this forum does not properly work (2.0.1 on the marketplace has the fix, in how you use RouteHelper class from the controller).

Can you remove this attachment and/or replace it by the new one (2.0.1 on the marketplace) to avoid confusion.

Also, on the 2.0.1 version currently in the marketplace, you lefft 3 .DS_Store files.

Here again, as a PRB member (and admin :/) I would like you guys to clean the archive to give the future addons dev the right example :)

(Another side note, in your block view.php, you use Loader::helper, but I thought this was supposed to be deprecated in favor to Core::make right?)
goutnet replied on at Permalink Reply
In case anybody struggle with the same type of issue, please look directly at the marketplace for Andrews example :
andrew replied on at Permalink Reply
Whew, thank goodness: just an update on this: 5.7.5 will bring back the $view->action() functionality in block add/edit templates (for server-side processing.)
italinux replied on at Permalink Reply
Hello there

I am actually looking to find / buy Block by Ajax for c5.7.
Are you aware of anything available or under development?

Thank you in advace
JohntheFish replied on at Permalink Reply
I expect I will eventually port Block by Ajax to 5.7, but its not
something on my immediate To-Do list.

I don't know of anything similar in the 5.7 marketplace or under