Prefix Options

[phillipmadsen]

If we are using multiple prefix's on both new and old models we should probably figure out what items can be shared and what items need to be separate. So far I have one setup with the following but would like to know what you guys think.

Shared

• models
• repositories
• functions.php / helpers.php

  Not Shared

• controllers
• requests
• fields_file
• {prefixed}public/assets
• {prefixed}/layouts/*

I am starting to think It might help if we have 3 or 4 prefix options instead of 2 but i am still trying to work it out and have not been able to yet.

1- RoutePrefix 2- PathPrefix 3- ViewsPrefix maybe even a forth for 4- PublicPrefix

This way even if all of the prefixes are not used they can default to the main prefix: *prefix = admin would be all 4 unless otherwise specified. * then you could seperate all of the part into assignable options. example: for public you could have themes and can switch from one to another using this convention.

Or maybe have the layouts assigned in the controller so the route pulls the right views when directed. _example blog with layouts selected in controller:_

public function index(Request $request)
  {
    $tag = $request->get('tag');
    $data = $this->dispatch(new BlogIndexData($tag));
    $layout = $tag ? Tag::layout($tag) : 'blog.layouts.index';

    return view($layout, $data);
  }

  public function showPost($slug, Request $request)
  {
    $post = Post::with('tags')->whereSlug($slug)->firstOrFail();
    $tag = $request->get('tag');
    if ($tag) {
        $tag = Tag::whereTag($tag)->firstOrFail();
    }

    return view($post->layout, compact('post', 'tag'));
  }

As of right know that Is all I have been working on but by all means lets collaborate.

[phillipmadsen]

Prefix Concept

Ok i did some testing today trying to find out the most effective way to use prefixes for both backwards compatibility and new generation.

_My proposal is this:_

RoutePrefix PathPrefix ViewsPrefix PublicPrefix

Not only will these be very precise when building or converting exiting apps but it will also make it really hard for a hacker to get the hang of so will keep the app more secure. Not only that but it will also make it hard for someone with no laravel experience to mess up.

Now let me explain why.

lets say we have a basic blog and the normal routes would be something along the lines of

BLOG
    |- App
        |- Console
        |- Events
        |- Exceptions
        |- Helpers
        |- Http
            |- Controllers
                |- ADMIN:controllers  
                OR
                |- BACKEND:controllers  
            |- Middleware
            |- Requests
                |- ADMIN:Requests
                OR
                |- BACKEND:Requests
        |- Jobs
        |- Listeners
        |- Models
            |- ADMIN:models
            OR
            |- BACKEND:
        |- Policy
        |- Providers
        |- Repositories
        |- Services
    |- config
    |- database
    |- public
        |- ADMIN:ASSETS
            |- css
            |- js
            |- images
        OR
        |- BACKEND:
            |- css
            |- js
            |- images
        |- css
        |- js
        |- images
    |- resources
        |- lang
        |- assets
        |- views
            |- admin = ADMIN AREA
                    |- users
                    |- posts
                    OR
            |- backend = ADMIN AREA
                    |- users
                    |- posts
            |- users
            |- posts
    |- Storage

If you are familiar with laravel or any other framework they all have the same tree structures. This makes it very easy to learn and take advantage of. As you can see the main pathways, routes and everything else are essentially the same as the other. This makes it very easy to get into each one without much trouble just my knowing one you pretty much know them all.

This also means if you already have an app and its admin section let say is backend for files but not for the routes then you would have to redo all of the files in that directory, and not be able to use the generator.

But

With laravel you can have the same thing but with names of everything not alike and very hard to determine without having access to the filesystem itself. Here is what I propose.

Awesome Blog

{ RoutePrefix = ADMIN } { PathPrefix = BACKEND } { ViewsPrefix = SECURE } { PublicPrefix = ADMINLTE }

This would work out something like this:

Routes.php

Route::get('admin/users' [ 'as' => 'secure.users', 'uses' => 'Backend\UsersController@getIndex']);

App\Http\Controllers\Backend\UsersController.php

public function getIndex()
{
    $users = User::orderBy('created_at', 'DESC')->paginate(10);

    return view('secure.users.index', compact('users'))->with('active', 'user');
}

public/adminlte/layouts/app.blade.php

{!! asset('/adminlte/assets/css') !!}
{!! asset('/adminlte/assets/is') !!}
{!! asset('/adminlte/assets/images') !!}

SHARED ASSETS App\MODELS\User.php App\REPOSITORIES\UserRepository.php

As you can see it would be very hard to get to say the controller from the path in the assets or the route provided in the actions from the forms.

But like I said the best part is this leaves the backwards compatability to work in a already build app with the directories that are within it.

And

Say you didnt want to do all this and you are building new then all of them default back to the first prefix supplied or none at all.

QUICK EXAMPLE OF POSSIBILITIES

AWESOME APP
    |- App
        |- Console
        |- Events
        |- Exceptions
        |- Helpers
        |- Http
            |- Controllers
                |- UsersController
                    |- {PathPrefix = BACKEND }: index, show, edit, create, update, delete // using {PublicPrefix = ADMINLTE }:ASSETS
                    |- {PathPrefix = FRONTEND }: index, show // using {PublicPrefix = liveSite }:ASSETS
            |- Middleware
            |- Requests
                |- {PathPrefix = BACKEND }: index, show, edit, create, update, delete  // using {PublicPrefix = ADMINLTE }:ASSETS
                |- {PathPrefix = FRONTEND }: index, show // using {PublicPrefix = liveSite }:ASSETS
        |- Jobs
        |- Listeners
        |- Models
            |- uSER:Shared
        |- Policy
        |- Providers
        |- Repositories
            |- uSER:Shared
        |- Services
    |- config
    |- database
    |- public
        |- {PublicPrefix = ADMINLTE }:ASSETS
            |- css
            |- js
            |- images
        |- {PublicPrefix = LIVESITE }:ASSETS
            |- css
            |- js
            |- images
    |- resources
        |- lang
        |- assets
        |- views
            |- {ViewsPrefix = SECURE } = ADMIN AREA
                    |- users  // using {PublicPrefix = ADMINLTE }:ASSETS
                    |- posts  // using {PublicPrefix = ADMINLTE }:ASSETS
            |- users // using {PublicPrefix = liveSite }:ASSETS
            |- posts// using {PublicPrefix = liveSite }:ASSETS
    |- Storage

[mitulgolakiya]

@phillipmadsen I like the idea and will start working on it. But as of now, we are not using public prefix anywhere because we are directly referencing CDN in adminlte and bootstrap templates. But in next 2 weeks, I am going to push some more templates of some popular themes like metronic, flatlab, chandra and as these are paid themes. so a user who purchased it needs to put it at the right place and configure it to work. so then we will implement public prefix.

[mitulgolakiya]

I have done one commit for initial support of 4 prefix options as mentioned above.

Also, I have added a support for multiple/nested prefix support like. --prefix=backend,admin. so it will generate something like following,

Namespace: App\Http\Controllers\Backend\Admin Path: app/Http/Controllers/Backend/Admin views: resources/views/backend/admin routes: backend.admin

Still I haven't done a full testing. so will do a testing and will push it soon.

[phillipmadsen]

Great ides, i love it. I just started playing with your dev branch and am getting some errors ill list them just in case you might be working on it.

ran php artisan infyom:api_scaffold Product --fieldsFile='resources/model_schemas/Product.json' returned

  [ErrorException]
  Undefined index: ns

[mitulgolakiya]

@phillipmadsen I have pushed a fix for it. Check again.