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/
> 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)
--
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.
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.
--
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.
> 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.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
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.
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.
>
---
--
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.
--
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.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.
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 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).
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).
--
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.
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?