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 <https://www.jetbrains.com/mps/>, 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.
