Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Nov 1, 2016 at 2:25 AM, Kasey Speakman wrote: > > So here's a concrete example of how we did it wrong in our legacy system. > To close a trainee's registration as "No Show", an employee has to create > an exam against that registration and grade it as 1%. This is an

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 8:31:07 AM UTC, Peter Damoc wrote: > > However, looking at a fresh system that one might want to design it seams > to me like there are 3 possible layers > > Layer 3. Business Objects Layer - concerned with validity of state > transactions > Layer 2. Data

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 10:00:08 AM UTC, Peter Damoc wrote: > > On Tue, Nov 1, 2016 at 11:30 AM, 'Rupert Smith' via Elm Discuss < > elm-d...@googlegroups.com > wrote: > >> Are you talking Elm running server side for this? >> >> I haven't thought about that too much. > In theory, there

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tue, Nov 1, 2016 at 11:30 AM, 'Rupert Smith' via Elm Discuss < elm-discuss@googlegroups.com> wrote: > Are you talking Elm running server side for this? > > I haven't thought about that too much. In theory, there should be some kind of schema common to both the front-end and the back end that

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

It is silly, and I don't know why it was done this way. But that's the world I live in now. It's easy to justify one case at a time, but all tolled it adds up. As far as "layers", you should check out these two posts in order.

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Oh, and yes, most of these layers are on the server side if we are talking about an Elm client application. Generally speaking, the client app serves to collect and prepare data to submit use cases. So it reads data from an API and submits data to an API. On Tuesday, November 1, 2016 at

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

It would be awesome to have a more complex but practical example that captures this. The reservation scenario from the second post looks like an interesting use-case. I will think more about it. On Tue, Nov 1, 2016 at 3:33 PM, Kasey Speakman wrote: > Oh, and yes, most

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 9:36:36 AM UTC-5, Rupert Smith wrote: > On Tuesday, November 1, 2016 at 1:16:40 PM UTC, Kasey Speakman wrote: >> >> It is silly, and I don't know why it was done this way. But that's the >> world I live in now. It's easy to justify one case at a time, but all >>

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 2:10:05 PM UTC, Peter Damoc wrote: > > It would be awesome to have a more complex but practical example that > captures this. > > The reservation scenario from the second post looks like an interesting > use-case. > > I will think more about it. > > > On Tue,

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 1:16:40 PM UTC, Kasey Speakman wrote: > > It is silly, and I don't know why it was done this way. But that's the > world I live in now. It's easy to justify one case at a time, but all > tolled it adds up. > > As far as "layers", you should check out these two

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

On Tuesday, November 1, 2016 at 9:53:55 AM UTC-5, Rupert Smith wrote: > > ... > There is clever stuff we can do with the data-centric approach, in terms > of using generic CRUD APIs, or tailoring graphql expressions to fetch or > update particular paths in the data model. It is a bit harder to

[elm-discuss] Re: Is there any way to use a type instead of a string for the value of an option

You're right it is easy, but it also feels quite messy. I appreciate your point that the specific use-case of value is to represent a value attribute in HTML which is a string, but part of the fun of elm is that it hides a lot of implementation details in HTML and CSS, and given that you can

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

In a new project, we are going for something like this. https://www.youtube.com/watch?v=GneIxgl71NM=18=PL9Z-JgiTsOYTdi91N_DlcpWqkCYvMrhA4 On Tuesday, November 1, 2016 at 10:00:36 AM UTC-5, Kasey Speakman wrote: > > On Tuesday, November 1, 2016 at 9:53:55 AM UTC-5, Rupert Smith wrote: >> >> ...

Re: [elm-discuss] Re: Metalinguistic abstractions over databases

Just wanted to say, thanks for posting this Kasey. It's great to hear the nasty details, though I'm sure it's not so great to live with them day to day :) It's a great point about implicit behavior pushing off programming from the system onto the users. Thanks also for the links. I have been

[elm-discuss] Changing root font size

For app that use `rem` for styling, the font size is set at html node html { font-size: 18px; } Is that the only way to control this value is by port and do it in js? -- Best Regards, Jacky See -- You received this message because you are subscribed to the Google Groups "Elm Discuss"

Re: [elm-discuss] How to write function that updates arbitrary element of a record

> On Oct 23, 2016, at 9:30 PM, Leroy Campbell wrote: > > I think I have something close to what you're looking for, but my solution > makes me wonder, why store text in your model rather than the parsed > float/int values? It seems like you want the parsed values for a

Re: [elm-discuss] Changing root font size

Why not use a stylesheet? On Tue, Nov 1, 2016 at 9:22 PM, Jacky wrote: > For app that use `rem` for styling, the font size is set at html node > > html { font-size: 18px; } > > Is that the only way to control this value is by port and do it in js? > -- > Best Regards, >