View definitions:

 

major changes:

• no args
• considered bad form to manipulate args from within a view.
• can return string (as now), but can also return view objects
• new api class method for defining args (tentatively viewpoint)

eg:

 

format :html do

 view :new do :perms=>:create, :tags=>:unknown_ok do |args|

   frame_and_form :create do

      [

        view.name_fieldset.optional,

        view.type_fieldset.optional,

        view.content_fieldsets.optional,

        view.button_fieldset.optional

      ]

    end  

 

  end

 

 viewpoint :new do

   point.optional_help = :show

  ....

 end

 

end

 

Implementation

 

The permissions handling (#2 above) is probably the most straightforward problem and should just require caching permissions checks on the format instance.

 

Getting rid of args should not be too hard, but there are a few considerations:

1. if we continue to use cloning to create subformats, we should store args (or args equivalents) on a single attribute/object (like "point" in the example above) so that we only have to clear one thing with each subformat
2. in general, args set on an inner view should not impact an outer view.  so if :open calls :header calls :title, then setting a "point" in viewpoint :title should not impact the point attribute used further down in the :open view.  To accomplish this, we may want each nested view to clone its args/points.  (We can have a separate format-wide mechanism for cases where we do want inner views to have this power, but it should not be the standard for most arg handling.
3. the api should cleanly represent when we want to override defaults vs only setting values that don't yet exist

 

 

Tentatively, I'm thinking that the view methods themselves should be defined in the set modules so that include_set_modules already sets up the hierarchy.  Those methods need to be executed by the format object (so the methods would need to return proc or lambda objects).

 

Let's say, for example, that a Claim cardtype overrides the "new" view in ...sets/type/claim.rb

 

It might create something like #_html_new in the set module.  The format object could call that method on its card, and retrieve a proc that it could then execute.

 

I'm curious as to whether we can address #5 above and make it so that "super" will trace the ancesors chain in the card's singleton class.  (Haven't worked that out yet)