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)