TYPO3.Flow

Did anybody start working on a concept yet?

So far, I've created two repositories at Github in order to get a clue and to get a possibility to work with and to point at it.

Assetic Package¶

Located at https://github.com/afoeder/Assetic-Package, serves as FLOW3 package wrapper for the original repository. Provides a tiny script that re-pulls the necessary files from the original repository.

TYPO3.Assets Package¶

Located at https://github.com/afoeder/TYPO3.Asset, provides the actual logic for working with Assetic.

For the time being I'll continue at a Wiki: http://forge.typo3.org/projects/flow3/wiki/Assetic_ideas page, for any reason I currently think that's the better way.

Great!
Do you plan to integrate filters and nested assets, too?

It would be nice to be able to set the debug mode ( https://github.com/kriswallsmith/assetic/blob/master/docs/en/define.md ) from the configuration file. So we could disable merging/filters etc... in Development Context and have it enabled in Production.

Johannes,
we "plan" anything you like :) We're currently in the absolut early stage of collecting some ideas and implementation possibilities.
Do you have production experience with Assetic? Would be fantastic to have you on board for that!

Hey Adrian,

Thanks for starting with a concept! Some comments from my side:

• I'd suggest to use "Assets.yaml" instead of "Settings.yaml"
• The ViewHelpers IMHO should directly output the <script src> and <link rel="stylesheet"> tags, and not work like <f:for>. Any particular reason you started with it?
• The bundle names should be namespaced (i.e. TYPO3.TYPO3:Debug instead of Debug)
• I'd rename "references" to "dependencies" and only allow bundle names there.

I am not yet sure if we actually need individual asset definitions, or if we can ALWAYS enforce the user to use Bundles. This would IMHO simplify the configuration.

What do you think?

Greets, Sebastian

Hi Sebastian,

indeed I thought about it in "idle time" ;-), I'll write down a few things.

Basically, the design of my suggestion was a bit inspired by already-existing implementations for e.g. Symfony or even Smarty.

Another general question I'd have is the level of abstraction we want to have here; how much should the Assetic usage bound to FLOW3? This would mean; how generic should the configuration, for example, be. This would be important for the layout of the Settings/Assets.yaml file; or even the naming of it. I, btw, would be fine to make Assetic compulsory per convention; if a user would like to use other stuff he's free to implement it project-based.

So far, to your statements:

1. Assets.yaml is fine for me, as mentioned above.
2. Direct output of <script> / <link rel="stylesheet">: The drawback is that the user hasn't control over the exact looking of the tags anymore. Maybe he'd like to add additional params or lack the auto-closing for any reason. But I must admit that that would be very rare and that most use-cases can be beaten with using the AbstractTag VH.
   Second reason for the nested layout was to make the actual VH less bloated; but that's only importent when letting the user define the concrete tag.
3. Namespacing: of course agree.
4. Forcing bundles: I think I'm also fine with it, because as you said: we won't allow such much permutations of configuration possibilities then.

As one of the next steps, I'd love to see a "target" specified, i.e. a use-case with some (JS) files and the appropriate Assets.yaml and VH looking. Because I personally still haven't the whole picture of what's possible with Assetic, that would be a good next step for me.