[feature request] Avoid anonymous sections in case section defined with a block

[ineverov]

It will be useful currently anonymous sections defined with block argument to have a class name.

Proposed solution: deduce_section_class to be rewritten similar to this:

   def deduce_section_class(base_class, &block)                                                                            
       klass = base_class                                                                                                    
       if block_given?                                                                                                       
         const_set(@_last_section_name.to_s.camelcase, Class.new(klass || SitePrism::Section))                               
         klass = const_get(@_last_section_name.to_s.camelcase)                                                               
         klass.class_eval(&block)                                                                                            
       end                                                                                                                   
       return klass if klass                                                                                                 
                                                                                                                             
       raise ArgumentError, "You should provide descendant of \                                                              
 SitePrism::Section class or/and a block as the second argument."                                                            
     end

where @_last_section_name is a name parameter from section/sections call.

Why?

I'm currently working on an internal framework (going to make it public someday) for mobile automation based on site_prism which identify arguments based on element/section name and section/page class name

For example, I have a page object classes defined like this

# module SitePrismDSLExtension extend and override/monkeypatch some basic site_prism DSL methods
class BaseSection < Section
   include SitePrismDSLExtension
end
class BasePage < Section
  include SitePrismDSLExtension
end

class Row < BaseSection
   set_default_search_arguments
   element :column1
   element :column2
end

class Home < BasePage
   element :header
   sections :rows1, Row

   sections :rows2, Row do
      element :column3
   end

   section :rows3, Row do
      element :column4
   end
end

This DSL extension identifies locator based on class name and element name. For example, a locator for column1, column2 and default search args for section Row will be looked in YAML file row.yml;
header, rows1 and rows2 in home.yml;
column3 will be defined in home.yml but nested

header: 
   locator: header_locator
# rows1 may use default locator
rows2: 
  locator: rows2_locator
  column3:
     locator: column3_locator

This allows to extract locators to another abstract layer and use config overlay to define locators based on device or platform (iOS and Android) without defining separate page object for same page structure in case locator differ for specific platform/device.

The logic of mapping depends on the class name. If the page class name is Home it will be looking for locators in home.yml. If section class name is Row it will be looking for locators in row.yml etc.

The problem arise for section definitions like rows2 with section name as well as a block. The actual class won't have a name (anonymous). Finding superclass of this class may slightly help, but will create another issue - row.yml will have to hold locators for all the possible extensions of Row section and it will hold no binding to the parent section/page. To avoid this problem 2 things are needed:

1. Section class should have a name
2. Name of the class should be based on parent section/page name + section name
   For example, for our case, it can be Home::Rows2 < Row and Home::Rows3 < Row

This should not be a breaking change as it only changes internal implementation.

[luke-hill]

In principle this is ok. However I would probably advocate for the following....

• "Anonymous" included in the name somewhere, as it is an anonymous section and that's what we're calling it.
• If it didn't have a random element, then there's a possibility of a name conflict? Need to think about this
• Probably need to log exactly what we're calling it