Planning for Mechanics 1.0

This page details progress and forthcoming changes as I move towards version 1.0 of Origami, Mechanics, and some other projects. The changes are numerous, and cover everything forwards from the current default / 1.2 compatible branches, beyond which large scale changes have taken place.

Planned

Autoroute

I am now using Autoroute and Tokens to replicate all the functionality previously created by Pipe Routes. From version 1.0 onwards, Mechanics will only be compatible with Orchard 1.4 and Autoroute. From the current time I'll be unable to offer any support or documentation for old versions of Science Project or Orchard.

Alchemy

This is a new module that's difficult to describe without a certain amount of hand-waving. Essentially it's a pluggable pipeline to map content or other objects to the display through a consistent routing mechanism. It means to modify most things about the way a display is rendered you don't need to override any controllers. It's a key part of the ability to push shapes to Layout zones instead of Content, although it will be able to do much more.

More information here...

Plumbing

This is being moved to a separate module, which will now just be a Theory project. Most of the functionality has been removed because Autoroute provides a clearer and more predictable interface.

Plumbing still has an important function, which is the Drill Route Part. This works with Alchemy to allow child relationships of an item to be displayed and filtered on sub-urls. The best example I can give would be for a per-user blog structure:
/users -> Displays all users (currently requires Projections, might support this in the future)
/users/pete -> Displays pete's profile
/users/pete/posts -> Displays a list of all pete's blog posts
/users/pete/posts/my-first-post -> Displays the blog post in "Detail" but still with the heading of "Pete's Blog Posts" and some of Pete's profile details

This is the core purpose of Plumbing - to display an object, and then drill down into that object's relationships on child urls.

Cache Eviction

This module is being removed, it will no longer be required as cache eviction will work thru the consistent routing mechanism of Autoroute.

Lens

This is a new search feature designed to be reusable across multiple contexts. It will function as a front-end search for users with Ajax bells and whistles, and as a pop-up search for creating relationships, and as a back-end search for the Content list. Hopefully it will be possible to in some way integrate with Projections to reuse its search/forms building in a dynamic way.

It will also have a nifty feature of "fallback search" - when a 404 page is caught, it will instead display a friendly page of "Perhaps this is what you were looking for..."

Gravity

This will be the Ajax / drag-and-drop library.

Formula

Another new module in the works. The idea is to dynamically build UI from simple POCO models (as opposed to Orchard.Forms which is pretty tricky to use and geared towards Rules/Projections; and after playing with it a bit I've found it's impossible to use for most common scenarios).

The forms will be manipulable with Placement.info, and individual parts will have overridable templates. You'll also be able to set up "Field Drivers" to encapsulate UI and postback lifecycle for specific fields or specific types of field.

It will also provide form building in the admin UI (e.g. "build your own Contact form").

Other

  • Alternates - now that so many more things can done with placement Match nodes, it's not so necessary to have as many alternates as we did on the connector shape (it was inconsistent across the different shapes anyway). The various Connector-{Left}-{Right} alternates and many permutations will be removed, hopefully this will speed up display building a lot.
  • Front end. The final goal is to start surfacing editor functionality in the front end rather than back end.
  • Layout pushing. It's now possible to push all shapes to Layout instead of rendering in Content. Or you can use Paperclips to push individual sockets to Layout. But there's still no way to control it for individual shapes.
  • UI grouping. I want to reuse the way sockets are grouped to different pages in the menu, to be able to create a tabbed panel on normal editor and display renders.
  • Nested editors. When creating or editing relationships you will want to modify content without transferring to a separate page. Due to a huge number of technical difficulties in intercepting the Prefix in normal content drivers I've reached the conclusion this must simply be done with iframes.
  • Front-end editing. For a smoother editing experience I want individual parts to be editable in the front-end rather than the entire content item, this is especially relevant with pushing shapes to Layout zones, so you can just click on the area of the screen you want to edit. This will require some Ajax trickery and some sleight-of-hand with shapes and drivers.

Completed

  • Settings - where the Site object supports sockets/connectors, these are now shown on individual Settings pages, instead of on every page. The SocketGroupName setting on ConnectorPart will move the UI for that socket to a different settings page (you can even create entirely new settings pages this way).
  • Placement. Orchard's Placement system has been extended to allow pluggable Match nodes, and new alterations (after the semicolon in a Place node). This allows greater scope for keeping Placement files sane when dealing with large numbers of content types, connector types, and display types in your website. The pluggable features will only work when content displays are build from a) SocketsPart (so all editor UIs and all connector displays) or b) Plumbing's ItemController, which requires you to use PipeRoute (although in the future I will additionally allow hijacking Core.Content's ItemController and AdminController so you can get the same functionality everywhere)
  • Paradigms. These are a set of pluggable, named conventions/behaviours which can be applied to socket/connector events and the rendering pipeline. It's in effect like having multiple DisplayTypes available. You can use paradigms in Placement (<Match Paradigm="Foo">) to switch shapes on/off (which will usually switch off their behaviour too) and specify alternate templates. You can also access and modify the Paradigms list in SocketHandler, ConnectorHandler, and ModelDrivers; so they can be used to switch behaviours on and off in code.
  • Alias/Autoroute integration. Alias and Autoroute are upcoming new features in Orchard 1.4. Mechanics now supports Autoroute/Tokens patterns for nested Urls.
  • Display/Editor unification. Origami now has the same process whether you are building a Display or an Editor; there's a new parameter called "Mode" that's available on the ModelShapeContext and also can be used in Placement Match. Model Drivers that used the display/editor separate can now inherit from LegacyModelDriver<T> instead to get the same functionality. The new ModelDriver<T> has just Build and Update overrides.

Partially Done

  • Optimisation - numerous areas have been identified where unnecessary processing was taking place. Many have been fixed now. It's not yet known how much performance increase this will have on a live site, but because of the multiplicative nature of relationship rendering (e.g. navigation), it's expected that even small optimisations in key places will produce a good overall difference.
  • Versioning. Leveraging Orchard's content versioning to store past revisions of all connectors as well as content. Needs merging to current branch and finishing off, but largely done.
  • Theory projects. Some still need updating and fixing. Others need consolidating or removing.

Last edited Jan 12, 2012 at 5:07 PM by randompete, version 8

Comments

No comments yet.