If you're in this deep, you probably know what Wagn "views" are.  Things like open, closed, content, core, raw, etc.  And you probably know what Wagn Set are.  Things like *all, User+*type, Wagn Modules+*self.

 

Our views API is principly concerned with configuring specific views for specific Set of cards.  And most of doing so boils down to a single method call:

view( viewname [, args] ) &block

If you've worked with Wagn layouts, you've encountered some builtin cards, like *head, *foot, *version, etc.   These are cards whose database content is irrelevant -- it is entirely overridden by the modules.  So we start with the bottom of the view food chain -- :raw.

 

Here's how we configure the *version card to have *version as its content:

#file: lib/wagn/set/self/version.rb

view :raw do |args| Wagn::Version.full end

Naturally other views are built on this view.  :core uses :raw, :content, :open, and :titled all use :core. 

 

Similarly, :closed uses :closed_content which also uses :core.  You may have noticed that HTML cards are rendered as "blank" when they're closed.  This is how we specify that:

#file: lib/wagn/set/type/html.rb

view :closed_content do |args|
''
end

 

Your view methods have access to a "card" object, referring the card being viewed, as in the following very simple example which sets the default behavior for the "name" view:

#file: lib/wagn/set/all/base.rb

view :name do |args|
card.name
end

Views also have access to a "form" object, which has access to ActionView helper methods.  Creating an editor view in the following manner will suffice to configure a custom editor that will appear in both single-edit and multi-edit contexts:

#file: lib/wagn/set/type/phrase.rb

view :editor do |args| form.text_field :content, :class=>'phrasebox' end

 

You will also have access to methods to refer to other views.  Here's an example of how to create the 'core' view for a Toggle card:

#file: lib/wagn/set/type/toggle.rb

view :core do |args| case render(:raw).to_i when 1; 'yes' when 0; 'no' else ; '?' end end

The "render(:raw)" method provides the "raw" content of the card (which is stored as a 1 or 0), and then the core view converts it into yes/no.  You actually have two equivalent options for rendering views defined with the #view method:

 

render :viewname
render_viewname

 

You will notice that very few views will be overridden with any frequency.  Primarily it will be :raw, :core, :closed_content, and :editor.  Those names (especially "core") are still under discussion.  

 

You can, in principle, override other views such as :open, :closed, :content, etc, but it is much more involved to do so and preserve behavior like our current behavior.  

 

You can also easily create new views with this API -- you just put your own view name as the first argument, and there it is -- but we encourage you to consider first whether your need isn't better met through more conventional means (eg. a new type)

 

Wagn 2.0 will allow for nuanced support of different file formats (HTML, HTML+javascript, plain text, csv, kml, etc), and this will all be handled with the view hierarchy.  For example, let's take a very simple view: "link".   Many file formats will probably just expect a full url when a link view is requested.  Something like this (below is a simplication):

view :link do |args|
  base_url + card.name.to_url_key
end

That's fine for a plain text view, but in typical wagn usage, that view will need to produce an HTML link.  So we might set that up as follows (NOTE - this is a simplification of the actual code)

format :html do
view :link do
   %{<a class="known-card" href="/#{card.name.to_url_key}">#{card.name}</a>}
  end
end

When no format is specified, the view is defined generically for all formats; when specified, the view is defined for just the format given (and will override generic views)