Collin: 0:00

Hey, Joel, how, uh, how has your week been?

Joel: 0:02

Hey. Uh, it's been great. Um, yeah, I've been kind of working on my, my gem quite a bit, um, which has been fun. Uh, I ran into some very interesting edge cases, like if you, um, if you try to use an attribute.

Collin: 0:23

Mm-hmm.

Joel: 0:24

The attribute name is something like class. Then obviously, uh, the, when the code is generated and it tries to, uh, look for the local variable class, it, um, doesn't work. So I've been trying to like figure out a good way to, uh, kind of like detect when you need to. Use like local, um, binding local variables instead.

Collin: 0:54

I guess you're at the point of working on this gem where you are, you are thinking about kind of edge cases, so that's cool.

Joel: 1:00

Yeah, it's where I'm actually integrating it into a project and running into real edge cases. Which are then driving a bit of the design,

Collin: 1:11

Yeah, that's cool. Um, yeah, so, well, let's just get into it cuz. So I sent you this, uh, I mean, that's interesting, but let's get into it. Uh, I, I actually pitched a topic to you this week, which is somewhat unique. Uh, and the topic was called, uh, MVC Isn't MVC, which is the title of a blog post I wrote that I'll link into the description and basically what I did was I spent all goddamn day writing this blog post. It's like 1200 words long. It took me forever. Cause I did all the, I had to do all this research and stuff and I probably still got some things wrong. So if I did, um, please just nobody tell me cuz I'm not going to, I, I don't want to know now. Uh, I've spent enough time thinking about this, but basically, The model view controller pattern is something that we're all very familiar with, right? It is spread wide and far right. And so what I did was I went back to the original documents from 1979. There were a couple of them. Uh, I only mentioned one of the blog posts. There was one from May and then one from December. The December one is easier to read and shorter, so I just kind of talked about that. But basically this guy named, uh oh, geez. Regg, uh, and he was an employee at Xerox PARC, so they were making, uh, do you know about Xerox PARC?

Joel: 2:31

No.

Collin: 2:32

So Xerox PARC is basically where, uh, they invented a few things. Um, it's famously where like Steve Jobs originally saw, uh, a graphical user interface for the first time.

Joel: 2:46

Oh, wow.

Collin: 2:47

Yeah. So they were the Palo Alto Research Center. Which was in Palo Alto in California and Silicon Valley. And they were uh, basically kind of inventing the sorts of things we all use today. And so one of those was like bitmap displays. One of those was object-oriented programming with a language called Smalltalk. And they created a computer called The Alto, is the one I'm remembering the name of that, you know, had a mouse and a keyboard and sort of windows like you think of, so. But the environment that it actually ran, its sort of operating system, was a Smalltalk environment. So what that means is that, uh, in Smalltalk, like the environment you program in, have you've ever seen this? It's not like you load up your text editor and start editing files. It's like you have this sort of live environment that looks like an operating system basically with like windows and menus and things and you sort of um, are just editing the living live objects in that environment, And it makes it really great for debugging and some other things cuz everything's just sort of going So they were inventing all, really

Joel: 4:00

like a graphical user interface to the program,

Collin: 4:05

Yeah. So,

Joel: 4:06

but to the programming of the program.

Collin: 4:09

Yeah, so I'm gonna send you something in, uh, in the chat. Um,

Joel: 4:16

And we, we can post this on the

Collin: 4:18

yeah. I'll post this. So if you go to squeak.org, you can see, you can scroll down and then they have some screenshots of the windows and things. Uh, you can see where that's, Basically, yeah. The environment you are working in is kind of like its own little operating system. So on one of the screenshots, if you scroll down, they show you the system browser. That is how you get to all your classes. So you see it's kind of an outline view where it starts, it's like a four column thing. So on the, on the far left side is like categories of things. So that might be like your app basically, or whatever, and then next to that is your classes, and you can edit on the instance side or the class side, and then the third column is categories of methods and the fourth column of methods. So you don't like open a file and then like find them, you, go find the method in this kind of like outline view sort of thing. Does that make sense?

Joel: 5:10

Yeah.

Collin: 5:11

So it's really cool. Um, and they were inventing all of this and uh, and, and one of the things they invented was this guy, uh, Turig Green published this paper called Models, views, controllers, and it's a design pattern they came up with, because basically they were the first people who were developing these kind of graphical user interface applications. And so they, this is what they came up with. Um, and what was interesting to me about it is that reading the original paper, it's actually, it is recognizably the same as the other instances I've just, I've used of this, but it's also kind of different. Um, so like, how would, so how would you describe model view controller, like as a, as a pattern?

Joel: 6:02

Let me think. So a model is meant to model, um, some of your like business data. Um, so that might be for a blog that would be like posts, comments, um, subscriptions, that kind of thing. The view is like a visual representation of the, of the model or the, the data that you are representing. Uh, for that view, it could be, it could be more than one model. And the controller is kind of like a, a link between the two in, um, in Rails. It's, it's, um, Kind of responsible for, it's not responsible for routing, but after routing to a particular endpoint, the controller is responsible for, uh, rendering the view and giving the view the correct information. Uh, and also like making sure that, uh, everything around a particular session, Uh, is, is happening correctly. So, for example, um, correct headers are re returned, cookies are set, um, authentication is done. Essentially a controller is like modeling a request to some extent. Um, and it's, it's not routing a request, but it's, it's, it's essentially modeling a request,

Collin: 7:25

Yeah, so I think that's a pretty good way of describing it in kind of the rails way of doing it. Right? So the idea is that a model is the, uh, It's the part of the application which kind of represents the abstractions that you're using for like basically modeling the data. You know what I mean? Like if you think about like a model is like how you think about a thing, right? As an abstraction. That's, that's what a model is. Um, a view is a visual representation of a model. Right. And then, uh, the controller, they describe it in the original document as the controller is the link between the user and the system. So it, it arranges views on the screen, it receives user input, it passes messages to views, and it updates the model. And if you think about it in rails, that kind of all maps, it's a little different, and we'll get into it, but basically, When you put all this together, you get this kind of, sort of beautifully circular kind of thing, right? Where basically the user interacts with the controller. So in Rails, this might be like, there's an HTTP request and it gets routed to an action in a controller. The controller then updates, uh, it, it uses the model and then goes to the view, and then the user sees that, and then you sort of get this circular thing going. So it's a little different in the way that the, um, how do I describe this? So one difference in the original MVC document, which totally makes sense that this is different on the web, uh, because I don't know how it would work otherwise Exactly, is that models are responsible for notifying the views when they've changed, and then the view updates when the model is changed. So the view has some use has like you click a button or something, you click save, right? That gets sent to the controller from the view that updates the model, and then the model notifies the view that it has changed and then that updates. And you can understand why this wouldn't work in like a web environment the same way because like those are not living objects. Like they would be in a, uh, In a Smalltalk or like native environment, right? Like each of those things only exist long enough for like the request cycle to happen, right? So like, so the way it works in rails is instead of that, it would be that, for example, if you had an editing form that that fires another request that gets routed back to a controller action, and then that gets the model and then that sets the view up again. It's a different view.

Joel: 10:12

Right. It, it redirects you to a different page

Collin: 10:14

Yeah. Yeah. So that's, so that is a way that it is different in, in, in, in the web and or in like what I call like the Ruby on Rails style, which my understanding is that that came from basically in the late nineties, all these like Java developers who were writing. Web applications, like we think of them, uh, you know, looked at it and were like, you know, they wanted a pattern that could work in this way. And so they created this thing called Model 2, which is confusing because that makes it sound like MVC is Model 1. Right. But Model 1 was actually this other web thing from before that that I think basically didn't have controllers. So that's kind of confusing. Um, so Model 2 is like a variation on mvc, but MVC is not Model 1. That's confusing.

Joel: 11:06

Okay.

Collin: 11:07

And that's basically what we have in, in Rails. So I just, I don't know, I thought this was really interesting, um, because, if you look at this document, the way I describe it is that, you know, it's not, it's not like in Smalltalk or something where like messages are getting passed and notifications are happening live, because all the objects are just sort of like in memory.

Joel: 11:31

Mm-hmm.

Collin: 11:32

the adaptation to make this sort of thing work on the web is that all of that maps to an HTTP request, and so those are the messages. Which I think is really neat. I think that's, I think that's really interesting to me how they were able to take that and then adapt it. Right.

Joel: 11:51

Yeah, because you don't have the application running locally in memory, so you are just exposed to the view and the, the messages coming back and forth from the server are essentially the view update messages, right.

Collin: 12:07

Yes. Yeah, yeah, yeah. So I thought, yeah, I thought that was interesting. And then I also mentioned in this a different style of MVC that I was also familiar with, which is what I called, um, Apple style MVC, which is where all of these objects are alive, but if you look at the, um, if you look at the blog post, you'll see the little diagram is different. And the way that this style of MVC is different, and I think this might be common in like native apps sort of thing, not just Apple, but it's where basically a lot more gets pushed onto the controller. So instead of it being like controller manipulates the model model updates, the view user uses the controller and it sort of has that circular pattern. It's more like the controller has a user action sent to it, which then updates the model. The model then notifies the controller, which then updates the view. And so the difference there is mostly that the, the model and the view, um, are not directly connected at all.

Joel: 13:12

Right. They sit on either side of the controller.

Collin: 13:15

Yeah, and like, so the controller's really like in between everything. And I think the reason they did this was because I think they're trying to make it a little more decoupled. Right? And so if you think about it, the, the controller is pretty tightly coupled to the model, and the controller's pretty tightly coupled to the view, but the view in the model are not coupled to each other in the same way.

Joel: 13:40

Mm-hmm.

Collin: 13:41

Right. So like a common pattern. Would it be like the controller wouldn't just say like person view, like here's your person object. It might even say like, person view, name label, text equals like whatever. Right. And it's kind of like literally all of the logic is in the controller in that way. So that, that was also, uh, so, so that was also different. And I thought, I don't know, I guess. Do you have any thoughts about any of this? It's like there's this thing that was come up, that came up with about, at the same time the original Star Wars was released and that it is still used and we are looking at it and it's relevant, but also that it's like really changed a lot in the past, like 43 years or whatever.

Joel: 14:27

Yeah.

Collin: 14:28

Yeah,

Joel: 14:28

it's really interesting to think about how this pattern has somehow also, still just like, it's still recognizable, right? So it's, it's withstood the, the test of time.

Collin: 14:39

Yeah.

Joel: 14:40

it has these different permutations, I think. Um, I, I don't agree with the separation of like model and view.

Collin: 14:51

Mm-hmm.

Joel: 14:51

think, um, I can understand why it seems like that's a good idea to have the controller be the only thing that knows about the model and the only thing that is about the view. Um, but I actually think that having, like having the controller have to manually take all of the attributes from a model and pass them to a view is just. Completely not worth it. And it's better to have, like, I th I think rather than pass like 10 different attributes, passing an object that has 10 different attributes is just much better overall. And for a view to depend on like one or two models or maybe an array of a specific model type, um, I think that's just much more maintainable than a view that has its own kind of, View based model of the model that is somewhat similar to the, you know, the data model of the model, and then have something else try to, try to interpret and pass messages between them. That, to me is, is, uh, doesn't sound like a great, um, yeah. Way to organize it. What, what are your thoughts on that?

Collin: 16:01

Well, yeah, and you're kind of talking about like this sort of Apple style thing I, I talked about in this and it's, well, it's a trade off, right? So, um, I kind of agree with you. I mean, in practice there's a little bit of a stylistic thing there. So sometimes you will literally have where the controller is setting like individual properties on the view,

Joel: 16:20

Mm-hmm.

Collin: 16:21

and then you will also sometimes have what you talked about, and that's sort of a stylistic difference, you know, depending on who's writing it. Um, I would say that, yeah, the obvious issue here with that style of MVC where the view and the model are so like completely decoupled from each other and they only go, they only speak through the controller, is that everything goes through the controller, right? Like the controller can get pretty big. Um, if you're not careful, and that is a, um, That is a thing that happens in iOS. So in, in iOS, we, we, uh, have traditionally had a kind of controller, which controls a view called a view controller. Right? That's the class. And so a lot of times, um, a joke, some people would make an iOS world would be calling M V C massive view controller, that that's what it stands for. And yeah, and I think part of that is because the difference is when you make the view dumber, You, you know, when you, you're pushing responsibility from the view onto the controller and you are separating any idea that the model and the view will talk to each other like directly at all. Um, yeah, you do end up with some benefits of decoupling, but you also end up with that, uh, the, that one layer of your code can become very unwieldy. So I think that's a good observation

Joel: 17:46

Right.

Collin: 17:47

So that's why I would say like that style of MVC, it's, it's still obviously like related, but it's, you know, it's like related in the same way that like, uh, Americans and British people speak English, right? Like we speak English correctly and then British people are weird. Like that's sort of the difference. Do you know what I mean?

Joel: 18:09

Yep.

Collin: 18:10

Yeah. Um, but no, I think that's a really good observation and yeah, it, it was interesting me to think about as, um, you know, I don't know as, is it worth trying to understand what some of those motivations were with like, having the model and the view be more, you know, coupled together. Like I could develop an application that way, that's possible. I was thinking in terms of like, you know, it's not exactly the same in rails, but I was thinking, tell me if I'm incorrect here, I was thinking in terms of like, like turbo streams and stuff. You know how you can do like the broadcasting from your model? I was like, oh, that's, once again, like it's not exactly the same thing, but like if you squint you forget that all these objects are actually like not alive really, cuz that doesn't actually matter for the pattern, like whether they are or not. Um, if you squint, like sending those broadcast messages that sort of automatically get the view updated without your controller doing anything, kind of looks more like the original MVC, right?

Joel: 19:12

Yeah. Yeah, actually, I, I think the original MVC is almost the most ideal and the one we, we should be trying to get back to like the, so the. It's, it's a bit more complicated when, when we're talking about web requests because you can't, you don't have just memory, um, that these things can live in. Uh, and so, so Rails traditionally is like this completely stateless, uh, system. Like every single request comes into the application and the application has to. Start from scratch. It's like, it's like you're just booted the application up again, right? And you, and you've gotta, you've gotta figure out who is this person? And like, um, what are they trying to do? Like what, what account are they associated with before you can even get started? Um, so that's interesting. I think that there are ways now that applications could be built where they are actually stateful and after the first request, the client is actually connected to the. Um, these objects that are running on the server and are able to communicate back and forth. Um, I think that, um, that, that would be a really interesting way for Rails or like some other Ruby framework to go where using either web sockets or service center events, you could still kind of have that, um, That live interaction. Um, and I think in terms of the view, you, you'd be able to send updates from the server just using something like morph dom.

Collin: 20:56

Yeah. Oh, well speak about, you were mentioning that to me offline before. Speak about, uh, what morph dom is.

Joel: 21:02

Right? So, um, I don't know a ton about morph dom, but the way I understand it is it's basically a way of saying Take this dom and replace it with this dom, but instead of replacing it, actually, uh, go through and figure out what things are actually different and then just change those things. So, um, an example might be if I want to, uh, let's say I have a, a text field. You're typing into it and when you type something that's invalid, uh, I want the text field background to go red, and I'm gonna do that by applying a CSS class to that field so the server could send a message that says, um, find this text field and replace it with this other text field, which is exactly the same except that it has. This extra CSS class, if you replace it, then the browser is gonna lose the state of that original text field. So if you had it focused or something like that, it's gonna be completely gone. Um, what I believe morphed on does is it would actually compare the two text fields and be like, well, these are both text fields and in fact, the only difference is we need to add a class. And so instead of replacing. Um, the first text field, with the second text field, it can just do a change, which is add this class to this original text field. Um, but it kind of does all of this in the browser and all you need to do is send it the new DOM or, or the new markup that, um, becomes Dom and is able to be merged, if that makes sense.

Collin: 22:44

Yeah, absolutely. And I think what I had mentioned before when you were kinda describing this is that actually sounds, uh, remarkably like how SwiftUI does it. Um, which is that also in SwiftUI, like the modern Swift UI framework for that for Apple stuff is that, um, The views are no longer like they used to be. They're not, they're not reference types, so they're not something where you're just like setting properties on them and like they're updating like it's an object. They're all value types. And so it's basically doing what you said, like the, the api, uh, is a little bit different, um, in how it works, the way it works in, uh, the way it works in SwiftUI y basically, as you say, like these are state, uh, These are like state variables and you can connect thing called observable objects to this. And basically it knows like when this observable thing that is a state thing changes, right? I need to diff what I have and then update it in that way. So it's kind of funny. It's kind of doing the same thing if you think about it. I think.

Joel: 23:50

Yeah. Yeah, it's very similar. It would be so interesting to build an application with Ruby. I, I think maybe even a new framework that, that, what that does, this where, A session is actually held open on the server, um, as well as on the client. And, um, you know, messages are just passed back and forth and you don't need to go through all that setup every time. There are some other ways of approaching, uh, this, which I think might be interesting to cover, which is, um, one example is, I think it's Turbo Boost, um, or one of the new Turbo Boost libraries. Um,

Collin: 24:33

I don't know. There's a whole, there's a whole variety of turbo something or others. Uh, this is

Joel: 24:38

Boost Streams, I think it's called. Um, so this is a way of. Sort of having state, uh, like client side state, uh, that the server knows about. And, and it kind of, it, it's not quite the same as what I've described a second ago, but, um, it does give you some, uh, some state that you can have in the client and in on the server. And the way that this works is, if I understand correctly, it basically will, um, Use cookies. And so it can, like, you can put state into like client side, state into the cookies, they're compressed. Uh, and this bunch of really, uh, clever stuff happens to them to make sure that they fit in the, the amount of cookie space. But then the next request that you make, uh, the server is actually able to understand what the state of the client. In, um, to some extent because of these, um, these flags. And so for example, if I, uh, go to a page and I click to a specific tab, or I open a specific dropdown and then I close that page, and then I open that page again, um, the server can render the view in the exact state that I had it in a second ago, because that state has been stored in my cookies. Um, and there is like limits to this because of the size of cookies that you can have. Um, but there's also within a session, like if you're just clicking around on a page, you don't close the page, you can actually store even more than that. Um, Because every request that you make also sends like the full state. So if it doesn't fit in the cookies, there's like extra state that can be sent as well. And like Turbo Boost has done a bunch of work around making this so that like, you don't need to think about any of the complexities of how it works. Uh, you just have the ability to kind of like sync client state with service state. So I've, I think that's a very interesting approach. It's still like, Keeping the whole, like every single request to the server is starting from scratch. It's just starting from scratch with some extra information that came actually from the client. Um, I don't know if it really affects the kind of MVC layout and that pattern at all, but I thought it was kind of interesting to, to talk about.

Collin: 27:11

Yeah. I think it is interesting to me thinking about both with like, You know, um, on the native end when you have things like the observable objects I was talking about, which you could kind of do before, but it was different, um, and less convenient and you know, with all this like new web stuff where, you know, like you can have a socket open and then turbo streams doing broadcast stuff or you can have the other things you mentioned or whatever that like. Yeah, it is interesting to sort of come that you kind of come full circle a little bit, um, you know, to where I. I think, you know, the whole Model 2 thing partially is structured the way it is because, uh, if you were in an environment where you could only do things via HTTP requests, right? Like there's no option to have the model update the view in that way. You know, but actually having live objects and being able to have them communicate sort of in a different way is, there are benefits to that. And yeah, it would be interesting to see what a Ruby framework, uh, designed around that would look like. I know I've mentioned there's a Smalltalk web framework I've mentioned before called Seaside that I think kind of did some of this, but I'm not familiar enough to like speak too intelligently about it.

Joel: 28:33

Right.

Collin: 28:33

Yeah, it would.

Joel: 28:34

There's also, Phoenix Live View, which is basically this, um, Phoenix Live view. As far as I understand. I don't know a ton about Phoenix Live view, but it does that thing where it keeps web socket connection open and the server is actually like, like keeping objects around. And it is, you are live interacting with a server session and your view is just syncing, using morph dom. This is actually where the Morph Dom project came from, so that's definitely an interesting one to look at in terms of like, I think we can bring a bunch of these ideas into Ruby and it, it might be very interesting.

Collin: 29:10

Yeah, I agree. And I, I don't know, I, um, I, I, I guess I can't get over how cool it is that like something that was made in like this very specific world for this very specific thing has just like, had, had enough legs basically to be applied so broadly and like be adapted. Phoenix is another thing I wanna look more into. We should, we should try and have, uh, this guy on the podcast at some point. Phoenix has gotta be doing something else entirely, right? Cause it's all functional. So I don't actually know what the code of this looks like, but yeah, the idea of it being able to just sort of update the view live, um, and I think that come from, I think it's very efficient for them to do that because, uh, you know, because it's all, um, very concurrent and asynchronous or whatever in Elixir, right. That's kinda the whole thing. It's able to keep a lot of connections open and be very performant. Um, which is, which is pretty neat. Uh, I definitely need to dig more into this. Um, I don't know what else.

Joel: 30:11

So I, I've got, I, I've got something else. So I actually clicked through from your blog post and read the original paper, and it's two pages long. I couldn't believe how, how like brief and simplistic this is. Um, but anyway, I was, I noticed that models, views and controllers fit on the first page. And we forget the second page. No one talks about the, the, uh, e, is, which stands for editors. So editors, uh, it says in, in the paper is, um, it's a controller connected to all its views. Um, and, sorry, I'm gonna start that again. Um, so editors is basically a special controller, uh, that permits the user to modify the information that's prevented in the view. Um, and I think this is a really interesting object. I think that this is pretty similar to probably what a lot of people are doing in terms of having form objects on the server. Um, and these are basically objects that receive. They're parameters from a form and process those and, um, do any kind of validations and, uh, that kind of thing, and then are able to pass the result onto whatever models they're meant to update.

Collin: 31:40

I know what your next gem's gonna be.

Joel: 31:42

yeah. Um, I, well, I might actually, I, I've been thinking about, um, About this problem a lot and I, I dunno what, what, what my next gem's gonna be. But it might be, it might be something to do with this.

Collin: 31:56

Yeah, I actually also thought that was interesting. I didn't mention it before. Cause it just, it's like we don't talk about it these days, uh, in either world I've worked in. But um, yeah, there's three things. There's like, there's models, there's views, there's controllers, and then on the second page, so it's really a page and a half, which is sort of amazing.

Joel: 32:12

right. There's a fourth thing.

Collin: 32:14

Yeah. There, there is a fourth thing, but also it's the whole thing. They fit a fourth thing in and that it's a page and a half, which is incredible to me. But yeah, it's a kind of controller that's temporarily inserted between the controller and the view when you're editing. So the, I think the example you gave is a really good web way to think about it. So that's, that's cool. The way I thought about it is I thought like, let's say you had like, If you were in the contacts app right on your phone or whatever your Mac, that when you hit the edit button and it goes into like edit mode, that's where you would insert. You'd be like, alright, um, like contact person, view control or contact control or whatever you are, you know you are gonna take a back seat cuz we're gonna have the contact edit controller now is taking over and now that's what receives. Like the user input and all that. And what I thought was cool about this is that it can kind of encapsulate the state of the editing mode. Do you know what I mean? So it's like when you hit save, uh, one is that it keeps that out of the primary controller, which I thought was cool. Um, so it just doesn't even know as much, but two. So when you hit save, then it's like, cool, I'm gonna update the model. And then the other controller, I guess, doesn't really even need to know anything at that point because the model will notify the view to do whatever has to do. So you're going to update the model and then remove it from the controllers. You'll take it out from in between, but then also, uh, if you hit cancel, because that controller has basically like encapsulated all of the state that was during editing. If you hit cancel, all you have to do is throw that away and now you're just, you're just back to where you started, which I thought was really cool.

Joel: 33:56

Yeah. Yeah. I, I, I, I want to touch on, um, a couple of the reasons for having, like, the advantages of having this layer in between, uh, the model. Well, this, this, this, this editor's layer or forms layer, it's sometimes called, I think, um, and, um, So a couple of these, the advantages are, first of all, some of your forms are going to touch multiple models. Um, they might even create multiple models or like update some models and create other ones. And typically in rails, like the kind of default golden path is actually that you model this form in a view. You actually, it, all the modeling happens, uh, in where you set up the view and you call like form with or whatever, and you have like, um, accepts nested fields and that kind of thing. Um, or actually accepts nested fields happens in the controller, I think. Right. Um, And, and yeah, so, so kind of a lot of that stuff happens in the view, some of the, some of it happens in the controller, where the controller is doing, um, you know, which parameters are permitted, that kind of thing. And some of it happens in the model where the model is saying like, these are my validations for, uh, these fields. And I think that, That can work when you've got a very, very simple app. But I think it can really help to have something, some object that is dedicated to the form. So it can, it can do the job of, um, of like having the structure of the form itself. Having which parameters, knowing about which parameters need to be permitted and um, how to generate a view for a form, but it can also handle validation. And I think this is really important because your models should validate like data that is valid to be saved in the database, like to actually be one of these models. But it shouldn't validate things like permissions. Like, uh, oh, this person doesn't have the permission to change this field, uh, to this value, but this other person does. And so, um, having another layer I think can really help because sometimes. It's completely appropriate to have a model where you can change certain fields in certain ways as like an administrator or like even just in the console, right? Um, but you wouldn't want a user to be able to do that. Um, and I think that when you have these kinds of problems, it can just help to have an object that's completely dedicated to that. Uh, I can't think of any off the top of my head, like patterns or things I would point you to. Um,

Collin: 36:55

But I think how they describe it here though, of like that they recognized that, you know, we both just named like a couple of different examples from web and native that like where you might, this could be cool. Um, is yeah, it's, it's, it's interesting to, what was I gonna say? It's cool to me that they recog that this guy recognized at the time that like there was another thing that could go here. And I think what it really shows me is, The power of making it into the acronym, because if it would've been M V C E I bet we'd bet we'd use these. Um, but we don't. Um, no, it's, it's, it's, it's cool. I think it's, it's, it's funny to me that it, that we don't have this as part of our layer in most places. You know, we have other things, but like, not exactly what's described here, that that's not a built-in thing because, um, but that this guy thought it was important enough to include. So that's, that's it doesn't mean he was right, but it, um, but it is, it is interesting. Um, so I, I may experiment with that. Actually. I, one thing I, I think is another thing I was thinking about as you were speaking was just that like, I think I, I think in Rails world, I think also in Native World, I think there's a concept that like a controller is a certain kind of thing. Right, like it's like an action controller or what, you know what I mean? Like it maps to being a sub, this one kind of subclass of a certain kind of thing. But like MVC is just a pattern. Like you can have other kinds of controllers and I think that's what he shows here, right? Like that probably wouldn't be a subclass of like the normal rails controller. It'd be like a different thing. They could also be called a controller. Um, and I feel like that is something that, uh, I don't know, I've seen missed in multiple places that like, You could have other, you know what I mean? Like it doesn't have to be the one thing. It could be, you could have many things like this. Um, I dunno, there's

Joel: 38:55

the same,

Collin: 38:56

and editors that you could think of.

Joel: 38:58

the same is absolutely true of models. Um, models don't have to be active record

Collin: 39:03

Oh yeah.

Joel: 39:04

They can be, um, they can be anything, any, any object. It could be a model,

Collin: 39:10

Yeah, that's maybe even a better example cuz especially in Rails, it does seem like there is a conception with some people that like it. You know, a model is like an active record model, right? That it's not just an object. Um, which is interesting. Yeah. Cuz MVCs a pattern. It's not like a framework, you know what I mean? Like you can apply these however you want.

Joel: 39:31

right. Yeah. You, you do often run into. Uh, the question of like, where do I put this file? Like where does it belong to? Is it a model? Is it a, like, is it something else? Does it go in lib? Um, and I think a lot of the time the answer is, it's a model. If you, if you don't really know what it is, but it's, but it's like modeling some important structure or. Data or, um, some concept, even even modeling an event, right? It may well just be a model. I think it can be reasonable to separate, um, like particular types of models. If you have a bunch of them and they all follow a very particular standard and it makes sense to like have a folder at the top levels. You've got like maybe models, views, controllers, jobs, right? You could say that a job is. A kind of model. It's like modeling and operation. Um, but we, we like treat jobs as like this special case. Um, and some people treat operations and service objects and, um, maybe even forms you might treat as a special case. You, you could say they're just models. Um, I dunno if that

Collin: 40:46

if you're modeling a form, then yeah, that's a model.

Joel: 40:48

Right, you're modeling a form, but you could say you're modeling a view and you're modeling a controller, right? So technically everything could be a model, but um, yeah. So I dunno if I've really helped you answer the question where you should put that file, but, um, maybe they should all be in the

Collin: 41:04

You sound a little bit like Alan Watts right now. Uh, he's a, like a zen guy that I I like a lot. Um, where you were like, you know, his whole thing is, it's, I would describe it as like, everything is everything, right? Like, uh, It's not that everything is one, it's that like everything is everything. Um, depending, like at what angle you look at it from is a sort of concept he goes over a lot. So I thought it was funny that, uh, that you got to, maybe everything's a model. I don't know. You're modeling a view. Um,

Joel: 41:29

I thought it was funny that I was like, so you might be confused as to way she put this file and let me add some more confusion to that.

Collin: 41:37

You, you have got me thinking though about where I might try and work this editor thing and I think it's interesting and I think, um, I also just wanted to let you know that I looked at rubygems.org and editor Controller is not taken as a gem name. So, um, but anyway, I think, you know, I think we've covered a lot. I think this is pretty good. Um, what do you think?

Joel: 41:57

Yeah, I think we should wrap it there.

Collin: 41:59

Cool. Well, thanks everybody for listening. Uh, you know, please read the blog post, um, you know, send us your feedback, uh, even though I said not to, you can. Um, and you know, if you like the show, please tell your friends. Please tell anybody you want, and, um, we will see you next week.