Design Braindumps+views

new( card=..., opts ) # Slots will usually have a card object from DB to work with. but they should also be able to work either without a card, or with a "temporary" card that is "free" from data. (leaning toward "temporary" card approach)

card # provides access to the current card object.

render :view=> viewname, *viewopts # render the given view for the current card. Looks up content view definitions in card data and code views defined in system modules.

render :content => content, *renderopts # this is access point to all rendering operations everywhere in the system. render options include a list of things to process :process=>[:transclusions, :urls, :links, :markup ], options to record refrences, override tranclusion views, etc. Custom rendering could be handled directly in view definition. If a more sophisticated approach is needed, modules could be give the option to create processing steps (or chunktypes in the current architecture) which could then be accessed from calls to render :content in the views. for example a code module might specify processing for markup code which then makes a :process => [ :code ] argument available to all render calls.

render :partial => partial, *partialopts # expect this will be fairly thin wrapper around rails render partial, taking care of making sure the slot object is available, etc. It *might* do some trickery around finding the correct partial but would prefer most of that be handled in layers above so that partial here specifies the actual file location.

subslot( card=..., opts ) # create a nested slot. this is used heavily during transclusion rendering and also in in code view definitions. Once a slot is instantiated with a card the card doesn't change, so this is the access to rendering views on other cards.

innumerable helpers # Slot provides access to all wagn view helpers that are accessed in the context of a current slot and view, as well as all built in rails view helpers.