The PR adds to options to the constructor of the EmbeddedFormRenderer, namespace and paths.
The namespace option simplifies setup by giving the option to let the renderer do the namespace filtering of the container, so you don't having to setup a new container class to do this.
The paths option lets you setup form views in folders and traverse each when looking for a key. This gives us the ability to organise the views into folders, as well as setup views for different contexts. So if, for example, there is an article template in a newsletter folder and a general folder, setting up the newsletter renderer with paths: ["newsletter", "general"] would resolve the template in the newsletter folder. But the newsletter renderer could also use the views in the general folder.
Note: I have also included a commit for the updated dry-validation support that was in another branch, as this was need to get the specs passing with dry-validation ~> 1.0
The PR adds to options to the constructor of the EmbeddedFormRenderer,
namespaceandpaths.The
namespaceoption simplifies setup by giving the option to let the renderer do the namespace filtering of the container, so you don't having to setup a new container class to do this.The paths option lets you setup form views in folders and traverse each when looking for a key. This gives us the ability to organise the views into folders, as well as setup views for different contexts. So if, for example, there is an article template in a newsletter folder and a general folder, setting up the newsletter renderer with
paths: ["newsletter", "general"]would resolve the template in thenewsletterfolder. But the newsletter renderer could also use the views in thegeneralfolder.Note: I have also included a commit for the updated dry-validation support that was in another branch, as this was need to get the specs passing with dry-validation ~> 1.0