I should point out the reason this matters and makes me panic a little.

Because of 5.7's Symfony based routing, you can pretty much route anything anywhere. This is really great news. Unless you have a website that has 15 addons all of them with ajax all of which have structured their views differently all of which you need to override.

If we don't land on a standard for this, blocks and packages could get really messy really quickly.

The same could be true for how to handle old tools and helper code as well.



ChadStrat

I agree with all Chad's reasoning that we really need a convention for this (as we do for many other things). The current lack of guidance on best practices for how more complex applications in 5.7 should be structured could soon lead to developers coming up with 100 different ways to do the same thing.

We need to allow some freedom for creative solutions, but the current blank slate will, as Chad says, lead to chaos.

(going back to an earlier instance of the same type of problem, still unresolved, search for "Page Type and Area Name Insanity")

I don't know enough about 5.7 yet to agree with the details of the above suggestion. But anything is better than nothing.

I totally agree with this. Ronny and I has been talking a lot about how to begin and where to end making good solid add-on programming. I have actually stopped it there and told Ronny that we should not go further before some good solid documentation has arrived.

It has been a pleasure to work with 5.7, and I think that I am getting the concept of it, but by far the knowledge that ensures good solid add-on programming!

/Michael

Some guidence would be good on this. I started playing around today with ajax and a dashboard single page, I see a few differnet conversations in the forums, but don't know how we should really do it. C5 guys???

Has there been any other discussion on this?

I like this approach and I do not see any other suggested outline.

Thanks for putting this up, Chad.

Rick

Hey Chad
Has there been further discussion on this topic? Where there any official best practices published in the meantime? I didn't find anything.

I wonder how you managed to get the views in the block folder as you wrote in your initial post. If I try this the view won't get rendered. If I locate controller and view in the corresponding folders in the package directory everything works fine.
Perhaps I am getting something wrong but in my opinion the controllers and the views that are only used for a specific block should be located in this blocks directory. It feels wrong if they are scattered throughout the whole package directory.

I'd really like to hear your opinion.

Cheers
Markus

I never got ajax block views to work from the block folder. My second post here shows how we structure our packages.

ChadStrat

Hello there
As Chad stated it isn't possible to put controllers and their corresponding ajax-views in the block folder of a package.
I investigated on the problem and found the following issue:
The controller can't instantiate the view because the path to the view is messed up. The cause for this is that the function uncamelcase (concrete/bootstrap/helpers.php) isn't able to handle strings containing backslashes.
On my test installation i hacked the uncamelcase function and everything seems to work now.
Do you guys think this would be something desirable for one of the next releases to be included?
I still think it would be nice to have the controllers and views wich are solely used by one specific block in this blocks directory.

Cheers Markus

@Lemon - thanks for looking into this further. I would agree with you. But I am curious what other unintended consequences this change has? I think that change should be fully explored and perhaps do a path find/search to review any instances of this same method and how this change might impact those.

ChadStrat

I looked through the code. The function isn't used that frequently. I looked at all the usages and found only one that needs to be updated. The rest should still work as intended. I attached a file in wich all usages are documented. Perhaps someone could cross-check my results? Then we could consider to put it on git to be integrated in a future release. What do you think?

Markus

Sorry to come to this discussion as a Concrete5 newbie, I'm just doing my first project using the CMS, so I don't have the 5.6 conventions to fall back on. But I'm finding the ajax for blocks a bit baffling. I've spent two days trying to figure out something that would take me 30 minutes in straight php. I'm just totally confused why the ajax calls can't just refer to a method within the BlockController and have the ajax methods in the Block Controller to output html or call a view file?

I'm working on a testimonials management system with a dashboard page. I have a block in which the user can specify how many testimonials to show up, how many per page, sort order, etc. Then I have another database table with all the testimonials in it, and I've extended DatabaseItemList to do pagination on the results of the query. I set up the custom controller as per the conventions in my own package.

Basically, if there are multiple pages I want the block to automatically show the pagination and use ajax to flip through the pages. The ajax and pagination are working, but have some problems with the ajax output.

The problem with separating the ajax calls to a separate controller is that the ajax controller doesn't get any instance data from the block, so in addition to having to recreate the testimonials list, and sending what page I'm on, I also have to figure out how to get all the data the user set up in the block instance to the new controller for the ajax call. Up to now I can't see a way.

Having experience in CakePHP, all this was really easy. Ajax and view methods coexisted in the same controller. Maybe I'm just confusing things, or haven't quite grasped the Concrete5 way of doing things? Can anyone give me a bit of help, as the tutorials out there so far are a bit too simple?

Ok, finally figured it out. Just for anyone else having the same issue, you can access the current instance by:


instead of using the BlockType, which preserves all the instance data. To access the methods, use: