Content Browser: Returning the Items
Our Content Browser is sort of working. We can see our one location... we just don't have any results yet. That's because, for whatever location is selected, the Content Browser calls getSubItems()
. Our job here is to return the results. In this case, all of our recipes. If we had multiple locations, like recipes divided into categories, we could use the $location
variable to return the subset. But we'll query and return all recipes.
Querying in getSubItems()
To do that, go to the top of the class and create a constructor with private RecipeRepository $recipeRepository
:
// ... lines 1 - 4 | |
use App\Repository\RecipeRepository; | |
// ... lines 6 - 11 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
public function __construct(private RecipeRepository $recipeRepository) | |
{ | |
} | |
// ... lines 17 - 70 | |
} |
Then, down here in getSubItems()
, say $recipes = $this->recipeRepository
and use that same method from earlier: ->createQueryBuilderOrderedByNewest()
. Below add ->setFirstResult($offset)
... and ->setMaxResults($limit)
. The Content Browser comes with pagination built-in. It passes us the offset and limit for whatever page the user is on, we plug it into the query, and everyone is happy. Finish with getQuery()
and getResult()
:
// ... lines 1 - 11 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
// ... lines 14 - 46 | |
public function getSubItems(LocationInterface $location, int $offset = 0, int $limit = 25): iterable | |
{ | |
$recipes = $this->recipeRepository | |
->createQueryBuilderOrderedByNewest() | |
->setFirstResult($offset) | |
->setMaxResults($limit) | |
->getQuery() | |
->getResult(); | |
} | |
// ... lines 56 - 70 | |
} |
Notice that getSubItems()
returns an iterable
... actually it's supposed to be an iterable of something called an ItemInterface
. So we can't just return these Recipe
objects.
Creating the ItemInterface Wrapper Class
Instead, in src/ContentBrowser/
, create another class called, how about RecipeBrowserItem
. Make this implement ItemInterface
- the one from Netgen\ContentBrowser
- then generate the four methods it needs:
// ... lines 1 - 2 | |
namespace App\ContentBrowser; | |
use Netgen\ContentBrowser\Item\ItemInterface; | |
class RecipeBrowserItem implements ItemInterface | |
{ | |
public function getValue() | |
{ | |
// TODO: Implement getValue() method. | |
} | |
public function getName(): string | |
{ | |
// TODO: Implement getName() method. | |
} | |
public function isVisible(): bool | |
{ | |
// TODO: Implement isVisible() method. | |
} | |
public function isSelectable(): bool | |
{ | |
// TODO: Implement isSelectable() method. | |
} | |
} |
This class will be a tiny wrapper around a Recipe
object. Watch: add a __construct()
method with private Recipe $recipe
:
// ... lines 1 - 4 | |
use App\Entity\Recipe; | |
// ... lines 6 - 7 | |
class RecipeBrowserItem implements ItemInterface | |
{ | |
public function __construct(private Recipe $recipe) | |
{ | |
} | |
// ... lines 13 - 32 | |
} |
Now, for getValue()
, this should return the "identifier", so return $this->recipe->getId()
. For getName()
, we just need something visual we can show, like $this->recipe->getName()
. And for isVisible()
, return true
. That's useful if a Recipe
could be published or unpublished. We have a similar situation with isSelectable()
:
// ... lines 1 - 7 | |
class RecipeBrowserItem implements ItemInterface | |
{ | |
// ... lines 10 - 13 | |
public function getValue() | |
{ | |
return $this->recipe->getId(); | |
} | |
public function getName(): string | |
{ | |
return $this->recipe->getName(); | |
} | |
public function isVisible(): bool | |
{ | |
return true; | |
} | |
public function isSelectable(): bool | |
{ | |
return true; | |
} | |
} |
If you had a set of rules where you wanted to show certain recipes but make them not selectable, you could return false
here.
And... we're done! That was easy!
Back over in our backend class, we need to turn these Recipe
objects into RecipeBrowserItem
objects. We can do that with array_map()
. I'll use the fancy fn()
syntax again, which will receive a Recipe $recipe
argument, followed by => new RecipeBrowserItem($recipe)
. For the second arg, pass $recipes
:
// ... lines 1 - 12 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
// ... lines 15 - 47 | |
public function getSubItems(LocationInterface $location, int $offset = 0, int $limit = 25): iterable | |
{ | |
// ... lines 50 - 55 | |
return array_map(fn(Recipe $recipe) => new RecipeBrowserItem($recipe), $recipes); | |
} | |
// ... lines 59 - 73 | |
} |
This is a fancy way of saying:
Loop over all the recipes in the system, create a new
RecipeBrowserItem
for each one, and return that new array of items.
All right, let's see what this looks like! Refresh the layout, click on the Grid, go back to "Add items" and... got it! We see ten items!
Implementing getSubItemsCount()
But we should have multiple pages. Ah, that's because we're still returning 0
from getSubItemsCount()
. Let's fix that. Steal the query from above... paste, return this, remove setFirstResult()
and setMaxResults()
, add ->select('COUNT(recipe.id)')
, and then call getSingleScalarResult()
at the bottom:
// ... lines 1 - 12 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
// ... lines 15 - 59 | |
public function getSubItemsCount(LocationInterface $location): int | |
{ | |
return $this->recipeRepository | |
->createQueryBuilderOrderedByNewest() | |
->select('COUNT(recipe.id)') | |
->getQuery() | |
->getSingleScalarResult(); | |
} | |
// ... lines 68 - 77 | |
} |
And just like that, when we refresh... and open the Content Browser... we have pages!
Adding the Search Functionality
Tip
Though this solution works fine, search()
and searchCount()
are deprecated
in favor of searchItems()
and searchItemsCount()
. To use the new methods,
keep the old methods (because they're still part of the interface) and use the
following for the new methods:
class RecipeBrowserBackend implements BackendInterface
{
// ...
public function search(string $searchText, int $offset = 0, int $limit = 25): iterable
{
// deprecated
return [];
}
public function searchCount(string $searchText): int
{
// deprecated
return 0;
}
public function searchItems(SearchQuery $searchQuery)
{
$recipes = $this->recipeRepository
->createQueryBuilderOrderedByNewest($searchQuery->getSearchText())
->setFirstResult($searchQuery->getOffset())
->setMaxResults($searchQuery->getLimit())
->getQuery()
->getResult();
return new RecipeBrowserSearchResults($recipes);
}
public function searchItemsCount(SearchQuery $searchQuery)
{
return $this->recipeRepository
->createQueryBuilderOrderedByNewest($searchQuery->getSearchText())
->select('COUNT(recipe.id)')
->getQuery()
->getSingleScalarResult();
}
}
You'll also need a new RecipeBrowserSearchResults
class:
// src/ContentBrowser/RecipeBrowserSearchResults.php
namespace App\ContentBrowser;
use Netgen\ContentBrowser\Backend\SearchResultInterface;
use App\Entity\Recipe;
class RecipeBrowserSearchResults implements SearchResultInterface
{
public function __construct(private array $results)
{
}
public function getResults(): iterable
{
return array_map(fn (Recipe $recipe) => new RecipeBrowserItem($recipe), $this->results);
}
}
Thanks to Joris in the comments for noticing this!
Ok, but could we search for recipes? Absolutely. We can leverage search()
and searchCount()
. This is simple. Steal all of the logic from getSubItems()
, paste into search()
and pass $searchText
to the QueryBuilder method, which already allows this argument:
// ... lines 1 - 12 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
// ... lines 15 - 68 | |
public function search(string $searchText, int $offset = 0, int $limit = 25): iterable | |
{ | |
$recipes = $this->recipeRepository | |
->createQueryBuilderOrderedByNewest($searchText) | |
->setFirstResult($offset) | |
->setMaxResults($limit) | |
->getQuery() | |
->getResult(); | |
return array_map(fn(Recipe $recipe) => new RecipeBrowserItem($recipe), $recipes); | |
} | |
// ... lines 80 - 88 | |
} |
If you want to have a bit less code duplication, you could isolate this into a private
method at the bottom.
Also copy the logic from the other count method... paste that into searchCount()
, and pass it $searchText
as well:
// ... lines 1 - 12 | |
class RecipeBrowserBackend implements BackendInterface | |
{ | |
// ... lines 15 - 80 | |
public function searchCount(string $searchText): int | |
{ | |
return $this->recipeRepository | |
->createQueryBuilderOrderedByNewest($searchText) | |
->select('COUNT(recipe.id)') | |
->getQuery() | |
->getSingleScalarResult(); | |
} | |
} |
And just like that, if we move over here and try to search... it works. That's awesome!
Alright - select a few items, hit "Confirm" and... oh no! It breaks! It still says "Loading". If you look down on the web debug toolbar, we have a 400 error. Dang. When we open that up, we see:
Value loader for
doctrine_recipe
value type does not exist.
There's just one final piece we need: A very simple class called the "value loader". That's next.
I see on my setup, 'searchItems' and 'searchItemsCount' are called. Then there is an error because they don't return anything, so it returns null, which isn't an int, and something blows up :wink:.
I also see search and searchCount are marked deprecated?
I had to move the code to searchItems / searchItemsCount. The parameter you receive there is a SearchQuery object that contains basically the same as before (searchText, offset, limit).
But to return results, you have to return an object, that will return the results...
So instead of doing the array_map, you have to create a little wrapper-object that implements SearchResultInterface, that contains a single method that returns the items.
I just made an object that receives the $recipes array in the constructor, and in the getResults() function does the array_map() call from your tutorial. Just another piece of boiletplate, but I guess it's needed for more advanced stuff or they wouldn't be doing it.