https://twill.io logo
Join Discord
Powered by
Lucius Vorenus - G'day, all! I'd appreciate a p...
# ❓questions
l
G'day, all! I'd appreciate a pointer on how I can display just one componentBlock (other use cases might be desirable to have a more than one) from a model (article) in listings (ie index page). (I have no issue displaying the whole thing.) TIA! As well, I was trying to figure out how the mapping works on the renderBlocks, as it may have been the answer. Is the block-type fully qualified or just relative to your model base directory, and, for componentBlocks, are you referring to the block file in the View/Components/Twill/Blocks/Article dir? (i have my class files for article in there)
i
you could trick your model into having the single block you want to render instead of all of them so you can still use the renderBlocks method
l
Is there an alternative programming pattern that I could have used? Context: I'm using what I know of Laravel programming patterns, and would have assumed that doing what I discussed above was a simple matter of me not having seen / read / understood Twill documentation? Is there a much easier way that you would have approched a solution to the 'problem' I presented? Aka, how would you do an index listing using the detail from the article.header block, as follows...
Copy code
<?php
    /**
     * @return Form
     * TODO: update Wysiwyg type to tiptap when super and sub scripts enabled.
     */
    public function getForm(): Form
    {
        return Form::make([
            Input::make()
                ->name('title')
                ->label('Title')
                ->note('Text: max 200 characters')
                ->placeholder('Definitely need this!')
                ->maxLength(200)
                ->required(),
            Wysiwyg::make()
                ->name('summary')
                ->label('Summary (Use as first para)')
                ->note('Text: prob 3-5 sentences. Used as summary in related article blocks etc')
                ->type('quill')
                ->toolbarOptions(['bold', 'italic', 'underline',
                    ['script' => 'super'], ['script' => 'sub']])
                ->required(),
            Input::make()
                ->name('author')
                ->label('Author')
                ->note('Articles always have an author, whether you or an alias!')
                ->maxLength(100)
                ->required(),
            Input::make()
                ->name('reading-time')
                ->label('Approximate Reading time (mins)')
                ->note('Min:3, Max:20')
                ->type('number')
                ->min(3)
                ->max(20)
                ->required(),
            Medias::make()
                ->name('cover')
                ->label('Cover Image')
                ->fieldNote('Used at the top of the article')
                ->required(),
            Input::make()
                ->name('attribution')
                ->label('Attribution')
                ->note('Use of photos from sources (even free ones, except your own) requires an attribution.')
        ]);
    }
}
I'm probably also expressing a personal frustration that I keep feeling that about (figuratively) 3 chapters of the documentation on basics has disappered for me. I have never struggled with learning new stuff (except CAD - just can't do CAD!) like I have with Twill, and I come from happily programming Drupal! (until they started the move from the offshore island back to the mainland!). Yes, I'm older and take time to absorb new cognitive challenges, but that's not terribly different for a proportion of people who have (perhaps good) skills in PHP, and a passing / reasonable familiarity with Laravel. I'm delighted at the support that I've got from the Discord server, particularly from you, @ifox, but better documentation would negate the need for this level of support.
From reading a lot of comments / questions on this platform, I get the impression that the assumption of level of competence on PHP / Laravel is probably higher than it actually is! I'm delighted to read that you are intending to provide a more sophisticated installable example based on the Pentagram website / demo. Can't come soon enough. Anyway, hope you're reading this on a Monday morning (EST), and you had a great weekend! I still think Twill absolutely ticks all the boxes. Fantastic work; don't want you to mistake the intent of my comments.
I'm off to play some Transport Fever 2!
i
Thanks for all this. I totally understand your perspective. The documentation has been a challenge for many in the past and we've made a lot of improvements in the past year, with more to come. Twill can do a lot more than what we have been able to properly document, and I always advise to dive in to the sources. It is all standard Laravel underlying and typing makes it a lot more discoverable now (still some work to do there, too, though). But there are aspects that may sound obvious to us that may not be for others, and we're always open to hear that feedback, as much as we are open to external contributions on the docs. Regarding your solution to the problem you exposed, this is not how it is best approached (though it can still work). The information you are storing in a header block is not "content", its actual data describing your article. These fields should live outside of the block editor, using actual columns in your articles table. Then, instead of rendering a content block on an index listing page, you would render whatever you need (assuming some sort of index card) using the article properties. The same way you can already access 
$article->title
. Now, if you want to keep your current approach, you could do something as simple as: 
$article->blocks->first()->content->summary
. But it's not robust to rely on the CMS user always putting the header block as the first block. So you could also do: 
$article->blocks->where('type', 'header')->first()->content->summary
. But then if the user puts 2 header blocks, what happens? I'm purposefully mentioning all this because this should help you understand why this information is not something you want to use a block for.
Finally, and that might have been obvious to you already, but for completeness sake, your index / listing of articles page, is something you're expected to setup a route for in the laravel app (be it to return a blade view or a json response for an headless approach), and in the controller for that route, make a query to the article model to fetch all the articles you want for that page (could be all of them, could be a paginated list, could be a bunch of featured articles only, whatever you need really), to finally return that to a view in your case, where you can loop over a collection of articles, which would have properties like 
summary
and 
author
, directly accessible, not deeply nested under a specific block.
regarding a more sophisticated example, I would highly suggest checking these open source projects: https://github.com/area17/awesome-twill#open-source-twill-projects
l
Sorry for the lack of conciseness in the ramble above! As I've said before, the version 3 docs are much, much better in many respects than previous. Needless to say, if I actually understood Twill 3 well enough, I'd give you a hand with them! ...and thanks for the patient and detailed reply. I was beginning to think that I shouldn't be putting it in a block, and sitting looking at the Opengraph fieldset, which aren't in a block, and have a similar set of info already. I had considered whether I could trust the ONE user that there will be for the current project, and reckoned I could rely on them to put the Header block in first, but your general point about relying on users to do anything right is spot on. Having some form of card on the index page is the right idea, it was just how to implement. The examples: I had the artic.edu installed here, but removed it as it was based on twill 2, will reinstall. Thanks for the others as well. I'll get those installed shortly. the $article->blocks... you mentioned. That's from HasBlocks.php, isn't it? I did go looking in the various files for functions related to blocks, but it would have been a fair leap in intuition to come up with the statements you mentioned above. I'll go off and have a look at these examples. Thanks again.
Great. I can see how everything in any block can be accessed using the 'blocks' function, and it also exposes the fact that the data is all Laravel Collections! I've a much better idea how to move forward.
PreviousNext
Powered by