You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
nonce from the discord server brought up an interesting problem that I think could be solved within the prologue framework:
Often times you have HTTP requests with multipart-formdata.
Currently prologue has a Request.FormData type, that contains the form-data that needs to be parsed. The parsing could be automated, as all you need to know is
The object-type to convert the form data to, which gives you the names and types of the individual fields you'd expect
The form-data itself
So I propose 2 procs:
parseForm for handling the parsing in general, and
toObjectValue for handling the conversion of a single form-field value in string form to the required object-field type.
The signatures would be as follows:
procparseForm*[T: object|refobject](form: FormPart, objectType: typedesc[T], skipFieldNames: staticseq[string] =@[]): T =functoObjectValue*(formValue: string, O: typedesc[Option[<UserDefinedType>]]): O =
Prologue would provide the parseForm proc that takes care of the general logic of transforming FormPart into an object of type T.
That parseForm proc would iterate over the given object type and for each field do the following:
Try to extract the form-field value from FormPart via the object-field name (We could also provide a pragma that allows you to deal with cases where the objcet-field-name and the form-field-name do not match)
Parse the form-field-value into the type of the object-field using the toObjectValue proc for the given field-type
Assign the parsed form-field-value to the object-field
Prologue would also provide a basic set of toObjectValue procs that deal with converting string to fields of type SomeInteger, SomeFloat, string(basically does nothing), bool and their optional versions.
Users can extend the parsing functionality by defining their own toObjectValue procs that would need to be available at the place where parseForm is called.
Finally, it would be possible to "skip" specific fields if there are specific circumstances where they can not be available (yet). One example would be during POST requests where any kind of id field can not have a value yet, and thus should be allowed to be missing from FormData.
Would such a feature still be within the scope of prologue? If so, I'd be willing to implement it, as I have already implemented a very similar version in Snorlogue, though with the names toModelValue and parseFormData.
The text was updated successfully, but these errors were encountered:
An alternative suggestion coming from hotdog was to keep this RFC as a separate package that could be used framework independently to parse one object into another.
It would still have a parseForm proc, but it would implicitly call another fromSource proc, which said package could define for the major frameworks (prologue, jester and maybe nexus once it is released, or entirely unrelated frameworks). I'm not entirely convinced of the value of such an approach as I'm pretty sure that in general other frameworks might have their own solution better tailored to their needs, but it is an option.
nonce from the discord server brought up an interesting problem that I think could be solved within the prologue framework:
Often times you have HTTP requests with multipart-formdata.
Currently prologue has a
Request.FormData
type, that contains the form-data that needs to be parsed. The parsing could be automated, as all you need to know isSo I propose 2 procs:
parseForm
for handling the parsing in general, andtoObjectValue
for handling the conversion of a single form-field value in string form to the required object-field type.The signatures would be as follows:
Prologue would provide the
parseForm
proc that takes care of the general logic of transformingFormPart
into an object of typeT
.That
parseForm
proc would iterate over the given object type and for each field do the following:FormPart
via the object-field name (We could also provide a pragma that allows you to deal with cases where the objcet-field-name and the form-field-name do not match)toObjectValue
proc for the given field-typePrologue would also provide a basic set of
toObjectValue
procs that deal with converting string to fields of typeSomeInteger
,SomeFloat
,string
(basically does nothing),bool
and their optional versions.Users can extend the parsing functionality by defining their own
toObjectValue
procs that would need to be available at the place whereparseForm
is called.Finally, it would be possible to "skip" specific fields if there are specific circumstances where they can not be available (yet). One example would be during POST requests where any kind of
id
field can not have a value yet, and thus should be allowed to be missing fromFormData
.Would such a feature still be within the scope of prologue? If so, I'd be willing to implement it, as I have already implemented a very similar version in Snorlogue, though with the names
toModelValue
andparseFormData
.The text was updated successfully, but these errors were encountered: