User:Dantman/Skinning system/Regions

The dataAfterContent key (which takes data from the SkinAfterContent hook) has made it somewhat apparent we need some sort of structured regions for blocks of ui or content. dataAfterContent is a rather ugly hack creating an area for extensions like SMW, FlaggedRevs, ArticleComments, etc... to add stuff to the end of the body area. Note that these can't be integrated into the bodytext because catlinks goes in between them on standard skins, however at the same time hardcoding the location of catlinks (or even requiring we use catlinks and not a custom list of categories in a custom location) is counter to the idea of flexible skinning as well. Hence it seems apparent we need a way for skins to define a number of regions, and extensions to define blocks that go in arbitrary regions. Skins would define restrictions on regions, and extensions would define requirements. Both would define preferences, and the skin system would act as a goto deciding where to put the blocks in the regions the skin has given. An idea in list format:

• Skins would specify regions. These may require some class config, or perhaps in the case of templates could be extracted from the markup.These would be extracted from the skin's template. The regions would be defined with things like size=wide (wide areas like the content), size=narrow (narrow areas like sidebars), size=short (stubby areas like a header that shouldn't have too much).
  • In a php skin $w->region('body'); would probably output a region, where somewhere else we define 'body' => array( 'size' => 'wide', 'primary' ).
  • In a template based skin the template would probably just contain <mw:region="body" size=wide primary>
• Extensions would define blocks that should be outputted into regions. Marking requirements like how factboxes, etc... need a wide area, and are meant to be inside the primary location.
• The bodytext and catlinks would be default blocks set to require a wide primary area.
• Skins can define extra preferences for locations of certain blocks. Namely things like removing the catlinks, moving them to a new location, etc...
  • Potentially site users may be given the ability to reorganize these too in skin-specific ways using a message.
• We may need 2 passes for the tree outputter. We'll want to handle mw:if="" in an early pass so that we can make note of when a <mw:region> has been dropped due to a closed if (or rather note the ones we find and skip the ones we don't reach) and redistribute it's content to other regions. We'll also want to explicitly drop a <mw:region> if we find it inside a mw:loop="" as such a thing should be illegal.