There are too many things stuck in my head and they want out. Here is a list with a few details about each and a proposal for doing something about it.
I have so ideas things stuck in my head - thoughts about features which would make the life of every (Fluid-using) developer so much easier. I am publishing this list in the hope that someone out there either wants to create it (they're my ideas but could be your product!), cooperate with me on creating it - or as a fallback would be interested in sponsoring funds which can then be converted to the necessary man hours.
The result would be like TemplaVoila's point-and-click mapping interface on steroids - which were also on steroids. Imagine Google Analytics' in-page click counters. Now imagine that the end result is a fully usable Fluid template for page templates (also FLUIDTEMPLATE-based!), Extbase plugins or even Fluid content elements. And now, imagine you could use it from your iPad while sitting in your couch.
Credit for the inspiration for this feature goes entirely to @denyerec. The name refers to Japanese master sword smith, Sengo Muramasa. There's a relevant story behind!
If muramasa becomes a reality, then masamune could follow as a refinement. By being very creative in overriding a few pivotal points in Fluid's code it would be easily possible to create markers in the output and allow muramasa to use an already rendered set of Fluid templates as the basis for another, separate set of templates.
Why? Imagine that you want to build a new version of your existing web site but want to completely redesign the templates. However, you don't want to reuse the Partials/Layouts but would rather create new ones, with a fresher instance of the ViewHelpers involved. Maybe you would like a designer to do the work?
This could be achieved by enabling masamune on the source site and in that configuration, enabling external imports of muramasa which would be permitted to butcher the current template into new templates on a secondary site - and even preload instances of HTML-element-to-ViewHelper replacements based on the beforementioned markers. Something which would not be possible using only muramasa. And something which enables cutting out different Partials and Layouts from individual pages on the source site.
The name refers to Goro Masamune. The folklore around Sengo Muramasa also involves Masamune.
This idea has been floating around for an incredibly long time - originally dubbed "The ViewHelper Repository". I have written a detailed plan for how to achieve such a thing:
Briefly described: TER is no good when it comes to delivering customised packages of, for example, ViewHelpers (but indeed also things like injectable Services). Therefore, my brain keeps coming back to the idea of creating an online "repository" of ViewHelpers and Services which could be added to a "shopping basket" either individually or in chunks. When adding, any dependencies and base classes not part of Fluid itself would also be included. Imagine the jQuery(UI) compilation and download page. Now imagine that instead of selecting JS plugins you would be selecting ViewHelpers and Services.
The result would be an extension with a custom extension key and pre-filled title etc., containing all the selected ViewHelpers under the chosen extension namespace.
Incremental updates would also be possible; including a manifest in each generated downloadable and allowing this manifest to be uploaded and modified (using the same "shopping basket" procedure as before) and finally re-downloaded with updates applied. For luxury a BE module could be added, containing the necessary logic to check for an automatically download and apply minor updates.
Credit for key parts of this feature idea goes to @fudriot from a long ways back.
Of the features described so far, this one is the smallest but possibly also the most useful (at least for extension developers, whatever the purpose of the extension may be - public or private). Flux delivers dynamic forms - but these forms cannot as it is now be used in Extbase backend modules. Flux already uses a special concept, a ConfigurationProvider, which handles the interaction and configuration of a Flux form template.
This ConfigurationProvider concept is already the base of the ContentConfigurationProvider from the extension fluidcontent and the PageConfigurationProvider from fluidpages. With a bit of effort a new BackendModuleConfigurationProvider concept can be developed, allowing use of Flux forms as complete backend modules which render one or more Flux forms contained in the template file(s) as forms in the backend module. This would require:
This is one I would really like to create, given the time. I envision this as part of EXT:fluidpages but could possibly be made generic enough to merit its own dependency free extension.
Because Fluid is cached as native PHP code and only triggers when Fluid actually renders the RenderingContext which contains the assets, this should be tremendously fast. By using a dependency tree it will be consistent regardless of the order in which assets were encountered. By allowing grouping (across dependencies also) of assets it becomes possible to manage entire groups and thus much easier to manage assets in general. And finally, by allowing a dependency to be removed and along with it any asset which depends on the removed asset, one can immediately rid an entire web site (assuming only asset inclusion is used to attach assets!) of all jQuery JS regardless of where it was included.
The main resource lacking is time. And that can be obtained in a few ways. If one or more of the above proposed features tickles your fancy and you're feeling motivated then let's act on it. In the order of preference these are the ideal contributions you could make:
I will stress though, that what is really needed is time and lots of it and that I absolutely would prefer if that came in the form of code contributors. Sponsorships are only mentioned here as a way to reserve some time working on these features - if I could, I would happily work full time on nothing but producing these features, but four to six hours every evening and almost always the majority of the weekend will not be enough. Not nearly.
(here's hoping that I managed to tickle your fancy)