Crud: Can we start adding more buttons like enable ?

[Athuli7]

The current button collection is nice. But something I keep building or copying and pasting every now and then is the enable button. Another one is the preview button.

While enable could be a straightforward approach, preview could require a more complex approach to be a usable feature. I can do a pull request.

_It would be appreciated if someone could guide me on conventions followed in such cases. Such as the controllers to be used etc. So whether to leave the controller half to dev to be implemented akin to the details view override._

[Athuli7]

I'm thinking something in lines of

enable.blade.php

@if($entry->enabled == 0)
    <a href="{{ Request::url().'/'.$entry->getKey() }}/enable" class="btn btn-xs btn-success @if($crud->hasAccess('enable')) @else disabled @endif "><i class="fa fa-plus-circle"></i> Enable</a>
@else
    <a href="{{ Request::url().'/'.$entry->getKey() }}/disable" class="btn btn-xs btn-danger @if($crud->hasAccess('disable')) @else disabled @endif "><i class="fa fa-minus-circle"></i> Disable</a>
@endif

CrudController Override

    public function enable($id)
    {
        $tempGeneric = Generic::find($id);
        $tempGeneric->enabled = 1;
        $tempGeneric->save();
        return back();
    }

    public function disable($id)
    {
        $tempGeneric = Generic::find($id);
        $tempGeneric->enabled = 0;
        $tempGeneric->save();
        return back();
    }

CrudRouter.php

        Route::get($this->name.'/{id}/enable', [
            'as' => 'crud.'.$this->name.'.enable',
            'uses' => $this->controller.'@enable',
        ]);

        Route::get($this->name.'/{id}/disable', [
            'as' => 'crud.'.$this->name.'.disable',
            'uses' => $this->controller.'@disable',
        ]);

I can make a PR if one of the project maintainers can approve of this.

[MickaelTH]

+1 each time I need to create a function in model and call it via model_function type. This could save lot of time.

[victorlap]

I dont think this is generic enough. For example what if the column is named active for some people or is translated in their own language?

[Athuli7]

@victorlap, we could just add it to the translate directives, akin to how other buttons are configured to support languages. And the method is overridden in the EntityCrudController to do the needful. If it is active, then they can change it there. The default action will have to be a call made by the developer.

All that being said, it would be nice to have a provision to pass more variables like the field options, but that would require major changes to how buttons are processed and consider the fact that a new version(major) is in the works, it may not the best idea to do it now.

[lloy0076]

Someone help me here, isn't there already functionality to add buttons that fairly much do anything one wishes to (within one's power - I really wish I could make a "Make Me Rich Now" button)?

I think there are two requests here:

• How does one make a button called, say, "enable"?
• Should a button that does what the OP's "enable" button be included in the actual project source?

[Athuli7]

@lloy0076, Why was Backpack created? or for that matter packages, composer etc. It is to be a bundle of commonly used tools and/or modules that can be rapidly reused. I've written a enable button into every project I've built. And yes, in many cases it is not binary. But a good majority are and my users want it. So, why not add it? btw it is not a question. It's an enhancement request.
Note: The CRUD logic is in my opinion incomplete without a enable/disable option.

[lloy0076]

I might be sounding a little short - apologies if that is the case - I need a "get rid of allergies/common colds" button in real life.

It strikes me that there are things that obviously are enabled and not, such as (and this is not a definitive list):

• Users
• Members
• Teams

But things where active / disabled / enabled may not make sense, e.g:

• Book details
• Television
• Floor colouring

This could be made more generic with a few extra "things" put on the model, e.g:

• canEnable() : boolean - if true then it can be enabled
• isEnabled() : boolean - figures out if the thing really is enabled (boolean, whatever, so long as the function returns a boolean)

...and that's not the only way to make it generic.

I think there might be a case for this functionality to move into the CRUD base but I'm not convinced that every single CRUD model would need it, even if it could be argued that a majority of the models might need it.

Anyway, PRs are welcome :)

[tabacitu]

Hi guys,

I've waited a bit to see what people have to say. Seems like comments have cooled down, so here's my opinion:

1. Totally agree about the "preview" button; it's something that most (if not all) CRUDs would benefit from, I agree; @AbbyJanke was working on something promising - see https://github.com/Laravel-Backpack/CRUD/issues/226, https://github.com/Laravel-Backpack/CRUD/issues/749, https://github.com/Laravel-Backpack/CRUD/pull/781, but it's a helluva lot of work :-) It's not just a button, the problem is "_how do we display every type of field, automatically, without developer input_"; but it's something I do believe we'll figure out and, once we do, it will be awesome :-) Feel free to pitch in, I expect to spend some considerable time on this in Sep and Oct, as I consider this a definite "Should have".

2. I find the enable button interesting, but I've never found that use case myself, so I'm skeptical that we should include it in CRUD, as I want to keep it as lean as possible. There are two paradigms when building packages (don't quote me on this, it's just my own theory :-) ):
   A) Start from minimal features and build customizations or extra features (this is where I hope Backpack will stay).
   B) Start from "all features included" and strip it down to only what you need (Wordpress + its plugins).

Granted, by definition of "minimal features" is odd (Backpack has by far the most features any admin panel on Laravel offers), but I do want to stop at some point :-) My worry is that including a niche button like this, which can be easily created, would mean Backpack making another small step towards the different building paradigm. Which is something I'm terrified of - both because I don't want Backpack to become something I wouldn't want to use AND because every feature we add, we have to document, support and maintain. Plus, we can't remove it without upsetting people. And it is _so so difficult_ to do everything already, with the resources we have with less than 1% of users actually paying for the software. So a rule of thumb for next features would be "_if it's not needed for every CRUD, it's not worth including in the main package_". I personally think the enable button fails this test, as I've built 20+ projects on Backpack and only needed something similar once. And indeed, I called it "activate", not "enable".

But I _do_ think we can (and should) ease the pain of recreating it every time. Creating a "Snippets" section on backpackforlaravel.com has been the plan all along - a place for the community to post things they find themselves reusing, but maintenance and feature development has been a priority so far, so zero work has been done on that. I expect we'll have a complete feature set in a few months, though, and I'll be able to work more on that side of things. I can't wait to build more places for the community to interact.

In the meantime, @Athuli7 , what do you think about creating a Gist, a Tutorial or both with the button, so that both you and other Backpack developers can quickly re-use it? Plus, a link from Backpack's website towards yours should help with SEO.

Cheers!

[Athuli7]

Snippets sound like a nice approach, but it would be lacking without a generator like cli option to rapidly include them into a project. And how they would work within the context the CrudController, ie, would it be extended or would it be routed specifically to the crud is the real question. Gist and Tutorial are too slow that people would opt to write from scratch.

The Wordpress analogy seems to bring about another query. If your concern is to keep backpack lean, why not have plugins? ie, work it out such that the enable option is an installable component. And yes, Activate sounds better.

[tabacitu]

Maybe snippets don't make sense for such a simple feature, yes. But for more complex ones i hope it might. More feedback is needed, i guess.

Plugins sound good, but i see plugins as standalone packages, not modifications to CRUD. For example, NewsCRUD, PermissionManager, BackupManager, i see all of those as plugins. Some use CRUD, some don't.

I considered having plugins for CRUD, but i think it requires a big refactoring and it has the downside of making things more difficult to understand for those that just want a one-off change. So the code would be easier to make plugins, but more difficult for those that don't make plugins. And i don't know how many plugins would make sense for CRUD anyway... Not saying it's out of the question, just making my train of thoughts public.

Sorry to hear you're not interested in creating a Gist or tutorial. I'll close this issue, but we can keep talking.

Cheers!

[b8ne]

+1 to a snippets section. Its pretty common that I will write a function that solves an issue, but simply do not have the time to create a full PR. It would be good to add what I have done and reference the relevant issue so that those who may have the time to create a PR can implement it.