Add typo3-flow-boilerplate package type

[cognifloyd]

typo3-flow-boilerplate is part of my Google Summer of Code which adds Boilerplate packages to TYPO3 Flow.

http://cognifloyd.blogspot.com/2013/05/flow-package-types-boilerplate-thoughts.html
http://cognifloyd.blogspot.com/2013/05/basic-designs-for-typo3boilerplate.html
http://cognifloyd.blogspot.com/2013/05/boilerplates-and-builders-in-typo3-neos.html

[shama]

Thanks for the PR. Am I understanding correctly that Boilerplate packages are not yet officially supported?

[cognifloyd]

When Flow support was first introduced, you said that we couldn't have wildcard folders (typo3-flow-<yourlib>) even though we wanted to support Packages/<any subfolder here>. The division between package-types allows for more logical package organization, even though technically, Flow doesn't care which folder they're in, as long as the package is a flow package. That means that the Framework, Application, Sites, or Plugins are treated the same within Flow, but from the users perspective they each have a different kind of package. The one folder that Flow sees as 'different' is the Libraries folder (which serves as the vendor folder within a TYPO3 Flow installation to hold all of the non-flow packages).

So, though the packages that work with Boilerplates are not complete, any typo3-flow-<subtype> is already supported by Flow.

Edit: fixed formatting.

[shama]

Ah interesting thanks for the explanation. How is autoloading configured in Flow? Would it be possible to load all packages from one custom folder?

[cognifloyd]

TL;DR

I'm not sure exactly how autoloading is implemented in Flow, but effectively this is how it works: Flow gets all of the composer.json files under Packages/, reflects the php code in the valid PSR-0 pacakges, and then autoloads everything from the reflection cache (as long as the package is marked as "active" in the PackageManager).

You don't need to configure Flow to know about any other custom folders in Packages/. It looks in all of the subfolders of Packages/ for PSR-0 packages. So, you could have flow packages in as many custom folders (subfolders of Packages/) as you like. But, this only works for flow packages. All other packages need to be in Packages/Libraries/.

Additional Information about Flow Pacakge Management

A description of how flow deals with PackageManagement can be found at http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/PartIII/PackageManagement.html

In addition to the PSR-0 definition of where to find classes, Flow also cares about other folders within each Flow package that are handled in special ways. Flow grabs and combines the configuration from all of the packages (in <package>/Configuration/), and creates symlinks in Web/_Resources/ to all of the public resources (in <package>/Resources/Public/), but only for Flow packages. Also, if you run PhpUnit with Flow's unit or functional test configurations, then all Tests in the <package>/Tests/ folder of each package are automatically included in the test run. Other folders might get special handling, like <package>/Documentation/, if a package is installed that wants to do something with that folder. In Libraries, only the PSR-0 classes are touched by flow because there is no guarantee that these additional Flow folders are present in other package types, or that these other packages follow any Flow conventions on what goes in these folders if they do happen to have them.

Some things to note about Flow's PackageManagement include:

• Flow only supports PSR-0 class autoloading: http://docs.typo3.org/flow/TYPO3FlowDocumentation/TheDefinitiveGuide/PartIII/PackageManagement.html#class-loading
  • It does not use the composer generated autoloader, though the composer autoloader is extremely useful when developing a flow package in PhpStorm.
• A reflected class is generated for each PSR-0 class to do things like:
  • introduce lazy loading of domain objects (possible thanks to the object manager)
  • introduce any aspects (like logging or security) that want to wrap a particular class or method with additional functionality
  • autowire Domain Models with Doctrine ORM using some Flow helpers that make using Doctrine even simpler
• When you run a flow app, you are technically running from these generated php files (they're cached), not the original php source files.
  • Flow introduces some awesome error handling to make sure that when you see an error, the error points to the original php source file, not the generated one
• Any package can be marked as inactive through the packageManager, preventing autoloading of any code from that package
  • other interesting states include frozen packages and how changes in the original php source files are treated differently depending on whether you are in a production context or a development context
  • (eg if someone hacked in and changed one of the original source files in a production context, it wouldn't do anything, because flow is using one the generated reflected copy of those classes.)
• If you want to load any php code that is not reflected automatically (like a package that doesn't list their main sources instead of their test sources first in autoload: { psr-0 {} }, making you disable autoloading for that package), then you have to handle loading that package's classes yourself through include().

Edit: fixed typo

[shama]

Thanks I appreciate the information!