Major Feature #33258

Implement support for Assetic

Added by Sebastian Kurfuerst almost 10 years ago. Updated over 7 years ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2012-01-17
Due date:
% Done:

0%

Estimated time:
PHP Version:
Has patch:
No
Complexity:

Description

We still need a clean solution to handle assets; and https://github.com/kriswallsmith/assetic would be a great fit to integrate.

First off, we need to create a concept for it.


Related issues

Has duplicate TYPO3 Flow Base Distribution - Story #42407: Asset ManagementNew2012-10-26

Actions
#1

Updated by Sebastian Kurfuerst over 9 years ago

Did anybody start working on a concept yet?

#2

Updated by Adrian Föder over 9 years ago

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.

#3

Updated by Johannes K over 9 years ago

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.

#4

Updated by Adrian Föder over 9 years ago

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!

#5

Updated by Sebastian Kurfuerst over 9 years ago

  • Status changed from New to Accepted
  • Assignee set to Adrian Föder
#6

Updated by Sebastian Kurfuerst over 9 years ago

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

#7

Updated by Adrian Föder over 9 years ago

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.

#8

Updated by Adrian Föder over 8 years ago

  • Assignee deleted (Adrian Föder)

Also available in: Atom PDF