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

Partial Page Routes #79

Open
drewroberts opened this issue Apr 13, 2021 · 2 comments
Open

Partial Page Routes #79

drewroberts opened this issue Apr 13, 2021 · 2 comments
Assignees

Comments

@drewroberts
Copy link
Owner

The Blog controller should accept routes for Pages (#15) that are parent Pages and have child Pages and grandchild Pages.

drewroberts added a commit that referenced this issue Apr 14, 2021
Update BlogController and PageController logic for #79 and #80
@pdbreen
Copy link
Collaborator

pdbreen commented Apr 14, 2021

@drewroberts - I think there may still be issues between what you're trying to achieve and how you're trying to achieve it within the blog package. Consider the scenario of a single market ('orlando') with a single location ('downtown'). The recent changes will cause /orlando/downtown to redirect to /orlando - (pretty sure this part is correct). But, now the first question is - what should be rendered?

A) Is the resulting page truly a completely static page that is not location aware, something that can be handled by the PageController and one of the page views (with no access to market model or location model)? If it is truly static, should the content be pulled from the "orlando" page model or the "downtown" page model?

B) Or, is the result a more of a functional page that should be handled by a MarketController and view specific to handling a market page with access to both the market model and location models (in addition to the pages that they link to)?

If its B, then all of this special routing within the blogs package isn't necessary. Instead, there needs to be a change to some solution that can support fallback style routing across multiple packages so any unmatched url can be tested (in some priority ordering) across multiple packages to determine which controller / view should actually handle it. (Not exactly sure how this would be solved without some experimentation)

C) Or, is your expectation that the location package create/register new layouts for market page and location page and attach those layouts to the pages associated with market and location? If yes, this would require these views to depend on view composers (within the location package) to more or less fill the role a controller typically fills - gathering and passing the additional models and data the view requires for rendering.

If its C, I think this might work, but its a very unusual approach for route handling within laravel - the blog package is handling the route with the PageController, but rendering a view from the locations package with data provided by a combination of a view composer in the location package and the page model from the blog package. This could be difficult for others to understand and maintain in the future.

@drewroberts
Copy link
Owner Author

What I have in mind is a variation of C, where the Location package has views for:

  • locations::page.markets.amp
  • locations::page.markets.base
  • locations::page.locations.amp
  • locations::page.locations.base

These are added in a migration:

class AddLocationLayouts extends Migration
{
    public function up()
    {
        foreach ([
            [
                'name'          => 'Base Location Page',
                'layout_type'   => LayoutType::PAGE,
                'view'          => 'locations::page.location.base',
                'note'          => 'Location Base HTML Structure',
                'created_at'    => '2021-04-09 10:00:00',
                'updated_at'    => '2021-04-09 10:00:00',
            ]
        ] as $layout) {
            Layout::firstOrCreate($layout);
        }
    }
}

These Layouts would not need any Controller data passed to them, because they will only be for Pages that have a Location and will simply get the data through $page->location->title and using that relationship chain.

It is an unusual way to do layouts, but it allows the creation of those Layout files to stay in the package for the resource. Let me know if this direction would work and if there is anything I might be overlooking or any potential "gotchas" with it.

drewroberts added a commit that referenced this issue Apr 14, 2021
Change flag name and simplify redirect logic #79
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants