16/01 2013

Ideas, ideas, ideas...

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.

Dear community,

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.

Here goes...

MURAMASA

Quite against my ideas so far this one mostly concerns JavaScript. Yep. What I propose is a TYPO3 extension which (requiring BE authentication) can deliver a JavaScript file which can then be included in a standalone HTML file anywhere (online, locally or on the same site) in order to call upon some Fluid Voodoo:

1. When included in an HTML file the script would self-initialize, attaching a multitude of listeners in the document which allow a set of actions for any HTML element.
2. The actions which can be performed would be directed at visually chopping the HTML file into Layout, Partial and Template divisions inside the document.
3. Every HTML element would be replaceable by any ViewHelper - the JS would request (again, secured by BE auth) another resource containing a full list of every ViewHelper which can be used on the source site - and every argument and argument type each ViewHelper accepts.
4. When opting to replace an HTML element with a ViewHelper, a visual representation allowing a) selection of the desired ViewHelper and b) configuration of parameters and c) selecting where to place the parameter's value (in template or as template variable).
5. When satisfied, the butcher (he who chops) saves the complete configuration to the site.
6. The site then processes the configuration, chopping the template up into Layout, Partials and a Template.
7. The site then registers the defined variables in a static TypoScript file.
8. Full round trip support by being able to load the configuration from the site.

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 <link https: twitter.com denyerec>@denyerec. The name refers to Japanese master sword smith, Sengo Muramasa. There's a relevant story behind!

MASAMUNE

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.

HEAP

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: <link https: github.com namelesscoder heap external-link-new-window>github.com/NamelessCoder/heap

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 <link https: twitter.com fudriot>@fudriot from a long ways back.

FLUX BACKEND MODULES

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:

1. The invention of the BackendModuleConfigurationProvider and necessary registration logic.
2. New ViewHelpers/attributes to define how the module should appear.
3. New ViewHelpers to add and configure module navigation options.
4. A new ViewHelper to render a Flux-generated TCEforms configuration from a Fluid template.
5. The invention of a concept for POST data processors which can post-process the form data POSTed from any BackendModuleConfigurationProvider.

This would effectively wrap the creation of severely advanced and dynamic form-based backend modules inside Fluid and a single companion class, be that a custom subclass of BackendModuleConfigurationProvider or a form data post processor class. It would mean no longer having to deal with the backend ViewHelpers from Fluid to generate the document, include Javascripts/CSS, create navigation, make quicklinks etc. - it could speed up development of form-based backend modules by, oh shall we say, a few thousand percent? - by allowing extremely easy use of any TCEforms sheets, section objects, fields and wizards to build the actual module content - all rendered using Fluid.

ASSET HANDLING FROM FLUID TEMPLATES

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.

Currently it's just a PITA to try and include JavaScript and CSS from within Fluid templates - the ordering goes haywire, compression/concatenation doesn't detect the files, the included assets cannot be removed in any way except removing the calls to ViewHelpers or inline code blocks - and so on, ad nauseam. There is a way to fix all of this - and allow CSS/JS to be placed in Fluid templates at the same time as being mutable from TypoScript. How? I'm going to enjoy writing this next bit :)

1. Use a subclassed f:section ViewHelper - in every way working like a normal f:section except for added arguments and the ability to store in the ViewHelperVariableContainer any settings passed to it as well as any settings harvested from the section's body when rendered.
2. Allow a special set of variables which are assigned when rendering the new section type to harvest assets.
3. Override pivotal points in Fluid's code to detect the presence of asset sections inside every RenderingContext which is itself not a section. If detected, process assets when rendering the RenderingContext and store assets for later actual inclusion.
4. If a Flux form is detected and there is a record associated with the template (i.e. FLUIDTEMPLATE not supported in this particular case - but then again, FLUIDTEMPLATE + Flux is a very special breed of mutant) then use Flux to render the Configuration section with the record's "flex" field as data, grabbing the output variables and assigning them as template variables when rendering the resources. This effectively allows Fluid Content, Fluid Pages and any Extbase plugin which uses Flux to make user-configurable dynamic asset inclusions and variable substitutions in the asset's contents.
5. If the child content is not empty, use it as header content; happily assuming that <script>, <style>, <meta> and <link> tags have been used to create valid HTML <head> tag contents.
6. Add a new type of and abstract base for a school of ViewHelpers designed to include assets (individually, in groups or entire folders at once). On this new ViewHelper, add a special Interface and require the presence of a build() method which (no surprise) is able to build things like LESS and SASS on-the-fly, cached or uncached depending on current USER/USER_INT context.
7. Enable asset inclusion ViewHelpers to render their tag content and use it as script/style/header-content (depending on an Interface for each inclusion type which must be implemented for the type of asset to be recognised and processed correctly).
8. Allow the subclassed f:section access to child objects, enabling it to call build() as well as read arguments from asset inclusion ViewHelpers used in the tag content.
9. Identify every asset by the "id" used on the containing subclassed f:section.
10. Allow targeting asset ids in TypoScript - for example removing assets by id, configuring concatenation etc.
11. Additionally and optionally identify every asset by an asset id group - which can be targeted for removal/configuration through TypoScript just like individual assets can (i.e: enable concatenation for a whole collection of individual files added from both the page and content/plugin templates).
12. Enable the use of dependency between assets. For example if asset Foo depends on Bar, but Bar is always rendered last - then adding Bar as a dependency in Foo will cause the post processing to construct a dependency tree and use it when performing the final inclusion. Because of this, removing a dependency (fx "jquery") could remove jQueryUI, a jQueryUI CSS theme and every plugin used in individual Partial templates.

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.

Final thoughts about what to do about all this

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:

1. Be heard. <link http: fedext.net overview external-link-new-window external link in new>I've created a forum thread where this entire text is also placed. I would be very happy to discuss the features with you all in that thread.
2. Become a contributor. If you are a developer and your skills apply please do get in contact with me. If you're not the boss of you then perhaps ask whomever is, if you could be allowed to spend a few chunks of company time on creating (if you'll excuse the sales pitch) totally kick-ass features for the TYPO3 community.
3. Become a sponsor. I don't enjoy writing this part - but I've come to the realisation that it is not feasible to single-handedly do all the above at the same time as managing a full time job at Wildside. That's why: if you are not interested in or able to contribute manpower but you happen to be in possession of extra cash - then please consider hiring me as a consultant through Wildside to work on just the feature you would like to see become a reality. You would of course receive due credit with linkage everywhere that the feature is mentioned.

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)

Coder's greetings,
Claus