Flow Package Types + Boilerplate Thoughts

So, there are a bunch of different package types for TYPO3 Flow. If you look in the packages folder you'll see several major kinds:

• Distribution/ : The super-package that includes (via composer.json) all the other packages
• Packages/
• Applications: Flow-based apps
• Framework: Flow's packages
• Libraries: 3rd party libs and non-Flow packages
• Sites: Neos site packages
• Boilerplates: Meta-templates (part of my GSOC Proposal) that contain boilerplate files (php code, fluid templates, yaml, ...)

Then, there are some common naming conventions for Flow applications.

• FooKickstarter: for initial creation of packages of type "Foo".
• FooBuilder: to not only create, but edit "Foo" packages.

So, if my GSOC project is only going to be a one-time copy kind of a package, then I need to call it FluidKickstarter. If I give it the ability to edit and not just start templates, like I plan, then it should be called FluidBuilder.

I'm thinking of creating a Boilerplate framework. That way, there'd be a TYPO3.FluidBoilerplate that deals with Fluid specific template manipulation, but the TYPO3.Boilerplate package would contain the more abstract parts of dealing with any Boilerplate package. So that would mean there'd be something like this:

• FooBoilerplate:
• extends TYPO3.Boilerplate to assist builders in building "Foo" packages.
• Not to be confused with packages in the Boilerplates folder, which contain raw material for the Boilerplate system to use in creating various types of packages (by FluidBuilder, PackageBuilder, FormBuilder, etc)

That solution feels awkward. Perhaps, there's a TYPO3.Boilerplate package, like before, that provides the abstract ways of working with Boilerplate packages. Then, the Builder packages would include a server-side layer that interacts with TYPO3.Boilerplate to do the building of packages (Fluid, Package (Flow), Form, Ember). Plus, each Builder package would contain a Frontend app that does the same thing as the backend, but in the browser. Then they would communicate over some RESTful API with Ember Data.

To date, that has been the solution for the other builder projects, so I think that would be a good convention to follow, with one change, in that I'll be using Boilerplate package, and hopefully other Builders will follow suite.

One of the issues with current Builders is that they store all of the template like stuff in their Private Resources folder. That's not very extensible, and though it might work for a lot of the current Builders, it won't work for FluidBuilder because I want there to be a lot of ready-made boilerplates that people can use to create whatever site they want as fast as they want. They should be able to make their own, or use Twitter Bootstrap, or H5BP, or whatever other grid system they enjoy.

Why? Flow is already fun for developers, but it needs to attract designers. So, Neos should be fun for designers to use, and Boilerplate packages are a good way to get there.