cognifloyd/cognifire.filefish

This used to be called "BuilderFoundation". A generic file editing framework designed to allow semantic file editing especially within "packages". The basic process is: Stuff gets copied from a boilerplate package into a derivative package. In the process, the files in the derivative package may be modified through this semantic editing framework.

cognifire.filefish's Issues

Add YAML persistence of Editing Scripts

Add Yaml persistence of editing scripts (FlowQuery is easy to use from Eel which is easy to store in Yaml).

Wire QueryPath into the HtmlEditorContext

Wire QueryPath into the HTMLEditorContext and register which QP methods can be accessed from FlowQuery

Add EditorContext parsing

Make the EditorContext parse the files into a DOMDocument or DOMDocumentFragment

HTML/Fluid Files might need two passes: HTML5-PHP and Fluid Parser (for namespaces and inline fluid)

Add a way to edit fluid files

I want to make editing/creating TYPO3.Fluid files scriptable in a semantic fashion. I do not want line based editing. It's got to be able to insert elements (html, fluid, etc) at particular positions without mangling the syntax/semantics and spacing of the file.

This is my design for the "script" on the backend:

• The script will be a DSL (TYPO3.Eel and FlowQuery strings stored in YAML files).
• The TYPO3.Eel objects will map to
  • querypath/QueryPath functions (see also http://querypath.org)
    • lambda/callback functions won't be accessible from within Eel.
  • additional Fluid creation/editing functions
  • additional functions to find/load/select files (possibly a selection of files from a boilerplate package like zurb foundation or html5bp+bootstrap)
• I will use a version of QueryPath that uses masterminds/html5 (QueryPath 3.x includes this)
  • I expect most fluid templates to produce html5 documents, so an html4 or xhtml parser is not enough.
  • html5 parser support: technosophos/querypath#114
  • Since Fluid uses xml-like namespacing (even using xmlns on body tags in some templates), I will need namespace support, which is not technically part of the html5 spec. For this, I need:
    • Implicit Namespace support: Masterminds/html5-php#43, Masterminds/html5-php#44
    • Explicit namespaces support drafted in my fork cognifloyd/html5-php:
      • cognifloyd/html5-php@9287135, cognifloyd/html5-php@a06d501
      • Explicit Namespaces shouldn't get added to the nsRoot or nsStack in the DOMTreeBuilder because the elements can occur anywhere and aren't dependent on being in any particular contextual root element (like svg, or mathml)
      • I could probably use AOP to inject the Fluid namespaces (retrieved from fluid files by using the Fluid parser as a kind of Pre-processor) but, that means html5-php has to already have support for explicit namespaces (esp in DomTreeBuilder->startTag()), and it needs a way to register additional namespaces from outside the DomTreeBuilder.
    • Note that mastermind/html5 already recognizes tags with ":" in them

Once I've got this down, then I'll extend my app to edit other filetypes, including php, typoscript, stylesheets (css, sass, less, etc), javascript, yaml, and whatever else people might want to edit. All they have to do is add a library that understands the semantics of the filetype and provides a fluent interface (or at least uses method chaining) for searching/editing the file in a jquery-like manner. It'll use the same DSL (FlowQuery in Eel in YAML). Hopefully, I'll be able to jump from editing one kind of document to editing another, as different documenttypes are embedded in each other (eg SVG, MathML, CSS, and JavaScript are all easily embedded in HTML)

Test existing functionality.

Convert my testing command controller into unit, functional, behat tests.

This is what exists:

• I can select all of the files in a given package of a particular mediatype.
• I can copy a set of files from one boilerplate package to a derivatie package.
  • Derivative Packages are extensible. For now, I have only implemented the Flow package type, however I have a stub for a TYPO3 CMS Extension, and I can imagine adding symfony package type or whatever.
  • Packages of a particular package type are managed by a packageManager class that understands how to find and work with that package type (again like the domain object principle).
• I have wired up FlowQuery with my EditorContext so that FlowQuery can pass the operations into the context.
• Delete the command controller that I used to test a lot of this.