And point at http://localhost:8080/wotever/index, the modRel looses its leading slash:
modBase=`/wotever/` modRel=`index`
I know Brian explained that is how the Uri.getRange() method is supposed to work, but from an API consumer point of view, it doesn't feel right. For to write a WebMod that can be used anywhere (in a RouteMod or not), you have to have to cater for both scenarios.
That is the really the special case when there is no base mod nor relative URI to such. So it actually seems correct to me have the modRel be absolute (because its not actually relative to anything). In general you use modBase to construct URIs to within your mod, and modRel to parse your internal URI structure. The leading slash shouldn't effect that does it?
SlimerDudeMon 3 Feb 2014
use modBase to construct URIs to within your mod
Indeed. But what when you use modRel to construct your URIs? As in:
// with RouteMod
uri := req.modBase + req.modRel // --> /wotever/index
// without RouteMod
uri := req.modBase + req.modRel // --> //index
Which, at best, leads to ugly URIs (and may causes errors at worst). Okay, I know I can re-code as:
Or I could also use req.uri - But then I have to know not to use modRel in the above manner. It just seems needlessly error prone.
modRel to parse your internal URI structure. The leading slash shouldn't effect that does it?
Well, it means I have to be careful about what I'm comparing it with:
if (req.modRel == `/index` || req.modRel == `index`) ...
Again, I don't think the WebMod should have to code for both scenarios, for why should it care where it is in the module stack? If it really needs to know, well, it can check modBase!
isRootMod := (req.modBase == `/`)
I don't think the API should return different values dependent on the context of usage; for that either limits its re-use, or complicates the code.
brianMon 3 Feb 2014
// without RouteMod uri := req.modBase + req.modRel // --> //index
If the URIs were added together like that then it would be a bug. It should be handled by the URI class:
fansh> `/` + `/index`
/index
Well, it means I have to be careful about what I'm comparing it with: if (req.modRel == /index || req.modRel == index) ...
I think the proper way to handle that is like this:
req.modRel.path.first == "index"
It just doesn't seem like something we should make a special case considering how Uri getRange works.
SlimerDude Mon 3 Feb 2014
A simple WebMod:
When pointed at
http://localhost:8080/index
, returns:But when I use a
RouteMod
:And point at
http://localhost:8080/wotever/index
, themodRel
looses its leading slash:I know Brian explained that is how the Uri.getRange() method is supposed to work, but from an API consumer point of view, it doesn't feel right. For to write a
WebMod
that can be used anywhere (in aRouteMod
or not), you have to have to cater for both scenarios.(I think I touched upon this in this topic also.)
brian Mon 3 Feb 2014
That is the really the special case when there is no base mod nor relative URI to such. So it actually seems correct to me have the modRel be absolute (because its not actually relative to anything). In general you use modBase to construct URIs to within your mod, and modRel to parse your internal URI structure. The leading slash shouldn't effect that does it?
SlimerDude Mon 3 Feb 2014
Indeed. But what when you use
modRel
to construct your URIs? As in:Which, at best, leads to ugly URIs (and may causes errors at worst). Okay, I know I can re-code as:
Or I could also use
req.uri
- But then I have to know not to usemodRel
in the above manner. It just seems needlessly error prone.Well, it means I have to be careful about what I'm comparing it with:
Again, I don't think the
WebMod
should have to code for both scenarios, for why should it care where it is in the module stack? If it really needs to know, well, it can checkmodBase
!I don't think the API should return different values dependent on the context of usage; for that either limits its re-use, or complicates the code.
brian Mon 3 Feb 2014
If the URIs were added together like that then it would be a bug. It should be handled by the URI class:
I think the proper way to handle that is like this:
It just doesn't seem like something we should make a special case considering how Uri getRange works.