allow configurable page headings using tokens

[pxpm]

WHY

BEFORE - What was wrong? What was happening before this PR?

The main idea behind this came up from #4902

We discussed it internally and aknowledge that the PR as is was not mergeable, and not everyone agreed with the change so it was postponed.

I was doing now a cleanup and stumbled upon it. I was one of the people that liked the "idea" of the PR. So I came up with this solution.

AFTER - What is happening after this PR?

This gives developers the flexibility to configure the page headers beyond just changing a word at a time.

Is this a good idea ? At first it looks 🤷

HOW

How did you achieve that, in technical terms?

Created two new language strings to represent the page_heading and page_subheading in full. By default accepted the needed parameters, but this can be extended in the future to pass additional parameters.

At the moment the available parameters are:
:singular - $crud->entity_name
:plural - $crud->entity_name_plural
:action - trans('crud.add/edit/preview'),

Is it a breaking change?

Maybe not ?

[pekka]

This sounds like a reasonable solution!

[tabacitu]

Are the empty strings here intentional?

[pxpm]

This is the only reason why this PR is not merged yet I think I wouldn't have called for your judgment if it wasn't for this use case.

This triggers my "spidey" sense too, so it's super you have noticed the same. (I would have talked you about this anyway).

So the reason this happens is because in ListOperation we don't show any "action" (Create, Update, Preview etc..), and also we don't want to show any "singular", mean Monster.

Translating this to placeholders means we would show the Monsters (:plural) in the heading, and two empty strings in the sub heading (where usually we have Create Monster (:action : singular))

Ideally singular, plural, action placeholders should always have value, filled from crud variables, without caring in what operation they are used. To achieve this, we need to remove the heading and subheading from lang files, and make them part of each operation.
So that ListOperation can set heading to :plural and nothing in subheading, while CreateOperation set heading to :plural and subheading to :action :singular.

We can still keep the defaults for backwards compatibility, and set the operation.heading to null or something and we keep the same translations/behavior we currently have. But developer can setup operation.heading in their Controller and it would overwrite our defaults. I think this is way more resilient that this placeholder approach.

What you think ?

[siberfx]

@section('header')
    <div class="container-fluid">

    <section class="header-operation container-fluid animated fadeIn d-flex mb-2 align-items-baseline d-print-none" bp-section="page-header">
        @include('crud::inc.page_headings', [
        'singular' => '',
        'plural' => $crud->entity_name_plural,
        'action' => '',
        'backButton' => false
        ])
    </section>
    </div>
@endsection

you forgot to add parent div, its broken when I tried :) and the same for reorder, show, create edit

[pxpm]

Hey @siberfx thanks for the heads up.

What div are you referring to ? From the code changes I didn't remove any div, I just moved the <h1> and the <p> to a new file.

Also I cannot find the mentioned div in the main branch of CRUD:

CRUD/src/resources/views/crud/create.blade.php

Line 14 in dee2eec

@section('header')

Maybe that's a custom change you made to your views ?

Cheers

[siberfx]

actually I saw between your @section codes, maybe I am the one who uses the outdated versions of these blades.. but if in updated version also contains the same structure, than I might be right :) just I applied these changes on my existing environment on local and saw them broken. so I decided to let you know :)

[pxpm]

Thanks @siberfx appreciated 🙏

Thing is that if you have those files overwritten in your local resources/views folder, you won't get the updated versions when/if we release them, so we can't break your app. 👍

This is still kind of POC, because I am still not happy with all the mumbo-jumbo setting "empty" stuff etc in some operations. I may have time to gives this a "fresh" look in the next month or so I hope 🙏

Cheers

[tabacitu]

Very clean PR, well done @pxpm 👏👏👏

I have one thing that jumped out in a comment above. In addition to that:

1. How will someone be able to change the heading/subheading? By changing swapping the :singular and :plural in the language file - which will change all the CRUDs in one go, correct?

2. Only found one bug - on the ListOperation the subheading isn't where it's supposed to. In this operation, the subheading gets replaced with JS with the description that DataTables calculates.
   

3. For future reference, I do agree that in terms of visual hierarchy the BIGGEST heading should be "Create Article" not "Articles". Pedro convinced me of that on Discord. I just wish we had created something like this from the start (having the entity name as the "pre-heading" as Tabler defines it). But doing that right now... seems like it'd be a lot of work for very little benefit. And probably a breaking change. We have to take into account that:

• people might have created custom operations, so if we push a pre-heading now those operations don't get it;
• we'd have to style this in all 3 themes;

But if we want the "Create Article" as the default heading in the next version, adding a "pre-heading" is probably the way to go, if you ask me.