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

Unique pages #61

Open
wants to merge 22 commits into
base: main
Choose a base branch
from
Open

Unique pages #61

wants to merge 22 commits into from

Conversation

OliverZiegler
Copy link
Contributor

This is a first implementation for issue #60.

Copy link
Contributor

@lloy0076 lloy0076 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are various PHP Docs missing, either completely absent or returns missing.

This getTemplaes and getUniquePages could probably just return a collection to avoid the (ugly) use of collect(...) all the time.

And in fact we could even avoid the various functional mapWithKeys etc by adding more semantic names in the trait.

(Yeah, functional programming is great but in the upper level clases it's nicer to see $this->getUniqueSlugs() vs collect($this->getSlugs()->mapWithKey()->foo()->bar())

README.md Outdated
`< route_prefix >/unique/< page_function_slug >`

For users to access the editing page for the page `about_us` you could add a menu item like so:
(remember the url will use the slug of your function)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Colon at end.

README.md Outdated
@@ -52,6 +52,27 @@ php artisan migrate
1. Go to **yourapp/admin/page** and see how it works.
2. Define your own templates in app/PageTemplates.php using the Backpack\CRUD API.

## Unique pages usage

Unique pages are pages that exist only once. You can not create a second instance nor delete the current one.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NL at end.

@@ -27,6 +31,8 @@ public function setup($template_name = false)
$this->crud->setRoute(config('backpack.base.route_prefix').'/page');
$this->crud->setEntityNameStrings(trans('backpack::pagemanager.page'), trans('backpack::pagemanager.pages'));

$template_names = collect($this->getTemplates())->pluck('name');
$this->crud->addClause('whereIn', 'template', $template_names);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NL after.

@@ -27,6 +31,8 @@ public function setup($template_name = false)
$this->crud->setRoute(config('backpack.base.route_prefix').'/page');
$this->crud->setEntityNameStrings(trans('backpack::pagemanager.page'), trans('backpack::pagemanager.pages'));

$template_names = collect($this->getTemplates())->pluck('name');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose we're stuck with this colllect(...) here.

It would read better as $this->getTemplateNames() though.

|--------------------------------------------------------------------------
*/
$this->crud->setModel($modelClass);
// don't set route or entity names here. these depend on the page you are editing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't set route or entity names here. These depend on the page you are editing.

}

/**
* Get all defined templates.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No @return.

| Unique pages for Backpack\PageManager
|--------------------------------------------------------------------------
|
| Each unique page has its own method, that define what fields should show up using the Backpack\CRUD API.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No comma here!

|--------------------------------------------------------------------------
|
| Each unique page has its own method, that define what fields should show up using the Backpack\CRUD API.
| Use snake_case for naming and PageManager will generate the page on first edit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eh? What if it's not snake_case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also a convention I just copied from default page templates behaviour.

| Use snake_case for naming and PageManager will generate the page on first edit
|
| Any fields defined here will show up after the standard page fields:
| - select template (hidden and fix)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "(hidden and fix)" mean?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improved the comment


// Change this class if you wish to extend the Page model
'page_model_class' => 'Backpack\PageManager\app\Models\Page',
'page_model_class' => 'Backpack\PageManager\app\Models\Page',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are going to have this, will it work for the other (non-unique) page class thingos?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I improved the comment. You need to set both config values 'page_model_class' and 'unique_page_model_class' if you want to use the same (overridden) model.

@OliverZiegler
Copy link
Contributor Author

@lloy0076 i fixed your review remarks. Would you review the changes please? 😊


public function setup()
{
parent::__construct();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the constructor called from setup?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point... this was just a copy&paste from the original controller...

$this->crud->setModel($modelClass);
// Don't set route or entity names here. These depend on the page you are editing

// unique pages cannot be created nor deleted
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or listed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually what is the point of this comment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wanted to inform why we deny this access...
what do you think? remove the comment entirely?

}

/**
* Create the page by slug.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the function name are slightly out of sync don't we think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is why I don't linke comments... function name says it all.. will fix

}

/**
* Override trait version to not update the session variable.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forget why?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have no "save actions" here and overwrite with save_and_back.
This would geht default for this session in all Crud-Views.
As we don't want to overwrite behaviour when user can't choose, we need this (empty) implementation

Copy link
Contributor Author

@OliverZiegler OliverZiegler Apr 24, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added some more comment to make this clear ;)

*
* As the method name of a unique page will also be the template name in the database,
* we must ensure that there are not any equal names defined.
* If different Models (and so different tables in the database) are used, this condition must not hold any more.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

must not hold vs may not hold? They're different?

@OliverZiegler
Copy link
Contributor Author

Ready for (final?) review :)

@OliverZiegler
Copy link
Contributor Author

@lloy0076 would you please review the current version?

Copy link
Contributor

@lloy0076 lloy0076 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

app/ seems to be getting cluttered up with stuff here...is that really the best thing to do?

e.g. app\UniquePages.php (which is a trait?)

@OliverZiegler
Copy link
Contributor Author

@lloy0076 well this is consistent with the previous stuff.. so I think it's currently ok.
I'm working on an all new pagemanager with a more class based approach an especially artisan commands for creating and removing pages. For now I think we should sty with the current implementation.

@tabacitu
Copy link
Member

Hi @OliverZiegler ,

As I recently said in issue #60 - I totally agree with the feature, but I'm wondering if this is the best way to do it.

(1) The way I see it, since there is only one pages table, there should only be one Pages model - it doesn't really make sense to me to have Pages and UniquePages. This makes it much more difficult for developers to understand how this package works, and I think that's important because this is a package that most people end up changing / customizing / hacking at. Plus, if you put revisions on UniquePages, you probably want them on regular pages too, right? Because they're just one thing - pages. I think the distinction is artificial and maybe we should rethink this a little bit.

(2) Also, I think the two new restrictions that are imposed to pages would be better of as separate restrictions. For example, in my designs the home page looks A LOT like a landing page. So I usually let clients create new pages, that look just like the homepage, as landing pages. This is particularly useful to target different audiences, and point AdWords campaigns towards different landing pages, instead of homepage. They can then tailor those landing pages to that audience's specific needs => better conversion.

--

To achieve the above (which I think is the same need you have, and that this PR treats), for me as a developer, it would be easier to understand if I just have some new properties inside the PageTemplates trait, where I define which of the page templates are non-deletable, and which of the page templates can only have one entry, etc. So just have some properties there that impose some restrictions, instead of having a different Model where I define other "type" of page templates, which are actually "types" of pages :-)

So for a PageTemplates.php file that looked like this (no unique or mandatory pages):

<?php

namespace App;

trait PageTemplates
{
    /*
    |--------------------------------------------------------------------------
    | Page Templates for Backpack\PageManager
    |--------------------------------------------------------------------------
    |
    | Each page template has its own method, that define what fields should show up using the Backpack\CRUD API.
    | Use snake_case for naming and PageManager will make sure it looks pretty in the create/update form
    | template dropdown.
    |
    | Any fields defined here will show up after the standard page fields:
    | - select template
    | - page name (only seen by admins)
    | - page title
    | - page slug
    */

    private function services() {} // includes multiple addField statements, etc
    private function about_us() {} // includes multiple addField statements, etc
    private function home_page()  {} // includes multiple addField statements, etc
    private function contact() {} // includes multiple addField statements, etc
    private function landing_page()  {} // includes multiple addField statements, etc
}

The only difference, for the developer, to adopt this new feature could be to add a few new properties in PageTemplates.php:

<?php

namespace App;

trait PageTemplates
{
    /*
    |--------------------------------------------------------------------------
    | Page Templates for Backpack\PageManager
    |--------------------------------------------------------------------------
    |
    | Each page template has its own method, that define what fields should show up using the Backpack\CRUD API.
    | Use snake_case for naming and PageManager will make sure it looks pretty in the create/update form
    | template dropdown.
    |
    | Any fields defined here will show up after the standard page fields:
    | - select template
    | - page name (only seen by admins)
    | - page title
    | - page slug
    */

+   $templatesThatCannotBeAdded = ['contact']; // will not show up as options when creating new pages
+   $templatesThatCannotBeDeleted = ['home_page', 'contact']; // entries using these templates will not have a Delete button
+   $entriesThatCannotBeDeleted = [1, 5]; // these entries will not have a Delete button
+   $entriesWhereTheSlugCannotBeEdited = [1]; // the slug will be readonly

    private function services() {} // includes multiple addField statements, etc
    private function about_us() {} // includes multiple addField statements, etc
    private function home_page()  {} // includes multiple addField statements, etc
    private function contact() {} // includes multiple addField statements, etc
    private function landing_page()  {} // includes multiple addField statements, etc
}

Then all of the restrictions above could be done in the PageCrudController::setup() and maybe PageCrudController::search().

What do you think about this different way of doing things @OliverZiegler ? Better? Worse? Or just different? :-)

Thanks, cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants