Design Docs

This page lays out some in-progress brainstorming for getting the module pages correct.

Current challenges

• Extensions do too much / not well organized
• Tight couplings between Extensions
• Extensions mix between external service data fetch and internal structure 'api'
  • The extension knows nothing about how it should end up in GUI
• Manual cache options
• Mixed usage of data types, JSON, YAML, OpenStruct etc. This cause different ways of dealing with differnt data from different sources in the gui

Prototypes

• a specific Extension should only read data from a specific source
• Extensions only return OpenStruct data (what is bound to site/pages)
• 'We/Arquillian Site' can map Behavior objects to a Extension's data to enrich the model

https://gist.github.com/1562684

In short what it does:

• Runtime rewrite OpenStruct class to register Parent/Child relations of added Objects
• Runtime extend Objects stored in OpenStruct based on mapping to add behavior

a = OpenStruct.new
a.b = 'Test' # String
a.b.parent == a
a.b.what_ever_behavior_is_mapped_to_this_path() # /b

Module page rework

• expose the container api (json)
• expose the extensions api (json)
• integrate a how to use with maven/gradle script examples (using the previous apis)
• externally hosted modules integration
• display and integrate the README.x as part of the module page
• display container/extension configuration

But this is where some of the 'arquillian site internals/extension' need some restructuring. (see above)

Currently we basically only have module names+version+core compile v..