Sha256: c7bd877ef10a06ae7fca39ca23e86c71c0d1fd58ea0bc6c86b0b8b80a8fd979d
Contents?: true
Size: 1.44 KB
Versions: 4
Compression:
Stored size: 1.44 KB
Contents
h1. module ModulesInRenderHierarchy Why would we need that? h2. Situation We have a music platform. There we have public profiles, and private profiles. And of each type a band, and a venue profile. Public / Private have different functionality, and also Band / Venue. The chose class structure looks like this: @Public::Base < Project@, @Private::Base < Project@ @Public::Band < Public::Base@, @Public::Venue < Public::Base@, @Private::Band < Private::Base@, @Private::Venue < Private::Base@ To not have duplicate code, we include the functionality for Bands and Venues by using @include BandFunctionality@ and @include VenueFunctionality@. h2. Problem When rendering using the hierarchical rendering, we look up the templates as follows: (For ViewModels::Public::Band#render_as :example, :format => :html) # @views/view_models/public/band/_example.html.erb@ # @views/view_models/public/base/_example.html.erb@ # @views/view_models/project/_example.html.erb@ So the example template is taken from the @public/band@ directory. Why not from a @functionality/band@ directory (assuming the module is named @Functionality::Band@). The reason for this is that the current (v1.5.4) hierarchical rendering process uses superclass, which hops over Modules, rather than using ancestors, which wouldn't. h2. Solution #. Either override superclass, with all associated problems #. Or refit the whole hierarchical rendering into a HierarchicalRendering Class. (Preferred)
Version data entries
4 entries across 4 versions & 1 rubygems