Nice. Makes a lot of sense, too. Thanks.
One more - is it possible for Elm to access the HTML field values submitted
in the GET request? Or to load its values into an HTML form which is
submitted? I've seen several examples online but they all seem to be either
for earlier versions of Elm or to not actually perform submission.
Mark
On Wednesday, June 22, 2016 at 6:35:06 PM UTC+1, Peter Damoc wrote:
>
> How about modeling your problem differently:
>
> type FieldData
> = DropdownField (List String) -- list of choices
> | FreeformField
> | NumberField Int Int -- min max
>
>
> type alias Field =
> { name : String
> , key : String
> , del : Bool
> , data : FieldData
> }
>
> This way you have easier access to the common fields. :)
>
>
>
> On Wed, Jun 22, 2016 at 8:16 PM, Mark Green <[email protected]
> <javascript:>> wrote:
>
>> Fair enough.
>>
>> The situation is that as part of the view update, my database model is
>> calculating what inputs it needs displayed by passing a form data structure
>> to the view component which renders it in HTML. The current type is:
>>
>> type Field =
>> DropdownField { name: String, key : String, choices: (List String),
>> del: Bool }
>> | FreeformField { name: String, key : String, del: Bool }
>> | NumberField { name: String, key: String, min: Int, max: Int, del:
>> Bool }
>>
>> There's two problems. First of all, there's some common validation done
>> before any field is displayed involving checking that the key exists in the
>> database (which is a Dict) and getting its value. At the moment, in order
>> to do that I have to have a function
>>
>> fieldKey x = case x of
>> DropdownField df -> df.key
>> FreeformField ff -> ff.key
>> NumberField nf -> nf.key
>>
>> which seems a bit awkward. As I understand it I could use a generic
>> record instead by removing the tags on the field types above, but that
>> creates the problem that if the function that does the preprocessing
>> accepts the value as a generic record { key: String } then it can't call
>> the function to render the field because that requires all the components
>> of the record.
>>
>> The second problem is that "del" field. It represents if the field can be
>> deleted or not. It's a pain to have to constantly indicate it when it's in
>> practice the same for all fields in any given form, but having to pass the
>> form as well as the field to the field renderer is rather awkward, and as I
>> understand it Elm doesn't support pointers so I can't put a reference back
>> to the parent form in the field object.
>>
>> Mark
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> There is NO FATE, we are the creators.
> blog: http://damoc.ro/
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
