Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefix Options #155

Closed
phillipmadsen opened this issue May 19, 2016 · 5 comments

Comments

Projects
None yet
2 participants
@phillipmadsen
Copy link
Contributor

commented May 19, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented May 21, 2016

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

This comment has been minimized.

Copy link
Member

commented May 21, 2016

@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 mitulgolakiya changed the title Tell me what you think Prefix Options May 21, 2016

mitulgolakiya added a commit that referenced this issue May 21, 2016

@mitulgolakiya

This comment has been minimized.

Copy link
Member

commented May 21, 2016

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

This comment has been minimized.

Copy link
Contributor Author

commented May 25, 2016

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 added a commit that referenced this issue May 29, 2016

@mitulgolakiya

This comment has been minimized.

Copy link
Member

commented May 29, 2016

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

mitulgolakiya added a commit that referenced this issue Jun 5, 2016

mitulgolakiya added a commit that referenced this issue Jun 5, 2016

@mitulgolakiya mitulgolakiya added completed and removed in-progress labels Jun 8, 2016

wtom pushed a commit to wtom/laravel-generator that referenced this issue Jul 20, 2016

wtom
Merge commit '4044c8c3e6c1b5541244b7117b0f7677ca7702bb' into create_u…
…pdate_relationships

* commit '4044c8c3e6c1b5541244b7117b0f7677ca7702bb': (32 commits)
  InfyOmLabs#102 patch route added
  =fixed route named prefix in controllers
  Applied fixes from StyleCI
  InfyOmLabs#194 fields not generated fix
  fixed instruction
  Applied fixes from StyleCI
  InfyOmLabs#155 diff routes when prefix is used
  Applied fixes from StyleCI
  InfyOmLabs#87 option to specify to generate only specific views
  InfyOmLabs#172 cli option to turn on/off datatables
  Applied fixes from StyleCI
  InfyOmLabs#179 InfyOmLabs#174 InfyOmLabs#166 AppBaseController uses prefix now
  InfyOmLabs#155 prefix fixes
  return Not Found HTTP CODE 404 to pass ApiTest
  update to seperate directories
  added instructions for using the new prefixes
  Updated to use prefixes
  Updated to use the new prefixes
  InfyOmLabs#166 InfyOmLabs#174 appbase controller fix
  rename ROUTES_AS_PREFIX to VIEW_PREFIX
  ...

wtom pushed a commit to wtom/laravel-generator that referenced this issue Jul 20, 2016

wtom
Merge commit '4044c8c3e6c1b5541244b7117b0f7677ca7702bb'
* commit '4044c8c3e6c1b5541244b7117b0f7677ca7702bb': (32 commits)
  InfyOmLabs#102 patch route added
  =fixed route named prefix in controllers
  Applied fixes from StyleCI
  InfyOmLabs#194 fields not generated fix
  fixed instruction
  Applied fixes from StyleCI
  InfyOmLabs#155 diff routes when prefix is used
  Applied fixes from StyleCI
  InfyOmLabs#87 option to specify to generate only specific views
  InfyOmLabs#172 cli option to turn on/off datatables
  Applied fixes from StyleCI
  InfyOmLabs#179 InfyOmLabs#174 InfyOmLabs#166 AppBaseController uses prefix now
  InfyOmLabs#155 prefix fixes
  return Not Found HTTP CODE 404 to pass ApiTest
  update to seperate directories
  added instructions for using the new prefixes
  Updated to use prefixes
  Updated to use the new prefixes
  InfyOmLabs#166 InfyOmLabs#174 appbase controller fix
  rename ROUTES_AS_PREFIX to VIEW_PREFIX
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.