All fluent syntax methods should be camelCase

[tabacitu]

The fluent objects set whatever method you call as an attribute on that field/column/etc, even if that method doesn't exist on the object itself. So we've kept it simple - whatever method you call on the fluent object, that's the exact name of the attribute that will be set on the field. This makes it 100% backwards-compatible. For example, call CRUD::field('category')->inline_create(true) and it will set inline_create to true.

But it's ugly. And inconsistent. Sure, it makes sense, but... it's odd to have snake_case methods inside a fluent API - its not very Laravely and it's a little inconsistent with other parts of Backpack (ex - the CrudPanel object).

I wonder if there's a way to allow people do CRUD::field('category')->inlineCreate(true) without a breaking change. What if we turn the attribute from camelCase to snake_case, by default, before we set it? This could be as simple as:

    public function __call($method, $parameters)
    {
-        $this->setAttributeValue($method, $parameters[0]);
+        $this->setAttributeValue(Str::snake($method), $parameters[0]);

        return $this->save();
    }

The way I see it:

• attributes should be snake_case
• method names should be camelCase
• it's not terribly difficult to understand that calling datePickerOptions([]) will be available in the field as $field['date_picker_options']
• there are A LOT more attributes that use snake_case than camelCase inside our blade files, so converting those few camelCase ones to snake_case should not be very time-consuming

Thoughts anyone? Am I the only one that hates writing snake_case fluent methods? (apart from @tumf87 of course, who reported this)

[tabacitu]

(one could argue that we should make the attributes camelCase...)

[tabacitu]

What I found

Fields

• [ ] simplemde has a few camelCase attributes
• [ ] easymde has a few camelcase attributes

That means it would be pretty simple to do this for Fields. Just make those 2 fields support both camelCase and snake_case.

Columns

• [ ] most attributes on all columns are camelCase: searchLogic, visibleInModal, visibleInTable, visibleInExport, visibleInShow, searchLogic, orderLogic,
• [ ] model_function column uses function_name and function_parameters, but it could be made to support both camelCase and snakeCase, inside the blade file;
• [ ] model_function_attribute column - same as above;
• [ ] multidimensional_array uses snake_case
• [ ] number uses snake_case

This one is more tricky. For consistency between fields and columns, we should probably turn searchLogic into search_logic at the CrudPanel level. Either way, for those who have heavily customized their admin panels, or created custom columns, or overwritten their search() method, this will be a breaking change...

Unless we make fields attributes snake_case, but column attributes camelCase, which... could be introduced as a non-breaking change, but... it would fix one inconsistency with another inconsistency.

Filters

No snake_case as far as I can tell.

Buttons

No snake_case as far as I can tell.

Widgets

• [ ] should convert camelCase methods to snake_case attributes in constructor;
• [ ] progress and progress_white have camelCase attributes, so they should support both;
• [ ] viewNamespace is camelCase, so it should support both;

---

All in all, it doesn't look like it'd be too difficult to make camelCase methods a thing in fluent syntax, for everything except Columns. But... what do we do about Columns?!