[elm-discuss] Re: http.post gives BadResponse 415 "Unsupported Media Type"

[danneu]

You can use `Http.send` with a custom request object to set arbitrary 
headers.

Here's an example that send an application/json POST request.

judgeImage : Judgement -> Image -> Cmd Msg
judgeImage judgement image =
  let
url = "http://localhost:3000/id/"; ++ (toString image.id) ++ "/judge"
body = 
  case judgement of
Keep -> Http.string "KEEP"
Delete -> Http.string "DELETE"
Fave -> Http.string "FAVE"
request : Http.Request
request = 
  { verb = "POST"
  , headers = [ ("Content-Type", "application/json") ]
  , url = url
  , body = body
  }
  in
Task.perform
JudgeFail
(\_ -> JudgeSucceed judgement image)
(Http.send Http.defaultSettings request)

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: http.post gives BadResponse 415 "Unsupported Media Type"

[Dirk Vaneynde]

Found out that Http.post sends it as 'text/plain' mime, not as 
'application/json'. Strange, since it expects a JSON response.

Is there a way to force that?

Op zaterdag 2 juli 2016 00:21:58 UTC+2 schreef Dirk Vaneynde:
>
> Hi, I try to post some json via ELM to a java server with jax-rs, 
> consuming application/json.
>
> It works fine using curl: 
>
> curl -vH "Content-Type: application/json" -X POST -d '{"robotOn": true}' 
> http://localhost:8080/domo/screenRobotUpdate
>
> But it returns 415 error code when using the following simple elm code:
>
> updateInfo: Model -> Task Http.Error String
> updateInfo model =
>   *Http.post Json.Decode.string urlPost (Http.string """{"robotOn": 
> false}""")*
>
> I'm already in a bad mood since Belgium lost to Wales, so help is 
> appreciated :)
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] http.post gives BadResponse 415 "Unsupported Media Type"

[Dirk Vaneynde]

Hi, I try to post some json via ELM to a java server with jax-rs, consuming 
application/json.

It works fine using curl: 

curl -vH "Content-Type: application/json" -X POST -d '{"robotOn": true}' 
http://localhost:8080/domo/screenRobotUpdate

But it returns 415 error code when using the following simple elm code:

updateInfo: Model -> Task Http.Error String
updateInfo model =
  *Http.post Json.Decode.string urlPost (Http.string """{"robotOn": 
false}""")*

I'm already in a bad mood since Belgium lost to Wales, so help is 
appreciated :)

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: [ANN] elm-mdl 6.0.0 released

[Maxwell Gurewitz]

Wow looks really slick!

On Monday, June 27, 2016 at 7:58:18 AM UTC-7, debois wrote:
>
> Dear all, 
>
> Version 6.0.0 of elm-mdl is out—check out the live demo 
> . The new version comprises multiple 
> bug-fixes and enhancements, and 6(!) new components: Footers, Spinners, 
> Progress, Toggles, Tables & Tooltips. 
>
> Package here , 
> github here .
>
> Credits
>
> 1. Alexander Foremny (@aforemny), core contributor, commit-rights. 
>
> In a *massive* and very sophisticated contribution for this 
> release,
> Alexander contributed both numerous minor fixes and four entirely 
> new
> components: Menus, Tables, Progress bar, Spinner.  
>
> 2. Ville Penttinen (@vipentti), new contributor
>
> In an impressive initial contribution, Ville contributed both
> demo work, multiple enhancements to Layout Textfield, and two new
> components, Footer & Tooltip. all produced in an impressively short
> span of time. 
>
> 3. @SauceWaffle, new contributor.
>
> Very useful customisation of Menu icon.
>
> 4. Petre Damoc (@pdamoc), new contributor.
>
> Bugfixes to subtle CSS interaction problems in Layout. 
>
> 5. Søren Debois (@debois), original author. 
> 
> Remaining components, demo work, lots of bug fixes. I also 
> likely introduced any bugs you might find.
>
> Thanks to all contributors, new as old, including from previous releases!
> Elm-mdl is rapidly approaching a comprehensive and usable UI toolkit; this 
> is because of you. For that, I am very grateful. 
>
> Cheers,
>
> Søren
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: [ANN] elm-mdl 6.0.0 released

[Rindra Ramamonjison]

This is one of the best things that happen to Elm this year for two reasons:

- a beginner can build shiny apps without learning about many moving parts
- an intermediate elmlang user can go through the src code and learn how to 
build components with elm-parts

Kudos!


On Monday, June 27, 2016 at 7:58:18 AM UTC-7, debois wrote:
>
> Dear all, 
>
> Version 6.0.0 of elm-mdl is out—check out the live demo 
> . The new version comprises multiple 
> bug-fixes and enhancements, and 6(!) new components: Footers, Spinners, 
> Progress, Toggles, Tables & Tooltips. 
>
> Package here , 
> github here .
>
> Credits
>
> 1. Alexander Foremny (@aforemny), core contributor, commit-rights. 
>
> In a *massive* and very sophisticated contribution for this 
> release,
> Alexander contributed both numerous minor fixes and four entirely 
> new
> components: Menus, Tables, Progress bar, Spinner.  
>
> 2. Ville Penttinen (@vipentti), new contributor
>
> In an impressive initial contribution, Ville contributed both
> demo work, multiple enhancements to Layout Textfield, and two new
> components, Footer & Tooltip. all produced in an impressively short
> span of time. 
>
> 3. @SauceWaffle, new contributor.
>
> Very useful customisation of Menu icon.
>
> 4. Petre Damoc (@pdamoc), new contributor.
>
> Bugfixes to subtle CSS interaction problems in Layout. 
>
> 5. Søren Debois (@debois), original author. 
> 
> Remaining components, demo work, lots of bug fixes. I also 
> likely introduced any bugs you might find.
>
> Thanks to all contributors, new as old, including from previous releases!
> Elm-mdl is rapidly approaching a comprehensive and usable UI toolkit; this 
> is because of you. For that, I am very grateful. 
>
> Cheers,
>
> Søren
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Adding a transformation layer to the Elm Architecture

[Robert Walter]

Hi Peter,

this exchange already helped me to understand some of the nuances of the 
Elm architecture better, thank you.
I'm actually implementing a lot in Elm recently, and while I think writing 
code is the best way to learn a new technology, it also helps to exchange 
with peers from time to time (just writing and looking at code makes me 
blind to the obvious ;)).

So yeah, I will keep trying and see how far I can get with your advice. 
Thanks.


On Friday, July 1, 2016 at 4:07:16 PM UTC+2, Peter Damoc wrote:
>
> Robert, 
>
> What you are describing here can be modeled with current technologies and 
> it relates to the composition that is usually found in The Elm 
> Architecture. 
> Take a look a the nesting examples:
> https://github.com/evancz/elm-architecture-tutorial/tree/master/nesting
>
> These multiple domains that you describe could be modeled either side by 
> side using some kind of record structure or in a hierarchy where one has 
> nested domains. 
>
> One could conceivably have components that have behavior only (only the 
> model, the update and the subscriptions but no view) and that can be 
> interrogated with functions by some parent view. 
>
> The App.program signature is like the border of the App. It specifies what 
> all the small bits of your program need to compose to. What you do inside 
> your program is entirely up to you. 
>
> This is why I suggested that you actually try to implement something. 
> You might be surprised to discover that Elm is actually more powerful than 
> you first thought. 
>
>
>
>
> On Fri, Jul 1, 2016 at 4:35 PM, Robert Walter  > wrote:
>
>> Hi Peter,
>>
>> thanks for the response, it might very well be that Elm already has all 
>> the capabilities necessary and I'm just not aware of it. Frankly, ports are 
>> something I definitely have to look into in more detail before responding 
>> properly to your suggestions.
>>
>> While it is possible to chain transformations in the view callback (as 
>> you showed), it seems a bit kludgy to do this. By design, the view function 
>> returns a "Html msg", so a better description (compared to my initial post) 
>> of it would be that it is a wrapper around an app's transformation pipeline 
>> with a clearly defined input (Model) and output (Html msg). 
>> Adding an explicit "transformations" callback would allow to decouple the 
>> model and the transformation pipeline a bit (as I understand it, 
>> Html.App.program makes it mandatory to have the same model type for init, 
>> update, view, and subscriptions). I'm not saying that this is bad or 
>> anything, I just try to explore some ideas. The idea is to have "update" 
>> and "subscriptions" for each intermediate domain. 
>>
>> Imagine a domain A which I don't want to render directly, but transform 
>> its models into models of an intermediate domain "B". Third party 
>> developers could pick up this "piece of the chain" and use it's output "B" 
>> as input to their own programs, enhance the models with their own concepts 
>> and render everything however they please. They could still send messages 
>> to my model of "A" and it would update according to the logic in its 
>> "update" function, transform it to a model of "B", which is then further 
>> processed by their own transformation(s).
>>
>> Yes, this is all very theoretical and I should try to think of some more 
>> specific use cases. And I need to learn more about Elm ports and Effect 
>> Managers.
>>
>> Best,
>> Robert
>>  
>>
>> On Friday, July 1, 2016 at 1:50:17 PM UTC+2, Peter Damoc wrote:
>>>
>>> Hi Robert, 
>>>
>>> I'm trying to understand what you are requesting and I keep seeing 
>>> records/ADT for domains and plain old functions for the transformations. 
>>> In other words, I don't really understand what is the show stopper here. 
>>>  
>>>
>>> For example, let's say that you want to transform the model into a text 
>>> only representation and into some sort of audio output and send those to 
>>> some other output devices. 
>>> This can easily be accomplished by adding a textOnly port and an audio 
>>> port and returning from `update` a Cmd.batch of the commands to these 
>>> ports. 
>>>
>>> If you don't want ports you could probably use some Effect Manager to 
>>> produce the commands. 
>>>
>>> Also, if you want the model to pass through several transformations 
>>> before generating the output, you can easily to that like: 
>>>
>>> view model = 
>>> model 
>>> |> firstTransformation 
>>> |> secondTransformation arg1 arg2 
>>> |> finalTransformation
>>>
>>> Maybe if you try to implement what you want and reach a point where you 
>>> would like to write something and cannot because of current limitations, 
>>> you could present some mock code with how you would want things to be. 
>>>
>>>
>>>
>>>
>>> On Fri, Jul 1, 2016 at 1:03 PM, Robert Walter  
>>> wrote:
>>>
 Hello all,

 not having a strong web development background, but rather coming from 
 the area of d

[elm-discuss] Re: Communicating from parent to child and child to parent

[Wouter In t Velt]

Hi Rex,

I hope I interpret your setup correctly, but it looks like the flow is more 
or less:


   - user clicks a button inside child
   - this triggers child's update function
   - child's update function stores updates child model (with a message 
   Click)
   - the parent can then access the new function by accessing the child's 
   model
   
What I do not understand is: you mention an UpdateButton message that the 
parent responds to,

But what triggers this message?

Typically, the parent does not know or care about child model contents or 
child model updates. The parent receives child messages, but parent does 
not read child messages. Parent simply passes the messages on to the 
child's update function, and stores the updated child model.

 

This separation guarantees that you can modify code in your child component 
(e.g. change the child model, add new message types etc), and any parent 
will continue to work properly. No need to check or change code in any 
other component that imports the child.

If any parent 'looks inside' the model or the messages of the child, then 
this guarantee breaks down.

 

The discussion here (or at least my interest in this) is:

How do I communicate a message from a child to parent, while at the same 
time maintaining the integrity of the child's model (so no peeking by 
parents into child model)?

 

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Communicating from parent to child and child to parent

[Wouter In t Velt]

I hope I interpret your setup correctly, but it looks like the flow is more 
or less:

   - user clicks a button inside child
   - this triggers child's update function
   - child's update function stores updates child model (with a message 
   Click)
   - the parent can then access the new function by accessing the child's 
   model

What I do not understand is: you mention an UpdateButton message that the 
parent responds to,
But what triggers this message?
Typically, the parent does not know or care about child model contents or 
child model updates. The parent receives child messages, but parent does 
not read child messages. Parent simply passes the messages on the child's 
update function, and stores the updated child model.

This separation guarantees that you can modify code in your child component 
(e.g. change the child model, add new message types etc), and any parent 
will continue to work properly. No need to check or change code in any 
other component that imports the child.
If any parent 'looks inside' the model or the messages of the child, then 
this guarantee breaks down.

The discussion here (or at least my interest in this) is:
How do I communicate a message from a child to parent, while at the same 
time maintaining the integrity of the child's model (so no peeking by 
parents into child model)?

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Adding a transformation layer to the Elm Architecture

[Peter Damoc]

Robert,

What you are describing here can be modeled with current technologies and
it relates to the composition that is usually found in The Elm
Architecture.
Take a look a the nesting examples:
https://github.com/evancz/elm-architecture-tutorial/tree/master/nesting

These multiple domains that you describe could be modeled either side by
side using some kind of record structure or in a hierarchy where one has
nested domains.

One could conceivably have components that have behavior only (only the
model, the update and the subscriptions but no view) and that can be
interrogated with functions by some parent view.

The App.program signature is like the border of the App. It specifies what
all the small bits of your program need to compose to. What you do inside
your program is entirely up to you.

This is why I suggested that you actually try to implement something.
You might be surprised to discover that Elm is actually more powerful than
you first thought.




On Fri, Jul 1, 2016 at 4:35 PM, Robert Walter 
wrote:

> Hi Peter,
>
> thanks for the response, it might very well be that Elm already has all
> the capabilities necessary and I'm just not aware of it. Frankly, ports are
> something I definitely have to look into in more detail before responding
> properly to your suggestions.
>
> While it is possible to chain transformations in the view callback (as you
> showed), it seems a bit kludgy to do this. By design, the view function
> returns a "Html msg", so a better description (compared to my initial post)
> of it would be that it is a wrapper around an app's transformation pipeline
> with a clearly defined input (Model) and output (Html msg).
> Adding an explicit "transformations" callback would allow to decouple the
> model and the transformation pipeline a bit (as I understand it,
> Html.App.program makes it mandatory to have the same model type for init,
> update, view, and subscriptions). I'm not saying that this is bad or
> anything, I just try to explore some ideas. The idea is to have "update"
> and "subscriptions" for each intermediate domain.
>
> Imagine a domain A which I don't want to render directly, but transform
> its models into models of an intermediate domain "B". Third party
> developers could pick up this "piece of the chain" and use it's output "B"
> as input to their own programs, enhance the models with their own concepts
> and render everything however they please. They could still send messages
> to my model of "A" and it would update according to the logic in its
> "update" function, transform it to a model of "B", which is then further
> processed by their own transformation(s).
>
> Yes, this is all very theoretical and I should try to think of some more
> specific use cases. And I need to learn more about Elm ports and Effect
> Managers.
>
> Best,
> Robert
>
>
> On Friday, July 1, 2016 at 1:50:17 PM UTC+2, Peter Damoc wrote:
>>
>> Hi Robert,
>>
>> I'm trying to understand what you are requesting and I keep seeing
>> records/ADT for domains and plain old functions for the transformations.
>> In other words, I don't really understand what is the show stopper here.
>>
>> For example, let's say that you want to transform the model into a text
>> only representation and into some sort of audio output and send those to
>> some other output devices.
>> This can easily be accomplished by adding a textOnly port and an audio
>> port and returning from `update` a Cmd.batch of the commands to these
>> ports.
>>
>> If you don't want ports you could probably use some Effect Manager to
>> produce the commands.
>>
>> Also, if you want the model to pass through several transformations
>> before generating the output, you can easily to that like:
>>
>> view model =
>> model
>> |> firstTransformation
>> |> secondTransformation arg1 arg2
>> |> finalTransformation
>>
>> Maybe if you try to implement what you want and reach a point where you
>> would like to write something and cannot because of current limitations,
>> you could present some mock code with how you would want things to be.
>>
>>
>>
>>
>> On Fri, Jul 1, 2016 at 1:03 PM, Robert Walter 
>> wrote:
>>
>>> Hello all,
>>>
>>> not having a strong web development background, but rather coming from
>>> the area of domain-specific languages, model-driven development, and IDE
>>> development (i.e. building tools for developers and development platforms),
>>> Elm made me curious because of a lot of the ideas and features that are
>>> built into the language that I know from other technologies. While I
>>> understand that Elm is specifically targeted to make the lives of front-end
>>> web developers easier and offer them an alternative to JavaScript and the
>>> zoo of libraries there, I'd like to discuss if Elm could become even bigger
>>> eventually (especially given technologies like Electron that allow us
>>> easily to target the desktop as well).
>>>
>>> One of the key selling points for me is the thoroughness that is used 

Re: [elm-discuss] Adding a transformation layer to the Elm Architecture

[Robert Walter]

Hi Peter,

thanks for the response, it might very well be that Elm already has all the 
capabilities necessary and I'm just not aware of it. Frankly, ports are 
something I definitely have to look into in more detail before responding 
properly to your suggestions.

While it is possible to chain transformations in the view callback (as you 
showed), it seems a bit kludgy to do this. By design, the view function 
returns a "Html msg", so a better description (compared to my initial post) 
of it would be that it is a wrapper around an app's transformation pipeline 
with a clearly defined input (Model) and output (Html msg). 
Adding an explicit "transformations" callback would allow to decouple the 
model and the transformation pipeline a bit (as I understand it, 
Html.App.program makes it mandatory to have the same model type for init, 
update, view, and subscriptions). I'm not saying that this is bad or 
anything, I just try to explore some ideas. The idea is to have "update" 
and "subscriptions" for each intermediate domain. 

Imagine a domain A which I don't want to render directly, but transform its 
models into models of an intermediate domain "B". Third party developers 
could pick up this "piece of the chain" and use it's output "B" as input to 
their own programs, enhance the models with their own concepts and render 
everything however they please. They could still send messages to my model 
of "A" and it would update according to the logic in its "update" function, 
transform it to a model of "B", which is then further processed by their 
own transformation(s).

Yes, this is all very theoretical and I should try to think of some more 
specific use cases. And I need to learn more about Elm ports and Effect 
Managers.

Best,
Robert
 

On Friday, July 1, 2016 at 1:50:17 PM UTC+2, Peter Damoc wrote:
>
> Hi Robert, 
>
> I'm trying to understand what you are requesting and I keep seeing 
> records/ADT for domains and plain old functions for the transformations. 
> In other words, I don't really understand what is the show stopper here.  
>
> For example, let's say that you want to transform the model into a text 
> only representation and into some sort of audio output and send those to 
> some other output devices. 
> This can easily be accomplished by adding a textOnly port and an audio 
> port and returning from `update` a Cmd.batch of the commands to these 
> ports. 
>
> If you don't want ports you could probably use some Effect Manager to 
> produce the commands. 
>
> Also, if you want the model to pass through several transformations before 
> generating the output, you can easily to that like: 
>
> view model = 
> model 
> |> firstTransformation 
> |> secondTransformation arg1 arg2 
> |> finalTransformation
>
> Maybe if you try to implement what you want and reach a point where you 
> would like to write something and cannot because of current limitations, 
> you could present some mock code with how you would want things to be. 
>
>
>
>
> On Fri, Jul 1, 2016 at 1:03 PM, Robert Walter  > wrote:
>
>> Hello all,
>>
>> not having a strong web development background, but rather coming from 
>> the area of domain-specific languages, model-driven development, and IDE 
>> development (i.e. building tools for developers and development platforms), 
>> Elm made me curious because of a lot of the ideas and features that are 
>> built into the language that I know from other technologies. While I 
>> understand that Elm is specifically targeted to make the lives of front-end 
>> web developers easier and offer them an alternative to JavaScript and the 
>> zoo of libraries there, I'd like to discuss if Elm could become even bigger 
>> eventually (especially given technologies like Electron that allow us 
>> easily to target the desktop as well). 
>>
>> One of the key selling points for me is the thoroughness that is used to 
>> identify what we know as the Elm Architecture. Elm guides you to define a 
>> model of your "world" and to specify how this model changes ("update") due 
>> to effects from outside or inside ("subscriptions" and "commands"). Also, 
>> you define how the model is going to be presented to the user ("view"). And 
>> Elm takes care of wiring these components together. It's great and I see 
>> Elm as a great language not only for veterans, but also for beginners!
>>
>> In model-driven development, there are a lot of similarities, but also 
>> some differences. Often, your world is made up of several domains ("model 
>> schemas"), and you define transformations from one domain to the other. 
>> That means applications are composed of domains that are wired by 
>> transformations. A system that allows you to build applications that work 
>> that way is MPS, by Jetbrains , in case 
>> you would like to see an example.
>>
>> One could say that we have a simplified version of that in the Elm 
>> Architecture, where we define one domain ("model"

[elm-discuss] Re: Adding a transformation layer to the Elm Architecture

[Ambrose Laing]

Could you do something like this:

Tell the Elm Architecture (as it is right now) that your model is

(modelA, modelB)

where modelA is the type that you want to have as a "stage1" domain, and 
modelB is what you want for your "stage2".

And then as Peter Damoc suggested, compose functions to achieve what you 
want.  The update function will be made up of two parts, f1, which looks at 
the pair, but updates modelA only, based on the Msgs, and lets the modelB 
pass through unmodified.  The second function will be f2, which updates 
modelB while only looking at modelA, and ignoring the Msgs.  Then you tell 
the Elm Architecture (in the initialization) that the update function is f1 
andThen f2.  Then you write your view function to only look at the modelB 
part of what Elm thinks the model is.  I am not using exact syntax, but I 
am quite certain that something similar to this could be gotten to work, 
without changing the underlying architecture itself.

If you could get this to work, it would have the advantage that if someone 
else comes along with even more complicated requirements for a three-stage 
transformation, or even a tree-like non-linear number of stages, it can 
still be modeled in a similar fashion without changing the base Elm 
architecture.  Just an idea to try to flesh out.





On Friday, July 1, 2016 at 6:03:44 AM UTC-4, Robert Walter wrote:
>
> Hello all,
>
> not having a strong web development background, but rather coming from the 
> area of domain-specific languages, model-driven development, and IDE 
> development (i.e. building tools for developers and development platforms), 
> Elm made me curious because of a lot of the ideas and features that are 
> built into the language that I know from other technologies. While I 
> understand that Elm is specifically targeted to make the lives of front-end 
> web developers easier and offer them an alternative to JavaScript and the 
> zoo of libraries there, I'd like to discuss if Elm could become even bigger 
> eventually (especially given technologies like Electron that allow us 
> easily to target the desktop as well). 
>
> One of the key selling points for me is the thoroughness that is used to 
> identify what we know as the Elm Architecture. Elm guides you to define a 
> model of your "world" and to specify how this model changes ("update") due 
> to effects from outside or inside ("subscriptions" and "commands"). Also, 
> you define how the model is going to be presented to the user ("view"). And 
> Elm takes care of wiring these components together. It's great and I see 
> Elm as a great language not only for veterans, but also for beginners!
>
> In model-driven development, there are a lot of similarities, but also 
> some differences. Often, your world is made up of several domains ("model 
> schemas"), and you define transformations from one domain to the other. 
> That means applications are composed of domains that are wired by 
> transformations. A system that allows you to build applications that work 
> that way is MPS, by Jetbrains , in case 
> you would like to see an example.
>
> One could say that we have a simplified version of that in the Elm 
> Architecture, where we define one domain ("model") and one transformation 
> ("view") in which we transform our "domain model" to a "rendering model", 
> that is passed on to a rendering engine for display.
>
> So, some of you might say "that's all nice and good, but why do you bring 
> it up"? Well, I really think that there is a lot of potential in the idea 
> of model-driven development and projectional editing and I feel like Elm 
> would be an interesting technology to build something like this on due to 
> its functional nature and thoroughness put into its architecture. I'd like 
> to discuss this with the community. 
>
> To make things a bit more specific, I wonder what you think about 
> generalizing the Elm Architecture in a way that we not only transform from 
> a domain model to a Html model (a.k.a. view), but to allow for a series of 
> transformations if necessary. I like that the current architecture allows 
> us to do something like that to a certain degree. Looking at the Mdl 
> package for example, I consider this a "Widget domain" and I can 
> incorporate it into my "view" function, basically reusing portions of their 
> "domain model to Html" transformation for my own purpuses.
> But if I want to use Elm to transform gradually from a model of low 
> abstraction to Html via intermediate domains, it is hard to do. A 
> suggestion would be to have an optional callback called "transformations" 
> that takes in a model of type A and spits out a model of type B, which is 
> then again used as input for the final transformation step, which would 
> still be "view". Optional means that, if no transformation is defined, A == 
> B.
>
> I hope all of this does make a little bit of sense to some of you and I 
> really hope it is not too co

Re: [elm-discuss] Adding a transformation layer to the Elm Architecture

[Peter Damoc]

Hi Robert,

I'm trying to understand what you are requesting and I keep seeing
records/ADT for domains and plain old functions for the transformations.
In other words, I don't really understand what is the show stopper here.

For example, let's say that you want to transform the model into a text
only representation and into some sort of audio output and send those to
some other output devices.
This can easily be accomplished by adding a textOnly port and an audio port
and returning from `update` a Cmd.batch of the commands to these ports.

If you don't want ports you could probably use some Effect Manager to
produce the commands.

Also, if you want the model to pass through several transformations before
generating the output, you can easily to that like:

view model =
model
|> firstTransformation
|> secondTransformation arg1 arg2
|> finalTransformation

Maybe if you try to implement what you want and reach a point where you
would like to write something and cannot because of current limitations,
you could present some mock code with how you would want things to be.




On Fri, Jul 1, 2016 at 1:03 PM, Robert Walter 
wrote:

> Hello all,
>
> not having a strong web development background, but rather coming from the
> area of domain-specific languages, model-driven development, and IDE
> development (i.e. building tools for developers and development platforms),
> Elm made me curious because of a lot of the ideas and features that are
> built into the language that I know from other technologies. While I
> understand that Elm is specifically targeted to make the lives of front-end
> web developers easier and offer them an alternative to JavaScript and the
> zoo of libraries there, I'd like to discuss if Elm could become even bigger
> eventually (especially given technologies like Electron that allow us
> easily to target the desktop as well).
>
> One of the key selling points for me is the thoroughness that is used to
> identify what we know as the Elm Architecture. Elm guides you to define a
> model of your "world" and to specify how this model changes ("update") due
> to effects from outside or inside ("subscriptions" and "commands"). Also,
> you define how the model is going to be presented to the user ("view"). And
> Elm takes care of wiring these components together. It's great and I see
> Elm as a great language not only for veterans, but also for beginners!
>
> In model-driven development, there are a lot of similarities, but also
> some differences. Often, your world is made up of several domains ("model
> schemas"), and you define transformations from one domain to the other.
> That means applications are composed of domains that are wired by
> transformations. A system that allows you to build applications that work
> that way is MPS, by Jetbrains , in case
> you would like to see an example.
>
> One could say that we have a simplified version of that in the Elm
> Architecture, where we define one domain ("model") and one transformation
> ("view") in which we transform our "domain model" to a "rendering model",
> that is passed on to a rendering engine for display.
>
> So, some of you might say "that's all nice and good, but why do you bring
> it up"? Well, I really think that there is a lot of potential in the idea
> of model-driven development and projectional editing and I feel like Elm
> would be an interesting technology to build something like this on due to
> its functional nature and thoroughness put into its architecture. I'd like
> to discuss this with the community.
>
> To make things a bit more specific, I wonder what you think about
> generalizing the Elm Architecture in a way that we not only transform from
> a domain model to a Html model (a.k.a. view), but to allow for a series of
> transformations if necessary. I like that the current architecture allows
> us to do something like that to a certain degree. Looking at the Mdl
> package for example, I consider this a "Widget domain" and I can
> incorporate it into my "view" function, basically reusing portions of their
> "domain model to Html" transformation for my own purpuses.
> But if I want to use Elm to transform gradually from a model of low
> abstraction to Html via intermediate domains, it is hard to do. A
> suggestion would be to have an optional callback called "transformations"
> that takes in a model of type A and spits out a model of type B, which is
> then again used as input for the final transformation step, which would
> still be "view". Optional means that, if no transformation is defined, A ==
> B.
>
> I hope all of this does make a little bit of sense to some of you and I
> really hope it is not too controversial.
>
> Best,
> Robert
>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com.
> F

Re: [elm-discuss] combining union types

[Janis Voigtländer]

No. You can only do to Msg what you already did to PageMsg and LibMsg (through 
tagging *their* message "subtypes").

> Am 01.07.2016 um 11:43 schrieb jonathan de montalembert :
> 
> Is there a way to combine two Msg into one? Like (not working)
> 
>> type PageMsg
>>   = HomeMsg Home.Msg
>>   | ArchiveMsg Archive.Msg
>  
>> type LibMsg 
>>   = TranslationMsg Translation.Msg
>>   | PhoenixMsg Phoenix.Msg
>  
>> type Msg
>>   = PageMsg
>>   | LibMsg
> 
> then have 
> 
>> update: Msg -> Model -> (Model, Cmd Msg)
> 
> 
> -- 
> 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 elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Adding a transformation layer to the Elm Architecture

[Robert Walter]

Hello all,

not having a strong web development background, but rather coming from the 
area of domain-specific languages, model-driven development, and IDE 
development (i.e. building tools for developers and development platforms), 
Elm made me curious because of a lot of the ideas and features that are 
built into the language that I know from other technologies. While I 
understand that Elm is specifically targeted to make the lives of front-end 
web developers easier and offer them an alternative to JavaScript and the 
zoo of libraries there, I'd like to discuss if Elm could become even bigger 
eventually (especially given technologies like Electron that allow us 
easily to target the desktop as well). 

One of the key selling points for me is the thoroughness that is used to 
identify what we know as the Elm Architecture. Elm guides you to define a 
model of your "world" and to specify how this model changes ("update") due 
to effects from outside or inside ("subscriptions" and "commands"). Also, 
you define how the model is going to be presented to the user ("view"). And 
Elm takes care of wiring these components together. It's great and I see 
Elm as a great language not only for veterans, but also for beginners!

In model-driven development, there are a lot of similarities, but also some 
differences. Often, your world is made up of several domains ("model 
schemas"), and you define transformations from one domain to the other. 
That means applications are composed of domains that are wired by 
transformations. A system that allows you to build applications that work 
that way is MPS, by Jetbrains , in case you 
would like to see an example.

One could say that we have a simplified version of that in the Elm 
Architecture, where we define one domain ("model") and one transformation 
("view") in which we transform our "domain model" to a "rendering model", 
that is passed on to a rendering engine for display.

So, some of you might say "that's all nice and good, but why do you bring 
it up"? Well, I really think that there is a lot of potential in the idea 
of model-driven development and projectional editing and I feel like Elm 
would be an interesting technology to build something like this on due to 
its functional nature and thoroughness put into its architecture. I'd like 
to discuss this with the community. 

To make things a bit more specific, I wonder what you think about 
generalizing the Elm Architecture in a way that we not only transform from 
a domain model to a Html model (a.k.a. view), but to allow for a series of 
transformations if necessary. I like that the current architecture allows 
us to do something like that to a certain degree. Looking at the Mdl 
package for example, I consider this a "Widget domain" and I can 
incorporate it into my "view" function, basically reusing portions of their 
"domain model to Html" transformation for my own purpuses.
But if I want to use Elm to transform gradually from a model of low 
abstraction to Html via intermediate domains, it is hard to do. A 
suggestion would be to have an optional callback called "transformations" 
that takes in a model of type A and spits out a model of type B, which is 
then again used as input for the final transformation step, which would 
still be "view". Optional means that, if no transformation is defined, A == 
B.

I hope all of this does make a little bit of sense to some of you and I 
really hope it is not too controversial.

Best,
Robert

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: Help with idea for virtual-dom + polymer

[Kevin Le Brun]

I'm a bit late to the party. I recently given a talk at GDG Paris on how to 
integrate Elm and Polymer. All the examples are located 
here: https://github.com/kevinlebrun/elm-polymer. I also use a new Elm 
feature: "keyed nodes".

I hope it will help anyone interested in combining those two amazing 
technologies.

Le vendredi 14 août 2015 19:46:23 UTC+2, Hassan Hayat a écrit :
>
> I've opened an issue here 
>  in the hopes of 
> gathering ideas about allowing different types through main/allowing 
> different html interfaces to be represented with different types to go 
> through main.
> https://github.com/elm-lang/elm-plans/issues/19
>
> I think this would be interesting as folks might consider different 
> interfaces like React or Incremental Dom or whatever new shiny thing comes 
> next.
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] combining union types

[jonathan de montalembert]

Is there a way to combine two Msg into one? Like (not working)

type PageMsg
>   = HomeMsg Home.Msg
>   | ArchiveMsg Archive.Msg
>
 

> type LibMsg 
>   = TranslationMsg Translation.Msg
>   | PhoenixMsg Phoenix.Msg
>
 

> type Msg
>   = PageMsg
>   | LibMsg


then have 

update: Msg -> Model -> (Model, Cmd Msg)



-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.