Range validation enhancement

active/0000-range-enhancement.md

@@ -0,0 +1,83 @@
+- Start Date: 2015-01-15
+- RFC PR: (leave this empty)
+- Revel Issue: (leave this empty)
+
+# Summary
+
+Enhance range validation to include float and int ranges, also limit fractional digits will be an option
+
+# Motivation
+
+Current range validation only works on integers, this will expand revels built in capabilities to validate floats as well.
+
+# Detailed design
+
+The current `range` validator along with `min` and `max` validators only work with integers. This proposal is to change this suite of validators to be floats instead. Integer validation will still be available using the float validator with 0 fractional units. Adding new function names is required to provide unique signatures for the methods to distinguish them from the 
+integer only couter-parts. Structures will be changed to accept floats for comparisons and a new field for limiting the fractional units.
+
+    type Min struct {
+    	Min int
+    	FractionalLimit int
+    }
+
+    type Max struct {
+    	Max int
+    	FractionalLimit int
+    }
+
+Existing functions:
+
+    ValidMin
+    ValidMax
+    ValidRange
+
+New functions added:
+
+    ValidMinFloat
+    ValidMaxFloat
+    ValidRangeFloat
+
+Existing functions will call the Float version with a 0 fractional unit, for example `ValidMax` would call `ValidMaxFloat` with a 0 fractional unit like below
+
+    func ValidMax(max int) MaxSize {
+        return ValidMaxFloat(max, 0);
+    } 
+    func ValidMaxFloatSize(max float64, fractional int) MaxSize {
+        return Max{max, fractional};
+    } 
+
+
+
+# Drawbacks
+
+Adds more code to the code base, by adding this the project gets bigger and more complex
+
+Changing Max, Min structures may cause incompatible issues if people used these structures directly
+
+# Alternatives
+
+Alternatively we let the people implement there own validation
+
+# Unresolved questions
+Question
+Should we add new functions like ValidMaxFloatSize, or should we just allow someone to pass in one or more arguments and decide programmatically what route to take? 
+
+Answer
+We loose runtime checking if we do things programmatically. 
+(Most people seem to be against doing it programmatically)
+
+Question
+Should we modify the internal structures of Max, Min to be a float value ?
+
+Impact in theory should be minimal if we change these, mostly these instances were used internally by the validator, but there may be cases of people using them directly
+
+Answer
+
+Question
+What should the float function signatures look like ?
+
+Answer
+
+
+
+

active/0001-raml.md

@@ -0,0 +1,112 @@
+- Start Date: 2017-03-13
+- RFC PR: 
+- Revel Issue: reve/cmd#73
+
+# Summary
+
+Generate controller and model from RAML api specification
+
+# Motivation
+
+A quick way to generate a restful API with the backbone of revel
+
+# Detailed design
+
+The initial project will only create a **new** application to support the raml specification.
+
+###Controller Generation
+The controller code will be generated based on the root resource for example given the following
+```
+#%RAML 1.0
+title: GitHub API
+version: v3
+baseUri: https://api.github.com
+/user:
+/users:
+  /{userId}:
+    uriParameters:
+      userId:
+        type: integer
+    /followers:
+    /following:
+    /keys:
+      post:
+        /{keyId}:
+          uriParameters:
+            keyId:
+              type: integer
+```
+The following routes are implied
+```
+https://api.github.com/user
+https://api.github.com/users
+https://api.github.com/users/{userId}
+https://api.github.com/users/{userId}/followers
+https://api.github.com/users/{userId}/following
+https://api.github.com/users/{userId}/keys
+https://api.github.com/users/{userId}/keys/{keyId}
+```
+The controllers that would be generated would be 
+
+**user.go** 
+``` 
+type User struct {
+	revel.Controller
+}
+func (c *User) Index() revel.Result {
+return c.RenderJSON({})
+}
+```
+**users.go** 
+``` 
+type Users struct {
+	revel.Controller
+}
+func (c *User) Index() revel.Result {
+return c.RenderJSON({})
+}
+// Conflict with Index generation
+func (c *User) Index1(userId int) revel.Result {
+return c.RenderJSON({})
+}
+func (c *User) Followers(userId int) revel.Result {
+return c.RenderJSON({})
+}
+func (c *User) Following(userId int) revel.Result {
+return c.RenderJSON({})
+}
+func (c *User) Keys(userId int) revel.Result {
+return c.RenderJSON({})
+}
+// Conflict with keys generation
+func (c *User) Keys1(userId int, keyID) revel.Result {
+return c.RenderJSON({})
+}
+
+```
+**routes** 
+``` 
+GET /user User.Index
+GET /users Users.Index
+GET /users/{userId} Users.Index1
+GET /users/{userId}/followers Users.Followers
+GET /users/{userId}/following Users.Following
+POST /users/{userId}/keys Users.Keys
+POST /users/{userId}/keys/{keyId} Users.Keys1
+
+```
+
+# Drawbacks
+
+It is a one shot deal, if the raml changes they need to regenerate the code
+
+# Alternatives
+
+An example of this https://github.com/Jumpscale/go-raml
+
+# Unresolved questions
+
+# Future Considerations
+- Security
+- Generate Models
+- Update existing