On 20 June 2011 17:34, Greg Weber
I like the new url generator package, which should also be useful in focusing an application around the models.
I'd think it's more to do with the controller/view. E.g., I can have multiple URLs to the same resource via HTML/JSON, or whatever. How does it relate to models?
In Yesod one would currently check a form for errors and if there aren't any then insert the model, and this is all done from the controller. This puts model logic into the form.
Yeah, this sucks a bit. I'm a big supporter of having the model enforcing consistency. I quite like domains and constraints in PostgreSQL for this reason.
We did have techniques (not sure what the state of it is at the moment) to declare fields as required in the schema, and to have that automatically reflected in a form for a model. But a model may have more complex logic than that- a field may be required based on the value of another. This could be handled by indicating a validation function in the schema rather than just a boolean as to whether it should be required. This would also help handle more complex validations than whether just a field is required. One idea behind putting this in the schema, is that the logic is separate from a form. However, the normal way of creating a new model is just a simple insert.
insert User { name = "Chris", email = "e", requiredCheckbox = False }
In your application it's hard to say whether this is a good idea. Something to do with the required checkbox certainly shouldn't be in the model. What if you're interfacing with the application via a JSON or XML interface that has no concept of checkboxes or the notion of a user-choice in this area? It's worth establishing what we mean by MVC otherwise we're discussing the taste of ham and hamsters. I think the definition of the model is to handle and enforce business logic to do with application state that would still exist if you completely removed the view and controller. The model only works on valid input, and, where impossible to enforce with the type system, should barf on bad input. Stuff like getting input from the web request (like a form's inputs), caching pages, redirecting, choosing the right view to display and the right model objects to call depending on the input seems like the controller's job. Whether the controller is getting input from JSON, XML, form inputs, parsing files, etc. it should validate its input and give the model what it wants. The view provides a format with which the controller can send a representation of the model and receive commands; could be a curses UI, a web page, a SOAP API, an RSS feed, etc. Some MVC in practice will have the view call the model directly for what it needs which is convenient but, in my current view, is inversing control in some bad way. In this way, code that should be in the model ends up being put in the view, and the model ends up living to serve the needs of a particular view. I'm not sure whether your view actually differs to this, or whether we're just unclear.
From my limited Ruby experience, it is the triggers and validations that one attaches to the models, that really define the business logic of the model, (lets ignore for now how one deals with relationships to other models). Much of the rest of putting code into models is about having a nicer way to share, organize, and test code.
It seems a pain to expose the actual schema to the rest of the application. Shouldn't you just have generic methods that abstract the concept of creating database entries, reading files, etc. to do with the state? It seems easier to take the "big walls and gate" approach. Paris of Troy, being the cheeky lad that he was, took Helen from her husband, Menelaus. I don't know what Menelaus was doing at the time. Probably tending to issues of agriculture, directing his masses of armies, being the king of Sparta, that lark (I think we was really down the pub). Despite supposedly being great at logistics, he seemed to have poor people skills, because he sought to exact revenge not on only Paris, but the whole of Troy, by having a big fight. A proper war. The Spartans in general seemed to have a bad attitude. Helen of Sparta was said to be the most beautiful of all women. Not just really beautiful or the best pair of legs this side of Greece, but the most beautiful of "all" women. This makes one wonder who started that rumour; my money's on Helen. Since he didn't know his arse from his shoes, losing wives left, right and center, Menelaus hired his brother, Agamemnon who was more than happy to sort it out. Troy was designed to be a nice city, and it was. At first, armies would come from across Greece and kick the crap out of everything, stealing things, etc. The Trojans didn't like that. Later, they let people in, but installed guards that would wait around for things to kick off, and spring to action when things went bad. Sadly, this only worked so far, as people were killed and stalls smashed up, and sly graffiti artists would write “Paris is φαλλός” on walls when the guards weren't paying attention. They found it hard to separate the nice city and city people from the riffraf. Finally, they decided to erect a big wall around the city, to keep it nice. With one big gate at the front. Nobody could get in without first being inspected, checked. Otherwise they were told to sling their hook. At this point Agamemnon decided to attack. Pretty bad time to try to besiege a city that had recently had a brand new wall installed. Anyway, long-story-short the Trojans were idiots because they let a huge horse-shaped box containing person-shaped killing machines into the city without inspecting it at all on the outside of the wall or the inside. Subsequently the gate was compromised and a load of bad stuff went down. Bad Troy. I despair! Got a bit carried away there…