<div dir="ltr"><div><p><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">On Mon, Sep 23, 2013 at 8:58 AM, Simon MacMullen</span><span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:13px">�wrote:</span><br>
</p><p>> However, I'd be reluctant to merge this; conceptually
it's very specific to your use case - what if you want to match something
other than up to the first '.'? What if you want to do that on something
other than the resource name?</p><p></p><p>> No, I imagined that. They should though :-)</p></div>Thanks for the feedback. You're right, the compiler didn't complain but your way does makes more sense. I've updated the gist to reflect the changes if anyone is following along.<div>
<br></div><div>
As for use case specificity, I can see your point. Although, I'm struggling to come up with a case where you would want to use a tokenized version of anything other than name. Assuming name is the only thing that makes sense you could potentially have a new attribute called 'prefix_delimiter' which would be sent to the tokens function. If you wanted to add more customization there could be 'prefix_depth' as well which controlled how many tokens were returned.</div>
<div><br></div><div>These would be global settings but they do have a parallel to the native user permission regex matching which I think makes sense. Going inline with the logic like you mentioned would be flexible but I'm not sure how helpful it would be to have individual delimiters for different resource types. Delimiters seem like they would be more of a global decision for the entire broker once a proper group name convention was decided on.</div>
</div>