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.

-Jordan

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...

http://www.concrete5.org/community/forums/5-7-discussion/concrete5-...

-Steve

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.

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.

That's a good idea; I ended up doing something like that

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

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 context...so 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:

/packages/proevents/blocks/proevents_list/controllers/controllername.php
/packages/proevents/blocks/proevents_list/views/viewname.php

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?

ChadStrat

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?)

In case anybody struggle with the same type of issue, please look directly at the marketplace for Andrews example :

http://www.concrete5.org/marketplace/addons/likes-this-block...

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.)

https://www.concrete5.org/documentation/developers/5.7/working-with-...

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

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
development.