{"action":"created","issue":{"url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/5844","repository_url":"https://api.github.com/repos/silverstripe/silverstripe-framework","labels_url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/5844/labels{/name}","comments_url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/5844/comments","events_url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/5844/events","html_url":"https://github.com/silverstripe/silverstripe-framework/issues/5844","id":167972723,"number":5844,"title":"RFC: Namespace of Page","user":{"login":"sminnee","id":59968,"avatar_url":"https://avatars.githubusercontent.com/u/59968?v=3","gravatar_id":"","url":"https://api.github.com/users/sminnee","html_url":"https://github.com/sminnee","followers_url":"https://api.github.com/users/sminnee/followers","following_url":"https://api.github.com/users/sminnee/following{/other_user}","gists_url":"https://api.github.com/users/sminnee/gists{/gist_id}","starred_url":"https://api.github.com/users/sminnee/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sminnee/subscriptions","organizations_url":"https://api.github.com/users/sminnee/orgs","repos_url":"https://api.github.com/users/sminnee/repos","events_url":"https://api.github.com/users/sminnee/events{/privacy}","received_events_url":"https://api.github.com/users/sminnee/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-07-27T22:34:26Z","updated_at":"2016-07-27T23:41:05Z","closed_at":null,"body":"In SS4 we're introducing namespaces to all classes. However, for the `Page` class, this presents an issue.\r\n\r\nThe `Page` class is supplied by a project developer as part of their application. \r\n\r\n```php\r\nclass BlogPage extends Page {\r\n}\r\n```\r\n\r\nThe blog module needs to know what namespace Page sits in. But what namespace will developer put their project code into? Generally speaking, code should be placed into a globally unique namespace, which means that there will be no single namespace within which Page sits.\r\n\r\n### Alternative 1\r\n\r\nThanks to Hamish for this trick: we can use `class_alias()` to dynamic populate the namespace `__App` with the correct namespace:\r\n\r\n```php\r\nclass BlogPage extends \\__App\\Page {\r\n}\r\n```\r\n\r\nThen in our _config.php or similar, we can have a configuration option:\r\n\r\n```php\r\nset_app_namespace('Sminnee\\\\PersonalHomepage');\r\n```\r\n\r\nAs a style-guide point, `__App` should only be used in module that need to extend the Page class.\r\n\r\n[A proof-of-concept is available here](https://gist.github.com/hafriedlander/908b5ee405e70da4c4cb89bfc828bb8b)\r\n\r\n### Alternative 2\r\n\r\n**Include the same magic, but run it on `SSApp` rather than `__App` and use that as the default project namespace**\r\n\r\nThis will mean that the magic is only needed when users shift away from the default namespace, which might only occur in special cases (like people building project/library combos). This may give us the best of both worlds, but it also makes it less clear that SSApp will *sometimes* be magically populated.\r\n\r\nNote that I've suggested `SSApp` over `App` to avoid conflicting with, e.g. Laravel. It's conceivable that you build a project that incorporates both SilverStripe and Laravel components.\r\n\r\n### Alternative 3\r\n\r\nThe same as alternative 2, but with App instead of SSApp :-)\r\n\r\n### Other alternatives\r\n\r\n * **Leave `Page` unnamespaced** This would be less of a change, but it seems out of keeping with the rest of changes to namespaces being made in SS4.\r\n * **Use a hard-coded `SSApp\\Page` namespace** Simpler, but it forces people to bake in assumptions about whether a piece of code is in a project or a library. Since a lot of code starts out as a standalone project and then becomes a library over time, this seems awkward (e.g. a CLI tool that you then want to include as a library into a project as an alternative)\r\n * **Perform code generation on any module that subclasses Page to pick the right namespace** This would be a triumph of cleverness over practicality.\r\n * **Move away from subclasses of Page as way of creating page type in modules** ...might be the best long term solution, but more of an SS5 thing. It will be pervasive and distracting and we don't have time for it."},"comment":{"url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/comments/235754595","html_url":"https://github.com/silverstripe/silverstripe-framework/issues/5844#issuecomment-235754595","issue_url":"https://api.github.com/repos/silverstripe/silverstripe-framework/issues/5844","id":235754595,"user":{"login":"patricknelson","id":4269377,"avatar_url":"https://avatars.githubusercontent.com/u/4269377?v=3","gravatar_id":"","url":"https://api.github.com/users/patricknelson","html_url":"https://github.com/patricknelson","followers_url":"https://api.github.com/users/patricknelson/followers","following_url":"https://api.github.com/users/patricknelson/following{/other_user}","gists_url":"https://api.github.com/users/patricknelson/gists{/gist_id}","starred_url":"https://api.github.com/users/patricknelson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/patricknelson/subscriptions","organizations_url":"https://api.github.com/users/patricknelson/orgs","repos_url":"https://api.github.com/users/patricknelson/repos","events_url":"https://api.github.com/users/patricknelson/events{/privacy}","received_events_url":"https://api.github.com/users/patricknelson/received_events","type":"User","site_admin":false},"created_at":"2016-07-27T23:41:04Z","updated_at":"2016-07-27T23:41:04Z","body":"Speaking of smooth upgrade paths :) Isn't `Page` a special case, as it's by default installed into the `mysite/code/` directory? That being the case, why do anything here? It's in the global namespace, always is and why can't it continue to be? \r\n\r\nPut it this way -- most cases it shouldn't cause conflict. If/when it does, SS 4.0 should be _capable_ of being extensible enough to define the fully qualified class name for `Page` in case it doesn't exist at `\\Page`. e.g. Default to `\\Page` (good for backward compat but also just ease of use) and allow users to define the location of the base `Page` in their own way. \r\n\r\nThis helps prevent constraining just to `Page` as the base class name, if necessary. Heck, even an external out-of-date module could depend on `\\Page` when your main `Page` instance is actually `\\MySite\\MyPage` and, if that's the case, you could also just setup another PHP class in global namespace `Page extends MySite\\MyPage` and fix the module easily. No?"}}
{"actor":{"display_login":"patricknelson"}}