Miscellaneous code snippets + documentation extension

[kdv88]

A place to gather miscellaneous code snippets which can help new users start out, or a place to learn some neat tricks.
These suggestions are merely to get up to speed. Some people learn by reading code, some people learn by seeing examples, etc.

Perhaps the best suggestions/examples can eventually be merged in to the documentation.

Also a random list of stuff what is "missing" (as missing is rather subjective):

• GitHub repo with more advanced examples, to get your quickstart.... quicker?
  • Using rules() validation with the createOrUpdate()-method
• ...

[kdv88]

As a first code example. I have a LayoutList and within the LayouList I have the TD-objects in an array. Is there a way I can have 1 column with multiple buttons?

Answer: The Group also has a render()-method.

TD::make('options', trans('admin.options') )
            ->width(240)
                ->render( function(Project $project) {
                    return
                        Group::make([
                            Link::make(__('admin.crud.show'))
                            ->icon('magnifier')
                            ->route('platform.projects.show', $project->id),

                            Link::make(__('admin.crud.edit'))
                            ->icon('pencil')
                            ->route('platform.projects.edit', $project->id)
                        ])->render();
                }),

[kdv88]

I am not sure if I really like this solution yet, but the intention was a mimic of the Laravel Route::resource().

Usage: Route::screenresource('projects', "\App\Orchid\Screens\Admin\Project\Project" );

<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Route;

class ScreenResourceProvider extends ServiceProvider
{
    /**
     * Register services.
     *
     * @return void
     */
    public function register()
    {
        Route::macro('screenresource', function( $url, $className ) {
            Route::screen( $url . '/create'             , "{$className}EditScreen")->name('platform.'.$url.'.create');
            Route::screen( $url . '/index'              , "{$className}ListScreen")->name('platform.'.$url.'.index');
            Route::screen( $url . '/{project}/show'     , "{$className}ShowScreen")->name('platform.'.$url.'.show');
            Route::screen( $url . '/{project}/edit'     , "{$className}EditScreen")->name('platform.'.$url.'.edit');
        });
    }

    /**
     * Bootstrap services.
     *
     * @return void
     */
    public function boot()
    {
        //
    }
}

[bilogic]

Just thinking out loud, is ::screenresource or ::resourcescreen/::resourceWithScreen better?
Someone coming from Laravel will understand ::resource(), appending might make it easier to related/understand.

[bilogic]

How about adding permissions? e.g. read-only vs all permissions. I think this is a very common use case for web applications (Notice how I intentionally avoid the words "ad*** pa***" 😂)

[kdv88]

Just thinking out loud, is ::screenresource or ::resourcescreen/::resourceWithScreen better?
Someone coming from Laravel will understand ::resource(), appending might make it easier to related/understand.

Perhaps then I would go with resourcescreen, as that feels more "natural" to me. (In fact, I was wondering at the time if I should call it screenresource or resourcescreen 😂 ).

How about adding permissions? e.g. read-only vs all permissions. I think this is a very common use case for web applications (Notice how I intentionally avoid the words "ad*** pa***" 😂)

Yes, sounds reasonable. For now the current form fits my specific use case, but it is something to look in to.

[tabuna]

Hi guys. I added a recipes section to the site where you can publish your solution. (To date, very early stage)
Let's fill it in instead. I've added some examples.

[bilogic]

Has this been released to packagist?
I get 404 when loading /en/recipes/how-to-re-use-layers/

[bilogic]

May I suggest having examples in a separate package?

1. It will also make easy for new comers to start and study and won't get in the way of experienced developers
2. After they are done studying, they can easily remove the example package to clean things up
3. The package approach will address the --examples Add install orchid without examples #1343
4. It also shows developers how to build packages instead of building directly into Laravel (Easier to update to new Laravel versions)

I also have several proposals about architecture/function name changes to follow the Laravel way more closely. But I'm not sure if it will pose any concerns. See:

1. Simpler and shorter listener code #1623
2. Changing App\Orchid namespace for packages #1620
3. Permissions in a file #1523 (reply in thread)
4. canSee(...) -> visibleIf(...), create an alias function to be more fluent
5. defaultHidden(...) -> hide(...)
6. cantHide(...) -> preventHide(...)

How do I go about proposing them? Thank you.

[bilogic]

Recipes can be found here https://orchid.software/en/recipes/

[bilogic]

Hi all, I have released my example package to demonstrate what I suggested earlier.
Use composer require bilogic/orchidexamples to install and have a look. Thank you.