Making better use of namespaces

[Sam Minnée]

So, if we don't need to support PHP 5.2, we can make use of namespaces.  There are a few issues to work through.  Here are the ones that I can think of:

1) Backwards compatibility.

Let's assume that we move DataObject to silverstripe\framework\model\DataObject

A user's codebase might contain this:

class MyClass extends DataObject {

}

By default DataObject won't be discovered.  However, if we call class_alias("silverstripe\\framework\\model\\DataObject", "DataObject") in our autoloader, then this can be preserved.  This will mean that we'd still need a manifest, but it gives us a big backward compatibility boost.

I'm pretty convinced that we *need* this feature in SS3.  However, should we deprecate this usage, or do we consider it an enlightened way of getting the best of both worlds: the reliability of namespaces with the conciseness of direct class names.  Forcing the inclusion of "use" statements in every PHP file makes things more verbose, and I'd be inclined to benefit from the fact that we have a manifest.  Perhaps we try getting use statements into things and see who much more verbose it makes code (if you're mostly referring to classes from the same namespace - a sign of low coupling - maybe it won't be such a big deal)

2) PSR-0 compliance

PSR-0 is a standard mapping between namespaces and filenames:

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

It seems like a good move to get our code using this, although it's not strictly necessary, given that we have the manifest.  However, moving towards PSR-0 means that the manifest could become less important, and there might be opportunities for performance enhancement here.

For classes that currently contain underscores, we could either rename the class (see (3) below) or move the class into a subfolder.  Personally, I'd rather go for the former.

3) Dealing with renamed classes

With a bit of code in our autoloader, we could deal with renamed classes (DataObjectSet -> ArrayList, FieldSet -> FieldList, etc) more elegantly than currently: we can maintain a list of class renames and make an appropriate class_alias() call in the autoloader.  These should probably throw deprecation errors, but the code will work.

We could even use a /** @oldClassName **/ annotation to define this.  It would be way of easing annotations into the framework in a place where only advanced users are going to need to deal with them.

4) What are our base namespaces?

I would suggest that we use the following for our base namespaces:

silverstripe\framework

silverstripe\cms

Beyond that, our current folder structure can guide us:

silverstripe\framework\model

silverstripe\framework\control

silverstripe\framework\view

silverstripe\framework\admin

[Sam Minnée]

OK, I remembered some other important ones:

5) Table names

The "Member" class corresponds to the "Member" table right now.  Nice and simple, but what happens when the member class becomes silverstripe\framework\security\Member?  I really don't think that calling the table silverstripe\framework\security\Member or "silverstripe_framework_security_Member" is a good idea - it's way to long and generally makes interacting with the database horrible.

My inclination, for backward compatibility, would be to call the table "Member".  But then what happens when I create "samminnee\model\Member"?  Perhaps, in this case, we need to have a project-specific mapping of classes to tablenames.  The default is to use the unqualified classname as the table name, but we might change this in the case of a conflict.  Perhaps the config system can help here?

6) Reference to class names in URLs.

Very often we end up making reference to a classname in a URL.  Do we reference unqualified classnames, or do we move to some other indication of classname?  Putting \ into a URL seems nasty; should we choose another character as a delimiter?  Maybe a ":"?

7) ClassName field in tables.

Should this be unqualified or qualified?  If we put fully qualified classnames in then we're going to get a lot of backward-compat issues, although, presumably this would only happen when people add namespaces to their code so it might be okay.

If we make the ClassName field contain fully qualified classnames, we should probably have something in dev/build that will migrate unqualified data over.

Is a "\" an okay character to include in a field value?  I don't see any major problem there, so we should probably stick with it.

[Sam Minnée]

8) Manifest class tree creation

There's no real decision to be made here, except that we need to acknowledge that as soon as you start using "use" or "class_alias", the current manifest class tree generator is going to break.  A moderately difficult piece of coding will be needed to fix that, and we'll probably still need to make some assumptions about which class_alias() commands are being called.

[Simon J Welsh]

A quick overview of how the current namespace support works:

You can namespace your classes fine. The manifest picks them up and loads them. There are some caveats around the extend/implements clauses where use statements aren't applied so they must contain the fully qualified name otherwise the current namespace is prepended. There's also only support for the namespace name\space; declaration (so no namespace blocks and only one namespace per file).

An example table for a DataObject looks something like:
CREATE TABLE `rentbox\Repeats\Repeat` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`ClassName` enum('rentbox\\Repeats\\Repeat','rentbox\\Repeats\\Daily','rentbox\\Repeats\\Monthly','rentbox\\Repeats\\Weekly') CHARACTER SET utf8 DEFAULT 'rentbox\\Repeats\\Repeat',
`Created` datetime DEFAULT NULL,
`LastEdited` datetime DEFAULT NULL,
`Repeat` int(11) NOT NULL DEFAULT '0',
`Stop` datetime DEFAULT NULL,
`Stops` tinyint(1) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`ID`),
KEY `ClassName` (`ClassName`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Controllers can still be accessed by passing the fully qualified name to the URL, though this looks bad. Templates are also currently looked up using the fully qualified name, then falling back to just the class name (so rendering rentbox\Repeats\Repeat would look for rentbox\Repeats\Repeat.ss then Repeat.ss). This doesn't work too well on Windows, so that will need to be addressed too (say replacing every T_NS_SEPARATOR with a hyphen). Support for the backslash in table names and enum values may also be database dependant, so, if the fully qualified name is used, those will also need to be handled better.

I do believe that using fully qualified names for tables gets unwieldily (see http://s.geek.nz/p/2J for a small example), though I don't know how to get around that especially when class names collide. We can't even use only part of the fully qualified name, as there can still be collisions (i.e. rentbox\BodyCorp\Photo and rentbox\inspection\Photo will collide if we choose class name and project name). Whatever we go with, there will also need to be something similar to the class_alias() calls so that current queries with qualified column names still work.

I'm against going for a PSR-0 compliant autoloader. While there is a push for it to become a defacto standard, it also enforces a particular folder structure, so our autoloader would need to pop off silverstripe and then, if there's no matching folder for the next segment of the namespace, check for a {SEGMENT}_DIR constant and then look in that folder instead. Since we're going to need the manifest anyway (existing classes, namespaced classes that don't follow PSR-0, inheritance forest, etc) PSR-0 doesn't seem that useful.
---
Simon Welsh
Admin of http://simon.geek.nz/

[Sam Minnée]

On 27/03/2012, at 2:17 PM, Simon J Welsh <welsh...@gmail.com> wrote:

> I do believe that using fully qualified names for tables gets unwieldily (see http://s.geek.nz/p/2J for a small example), though I don't know how to get around that especially when class names collide. We can't even use only part of the fully qualified name, as there can still be collisions (i.e. rentbox\BodyCorp\Photo and rentbox\inspection\Photo will collide if we choose class name and project name). Whatever we go with, there will also need to be something similar to the class_alias() calls so that current queries with qualified column names still work.

I was thinking that DataObject could have a table_name option, that defaults to the unqualified name, and could be either set in the class definition or overridden in project-wide config if necessary (eg if you pulled two modules with conflicting table names into a project)

[Ed Chipman]

Sam,

I'm happy to see that SilverStripe is dropping support for php 5.2.x, I'm curious as to the decision of namespacing things. I agree that it is a really good idea, I'm just wondering if it is the right timing given that SilverStripe 3.0 is in beta. I'm concerned that given the scope of this change that it maybe a bit too significant for 3.0, I'm wondering if it makes sense to do this for 3.0 or to put it off to 3.1. Which would not only give the community more of a chance to get used to the current 3.0 architecture changes before adding in namespacing. But it would also give the 3.0 architecture more time to become as rock solid as possible prior to the release of 3.0. Which no doubt will still happen regardless of this change or not, I'm just thinking a big change like this could delay the release of 3.0.

Unno my 2 cents on it, not saying its a bad thing... just worried about the timing that's all ;)
------
Keelah se'lai
Ed Chipman
http://www.edchipman.ca

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Sam Minnée]

The problem is that we can't really include it in 3.1 either - so if we weren't to do it now, we'd need to leave it until 4.0, in which case there wouldn't be much point in dropping 5.2 support in 3.0. Although we could take that approach, it didn't really seem to be what most people wanted.

I agree that we should have really done this before beta1, but the idea is to get it in before beta2 so that we still have a decent testing window, and to minimise the backward compatibility issues.

[Sam Minnée]

OK, so here's a quick update on my progress with namespace introduction:

1) The work in progress is here - https://github.com/sminnee/sapphire/commits/introduce-namespaces - but please let me know if you fetch this branch yourself to work on, otherwise i'll keep rebasing it.  You can run dev/build, log in, and open the CMS, but there are plenty of test failures, mostly to do with table_name.

2) The auto-loader has a number of helpers.  I'm not sure which of these we should deprecate:

   - If you don't specify a namespace and go "extends DataObject", it will look up the DataObject for you and alias silverstripe\framework\model\DataObject to DataObject.  This means that code that isn't namespace-aware will keep working.

   - If you do specify a namespace (e.g mycompany\myproj) go "extends DataObject", it will look up a DataObject from the correct namespace, and alias silverstripe\framework\model\DataObject to mycompany\myproj\DataObject.

The former of these seems okay to keep around, the second seems like it should be avoided.

3) DataObject has table_name option now, which defaults to the namespace-free name of the class.  Also:

 - many-many tables are generated based on the table name, rather than the class name

 - classnames referenced in relationship definitions can choose to include the namespace or not.  i'm not sure if we want to deprecate the namespace-free syntax, and/or default to using the namespace of the class on which the relationship is defined as the default.

 - the fields generated in many-many tables are based on the unqualified classname rather than the fully qualified one.

4) Controllers will, by default, look for templates named the same as the unqualified classname.  I don't know if this is the best approach, but the implementation of this is pretty small.  Big long filenames don't strike me as an improvement in any way, but perhaps there could be a notion of namespacing templates?

5) One piece of good news is that I've managed to do this without any changes to the cms module whatsoever.  This is going to be my goal for ensuring backward compatibility.

6) The main thing that does need a lot of search & replace correction within the framework itself is where classnames are interrogated in a string - for example by seeing if get_parent_class(get_class($this)) == "DataObject" to identify if something is a base class.

STILL TO DO

 - Fix bugs with the table_name change.

 - Improve class selection in relationship definition

 - Improve template naming

 - Deprecate appropriate class-lookup strategies.

[Andrew Short]

Just one quick thing - I think we should use UpperCamelCase for namespaces. This follows our existing class name conventions and fits in with Zend/Symfony etc coding conventions. 

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/2yUZLMNF2LoJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--
Andrew Short.

[Sam Minnée]

On 29/03/2012, at 2:13 PM, Andrew Short wrote:

> Just one quick thing - I think we should use UpperCamelCase for namespaces. This follows our existing class name conventions and fits in with Zend/Symfony etc coding conventions.

OK, I guess that means we should rename folders too.

[Marcus Nyeholt]

Yeah, it looks like PSR-0 specifies keeping directory name case in line with the namespace case

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

[Sam Minnée]

On 29/03/2012, at 2:13 PM, Andrew Short wrote:

Just one quick thing - I think we should use UpperCamelCase for namespaces. This follows our existing class name conventions and fits in with Zend/Symfony etc coding conventions. 

This raises the question of what the namespaces should be.  One question is whether we include "framework" in the namespace, or whether we take "framework" as read and leave it out of the namespace.  Hamish was a fan of this:

SilverStripe\Bootstrap - sapphire/core/ (soon to be framework/core/)

SilverStripe\Bootstrap\Manifest - sapphire/core/manifest/

SilverStripe\Model - sapphire/model

SilverStripe\View - sapphire/view

SilverStripe\Control - sapphire/control

SilverStripe\Admin - sapphire/admin/

SilverStripe\CMS - cms/

Conceptually, this would make it easier to move to a place where you can decide to use, for example, SilverStripe\Bootstrap & SilverStripe\Control without SilverStripe\Model or SilverStripe\View.  It gets a little wonkier with the things that I *haven't* listed: api, cli, dev, email, filesystem, forms, i18n, search, and security, but one point about these pieces is that it's arguable as to whether or not the really should be part of the core framework or not (admin is also in that camp).  So, creating a namespace structure that side-steps this could be okay.  If we had a proper module loader (Composer), the fact that there would be lots of modules should be okay.

If we were to go down this road, we may want to consider pushing tests, templates, css, scss, js into these separate sub-modules too.  We don't necessarily need to do this at the time that we namespace things, but it would be good to know whether or not we thought it was a good idea.

Alternatively, we can accept the framework as being more atomic than all this, 

SilverStripe\Framework\Bootstrap - sapphire/core/ (soon to be framework/core/)

SilverStripe\Framework\Bootstrap\Manifest - sapphire/core/manifest/

SilverStripe\Framework\Model - sapphire/model

SilverStripe\Framework\View - sapphire/view

SilverStripe\Framework\Control - sapphire/control

SilverStripe\Framework\Admin - sapphire/admin/

SilverStripe\Framework\CMS - cms/

Another thing I quietly threw in there was renaming "core" to "bootstrap".  This was also Hamish's suggestion and is more in line with other frameworks (Rails, I think).

[Andrew Short]

I think we should use SilverStripe\Framework and SilverStripe\Cms - this way it fits it with the packagist vendor/package-name convention.

Andrew Short.

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

[Sam Minnée]

Yeah I guess the argument for not pulling Framework in there is if we wanted to shard Framework into its smaller constituent packages.

[Simon J Welsh]

I'm for not including framework, purely for easier typing. Sure, you can add use \sapphire\framework as fw; (or similar) to the start of every file, but for those files where something from the framework is only used infrequently, this would get rather annoying.

Some things to remember regarding case: namespaces are case-insensitive and passed to the autoloader as called. I type my qualified name with lowercase namespace and then camel case class. It will really annoy me and, most likely, confuse a lot of others, if we do go with the PSR-0 autoloader which doesn't seem to handle this.

I'm for keeping the folders themselves lowercase, simply for aesthetic and tab-completeion reasons. I just find folders containing code with capital letters weird looking and really hard to cd into.

> --
> You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
> To post to this group, send email to silverst...@googlegroups.com.
> To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
>

---

[Sam Minnée]

Ok, we're split on that issue. The problem with excluding framework is that our second level namespace gets really cluttered:

SilverStripe\Core

SilverStripe\Model

SilverStripe\View

SilverStripe\Control

SilverStripe\Admin

SilverStripe\Cms

SilverStripe\Api

SilverStripe\Email

SilverStripe\Dev

SilverStripe\Filesystem

SilverStripe\Forms

SilverStripe\I18n

SilverStripe\Parsers

SilverStripe\Search

SilverStripe\Security

SilverStripe\Tasks

SilverStripe\Tests

What, then, would the namespace of the search module be?

I'm going to namespace the code under SilverStripe\Framework for now and we'll see how it plays out.

I'm not going to rename any of the files just yet, so we won't have PSR-0 compliance, but things will be set up so that PSR-0 compliance will be achievable with a few file renames.

[Anselm Christophersen]

I was wondering what's the status on namespace usage?

I just checked some random core files in what I believe is the latest version (https://github.com/silverstripe/sapphire/blob/3.1/core/ClassInfo.php), and they are not using namespaces yet.

Can we already start using namespaces in our own modules, or are any specific changes due in order for us to allow to do so?

Anselm

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/n6GNK2-bkDgJ.

[dam...@silverstripe.com]

Just a heads up to anyone who is currently following this issue, the discussion on namespaces has been moved to github.

You can talk about this on the github issue at https://github.com/silverstripe/silverstripe-framework/issues/3548

[Marcus Nyeholt]

Interestingly, the github issue links back to here... :D

Anyway, a couple of years(!) ago now, Andrew Short actually did a fair amount of work getting SilverStripe working using namespaces in a manner that would make it a lot more composer friendly, and provided a cleaner "Application" abstraction. It's probably worth reviewing some of his work (some of which is available at https://github.com/ajshort/sapphire/tree/composer and https://github.com/ajshort/silverstripe-cms/tree/composer) to see if any of that is still useful in context of whatever changes are going to be implemented.

My opinion is that if we're switching such fundamental structures around, there's possibly some other related work (ie how modules are loaded, initialised and configured) that may be worth looking into at the same time. 

[dam...@silverstripe.com]

Well, since we seem to have moved the discussion back to the dev list, we may as well talk here. :) Hopefully everyone's managed to express their feelings about other issues in the mean time.

If we were to move to namespaces, does anyone have a particular preference for what the namespaces actually would be?

I've seen suggestions of using SilverStripe/Framework for all framework classes, but that wouldn't work for a psr-style implementation. There was also a suggestion to use all lowerspace namespace names, so we would be able to maintain current folders without a rename required (or need to think about case at all).

I'm quite keen on a psr-4 approach, roughly (but not exactly) based on the current directory structure. I'd prefer SilverStripe/Framework, SilverStripe/CMS etc as root spaces, since upper camel case makes for ease of reading and you don't need underscore delimiters. What do others prefer?

Kind regards,

Damian

[Conrad Dobbs]

I think sticking to the psr's where possible is a good idea. One thing with the namespaces is how this would then effect thirdparty modules. Currently modules are installed at the root level, I work for Web Torque, so I would then namespace it WebTorque/ModuleName. Would this mean we'd then have all the different vendor directories at the root level of the site? I think there was a discussion elsewhere about having modules installed through composer installed in the vendor directory. This would seem a lot cleaner than having a who's who of the SiverStripe community at the root of every site.

[dam...@silverstripe.com]

Just to be clear, this won't require modules to suddenly use namespaces, only that they reference the updated namespaced classes in core. :) Modules will still be installed at the root level as per normal.

[Conrad Dobbs]

While it may not be required, wouldn't it be recommended? Wouldn't it be better to have consistent coding standards in both modules and core? End of the day, noone has to follow the standards if they don't want to for a project.

[Sam Minnée]

Yes, I definitely think they would be recommended.

The move to shift modules into Composer's standard vendor/ folder would be a separate task (ajshort has a feature branch that started on this) but it would make a lot of sense to include this change in the same release as namespacing.

[Daniel Hensby]

Namespaces are a good idea, it has to happen at some point so putting it off shouldn't be an option.

As with Conrad, I think following PSR where possible is what we should do but it shouldn't be a definitive requirment. PSR-4 standards can be quite laborious and subject to personal preferences (tabs v spaces being a very obvious one).

I don't actually see using namespaces to bring about change to the case of folder names or class names as a bad thing, I'd welcome it 100% sometimes there needs to be an excuse to fix some of these inconsistencies and get it all into shape. At the moment, folder name case is important in SS and can break things like themes and so on (if you use the folder "Forms" in your theme, it will won't override a core "forms" template and same for if you use "includes" instead of "Includes"), so I'd like all of that to be cleared up rather than sticking with what we have.

Daniel Hensby Director

e: daniel...@betterbrief.co.uk t:  020 7183 9266 w: http://www.betterbrief.co.uk

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.

To post to this group, send email to silverst...@googlegroups.com.

Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Sam Minnée]

 

As with Conrad, I think following PSR where possible is what we should do but it shouldn't be a definitive requirment. PSR-4 standards can be quite laborious and subject to personal preferences (tabs v spaces being a very obvious one).

*MORE ON PSR-4*

Tabs vs spaces sounds like PSR-1 or PSR-2. PSR-4 is the second PSR that relates to autoloading: http://www.php-fig.org/psr/psr-4/

I like PSR-4 better than PSR-4 because it's got less unhelpful verbosity. So, if I have a class called Sminnee\MyProject\Model\MyData

PSR-0: 

I put this in composer.json:

{

    "autoload": {

        "psr-0": {

            "Sminnee\\MyProject\\": "src/"

        }

    }

}

My code would then go in src/Sminnee/MyProject/Model/MyData.php. Even though src/ is linked to the Sminnee\MyProject namespace, I still need to include those folders.

PSR4: src/

I put this in composer.json:

{

    "autoload": {

        "psr-4": {

            "Sminnee\\MyProject\\": "src/"

        }

    }

}

My code would then go in src/Model/MyData.php - note that Sminnee\MyProject isn't included in the folder name.

*DO YOU HAVE TO USE PSR-4*

Regarding the "definitive requirement" comment: I don't think that PSR-4 or PST-0 should be mandatory in modules/project code. SilverStripe still needs to come with a manifest-based autoloader, although I think it would make sense to use a PSR-4 or PSR-0 autoloader when you can. One practical benefit would be that, if you are using the PSR autoloader, you don't need to flush when you add a new code file. ;-) Long term, the manifest is still going to be required for generation of responses to ClassInfo::implementorsOf() and ClassInfo::subclassesFor() (maybe some other odds & ends too).

However, when it comes to the cms & framework modules, we'll need to make a call on how the code is restructured. My vote would go with PSR-4.

*PSR-4 AS A METAPHOR FOR TABLE NAME HANDLING*

I think that the PSR-4 concept of mapping base namespaces to paths on the filesystem can be applied to other areas, such as templates and table names. For example, let's imagine for the moment that we agree on SilverStripe\CMS\Model\SiteTree as the fully qualified classname for SiteTree. Then you might map SilverStripe\CMS\Model to the table prefix "cms". If you do that, the table name for SiteTree data would be "cms_SiteTree". With a set of sensible defaults, and easy ability to override, and some clear error handling in the case of conflicts, I think that it should provide a system that keeps namespace pollution manageable as well as avoiding irritatingly long table names. I'd expect something similar with the folder names of tables. You could also avoid having to do any database migration by mapping a number of different namespaces to a null prefix, and hoping that this doesn't cause conflicts. Although I have mixed feelings about making that a default option, it would be a good trick to include in the upgrading guide, at least.

*CURRENT TABLE NAME NAMESPACE BEHAVIOUR*

The current behaviour is that table names contain backslashes. Although it might make sense to continue allowing current behaviour, I can't really see this being a desirable mode for very many people and so I wouldn't want to recommend it to new users. Even if the PSR-4-like namespace-to-prefix conversion was dropped, I would still be in favour of replacing backslashes with underscores or something in the generated table names, with some sensible conflict error checking and workaround for the 0.1% of times where that causes a conflict. For example, the workaround might be a DataObject.table_name configuration parameter that you can override in your yml config.

In order to support the current behaviour, we might have setting like table_namespace_separator, which defaults to "_", but can be set to "\" by people already relying on this behaviour. I'd be interested to know how many people are using that behaviour—how many people have put their DataObject subclasses into namespaces?

[Daniel Hensby]

I can't say I have anything to disagree with there!

Will did some namespacing on a project of ours, not sure if any were DOs, though...

Daniel Hensby Director

e: daniel...@betterbrief.co.uk t:  020 7183 9266 w: http://www.betterbrief.co.uk

--

[Jeremy Shipman]

One of Hamish’s arguments on the related github issue in favour of namespacing was:

https://github.com/silverstripe/silverstripe-framework/issues/3548

4) Longer term, PSR-4 would mean SilverStripe would be compatible with middleware layers like Stack

I looked up stack middleware, and watched this video: https://www.youtube.com/watch?v=s9CC8dKsK3s

(which also has a great info the history of web servers / php).

Introducing stack middlewares sounds like a great way to get heaps of HTTP level functionality into SilverStripe with minimal effort, so +1 for namespaces (and one day possibly implementing HttpKernelInterface in SS).

[dam...@silverstripe.com]

I think psr-4 is probably the best current convention to follow, although we aren't quite at the point where we have decided to enforce composer usage for all silverstripe projects, even if it is the recommended practice.

Anything which is developed to meet this need will need a non-composer classloading fallback, as well as support for third party modules which are installed manually (whether they follow the psr-4 loader or not).

At the moment composer provides an autoloader generator, which allows module developers to specify in composer.json class mappings to source directories. Without composer then suddenly this would need to be done manually, or some other mechanism to be developed. ;)

In Core.php we have

if(file_exists(BASE_PATH . '/vendor/autoload.php')) {

require_once BASE_PATH . '/vendor/autoload.php';

}

We would probably have an "else" in there with some kind of custom autoloader with enough knowledge to work as well as composer would, or at least build it into the class manifest.

Kind regards,

Damian

[Loz Calver]

Anything which is developed to meet this need will need a non-composer classloading fallback, as well as support for third party modules which are installed manually (whether they follow the psr-4 loader or not).

Yep, we’ll definitely still need a non-composer class loader - not just for modules but for “mysite/” too.

Just a thought - are files in vendor/ added to the class manifest? Let’s say future me writes a module, PSR-4 compliant and autoloaded. If I don’t add the silverstripe-module type to composer.json, it’ll (presumably) be added to vendor/ (right?) - will this module work as expected? Will ClassInfo calls etc still work? Presumably, our current ClassLoader doesn’t touch anything in vendor/, does the same apply to ClassManifest?

[Michael Strong]

Loz,

They would get loaded in, but they wouldn't be treat as a module.

_config.php would be included at the wrong time (if at all) and _config folder would be ignored so you'd lose configuration. I haven't tested this though.

Michael

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Michael Strong | Platform Support Developer
SilverStripe
http://silverstripe.com/

Phone: +64 4 978 7330
Skype: micmania1

[Sam Minnée]

Just a thought - are files in vendor/ added to the class manifest? Let’s say future me writes a module, PSR-4 compliant and autoloaded. If I don’t add the silverstripe-module type to composer.json, it’ll (presumably) be added to vendor/ (right?) - will this module work as expected? Will ClassInfo calls etc still work? Presumably, our current ClassLoader doesn’t touch anything in vendor/, does the same apply to ClassManifest?

Not at the moment; that's something that would also need fixing. I believe that AJ Short has some work from a while back in that area.

[Matthew Bonner]

In terms of providing a full MVC implementation, most frameworks allow you to specify which namespaces will be searched for a controller, and then if no controller is found all namespaces are searched, and then if still no controller is found the global namespace is checked. Is this going to be the case when we switch over to using namespaces?

[Sam Minnée]

Hi everyone,

The last few days I've been working on PHP7 support for SilverStripe 4 - https://github.com/silverstripe/silverstripe-framework/pull/4551. Because this involved renaming DBField subclasses, I'm wanting to put them into their namespaces.

So, I've pulled my thinking into an RFC about namespacing. It doesn't cover all the details; it's intended to be more like a high level guideline to use as a starting point when we start addressing namespaces on a subsystem-by-subsystem basis:

https://github.com/silverstripe/silverstripe-framework/issues/4562

Feedback welcome!

Thanks,

Sam