-
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
@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 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. |
What I have in mind is a variation of C, where the Location package has views for:
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 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. |
Change flag name and simplify redirect logic #79
The Blog controller should accept routes for Pages (#15) that are parent Pages and have child Pages and grandchild Pages.
The text was updated successfully, but these errors were encountered: