The SegmentLayer and UriLayer

Another layer idea I've been playing with is the UriLayer. The basic idea here is to give every Faceted part in the model a hierarchical path-based URI. This will allow for another way of modeling relationships (by embedding URIs in models, similar to how we did it with "spans" in the SpanLayer) and can serve as a basis for inter-model references (or external references to model parts).

Here again I'll assign bits of the Gem syntax to assist. If the first child in a Group or Root element is a Word that has a ~ suffix, then it will be treated as the segment of the URI path for the Group or Root element, otherwise the segment will just be the index number of the Faceted part.... Ok that sounds a bit complicated, so here's the text for a model:

foo~ (barX~ a b [baz~] ) (barY~ b)

and here's a look at the model:



So the idea is that foo~, barX~, etc. are Words with the ~ suffix and appear first in their Group, therefore they have been used to name the SegmentFacet of their Group. The SegmentFacets that don't get a name this way simply get a number instead.

The UriLayer itself simply gives us a view of the URI assigned to every Faceted part by walking up to the Model part and concatenating each SegmentFacet value on the way:



The images above are showing Figures but not Sites. Let's look at both for the SegmentLayer:



So all Sites have '/' as the SegmentFacet value except for the Model which has '!'. The idea here is that if the Environment is asked to resolve a URI it can split it around the '!' and look at the first part to find a model and then hand the second part to the model's UriLayer to resolve in the context of that model.

The vague plan...

I've thought about adding an abstract UriQueryLayer where its UriQueryFacet would have a method like handle(String uriQuery). This would allow for resolving a URI (with the UriLayer) and handing the parameters to the resolved part to do .... whatever (you would subclass UriQueryFacet to provide domain-specific implementations).

With this group of layers you could imagine using a model to power a servlet. Incoming URLs could be directed to a UriQueryFacet for processing. The behavior of this servlet can vary based on the structure of the model (used to encode state) and the implementation of the UriQueryFacet (used to encode behavior).