Fix fetching routes when there's an underscore in the field name

[pxpm]

The issue was raised in #2874

We were using Str::kebab to convert the function names to url-segments but that is not the best parser for this scenario because of function names.

Per convention you must define the fetch routes as public function fetchWhatever() , fetchWhatever_dontcare, fetchWhateverDontcare; anyway, beeing it a valid function name it should be a valid url segment to use. No need to parse Str to other format than Str::snake, so we can get valid fetch routes and valid function names. Also it follow Laravel convention, when adding a field with name billing_address we know for sure it will get the fetchBillingAddress or fetchBilling_address.

It get's it's urls from entity, that should match model entity and fetchEntity function.

Eg:

    public function someEntity() { } 
// entity in field: someEntity
// fetch: fetchSomeEntity
// fetch url: https://backpackforlaravel.com/admin/entity/fetch/some_entity

[dividy]

Nice !
Fast answer :-)

However, not working on my side unfortunately.

With a field customer_id :

[
                'label' => 'Client',
                'type' => "relationship",
                'name' => 'customer_id',
                'entity' => 'customer',
                'attribute' => 'full_name_with_company',
                'ajax' => true,
                'placeholder' => "Choisissez un client",
                'inline_create' => [
                    'modal_class' => 'modal-dialog modal-lg',
                ]
            ],

Result :
/site/fetch/customer_id 404 (Not Found)

The only solution I found is providing the right data_source manually :

                'data_source' => '/site/fetch/customer',

But you have to do it for every field.

[pxpm]

Indeed @dividy

Yesterday it seemed ok to me to setup everything with field name, but well.. I was wrong.

Reverted the PR to use entity again, but snake case it.

[tabacitu]

Looks good to me. Is this tested & ready to merge @pxpm & @dividy ?

[tabacitu]

@pxpm should I merge this? Are you sure this a non-breaking change?

[pxpm]

I think as of now this will be a breaking change because everyone that setup fetch might used the data_source config to avoid this error. So if we merge this, the people who did the trick to solve the problem will have their app's broken.

I am now wondering if we need it at all (snake, or camel or kebab or whatever).

The fetch "route name" comes from a function fetchSomething. That function to have a valid name would make sure we have a valid url doesn't it? Or you see a way that a function name could not be a valid url ?

So why not https://backpackforlaravel.com/admin/entity/fetch/someEntity

Who cares about url as long as it is valid ?

[promatik]

Note for future us;
When this PR get's merged on v4.2, we should remove the note introduced with Laravel-Backpack/docs#244.

[tabacitu]

So why not https://backpackforlaravel.com/admin/entity/fetch/someEntity
Who cares about url as long as it is valid ?

I don't 😀

What do you think now, 1 year later, @pxpm - is this worth doing in 4.2? I'd rather keep the breaking changes to a minimum.

[tabacitu]

I still agree to doing this, but... we have enough breaking changes in 4.2 already... Since there's a reasonable and documented workaround for people who encounter this... I'm going to postpone merging this until the next major version... 😔

I've fixed the merge conflicts, though. So that it's easier for future-us to merge it.
Sorry guys.

[scrutinizer-notifier]

The inspection completed: No new issues

[tabacitu]

Also, let's close this in favour of #3930 which does the same thing but a bit cleaner.