模型在MVC文本编辑器方案中的作用

Question

I'm designing a movie script editing text editor for fun, and to try learn something about low level UI design. The format of a screenplay is quite simple, and is by long-standing standard written solely in 12pt courier. So I get the impression that designing an editor would be fairly straightforward, having only one font and font size, and no special formatting.

I'm keen on preserving semantic information -- eg, I want the scene header to be stored as a scene header, not just as text formatted as a scene header.

The application is further complicated by the change tracking required in scripts. Additional pages should have revision information at the top, therefore the document needs to be stored as a set of pages, with appropriate information identifying revisions.

It seems to make sense to keep the document as a separate object from the view, then call methods on a document object to add text etc, based on input in the view. However, which object is responsible for the pagination? At first guess I would have said the document, but pagination seems like a presentation thing. It would also not make sense for the document to use the graphics text API to measure strings and work out how much space they take up. However, if it was up to the view, this is in theory liable to conflict with how it has been stored in the document. So what would be the best solution?

I have plenty of experience in programming, but have had very little to do with the nitty gritty of drawing my own user controls from scratch. I've also deliberately avoided tying this to a specific language, but I'd most likely be writing in C# or C++.

Thanks for your time.

Answer 1

Neither the view or model IMO is responsible for pagination. That's the job of the controller in the MVC paradigm. Sure you would have some thing to represent the pager in the view, but the actual job of the controller to control how many records get sent to the view.

Of course the pager class itself is a model, but the instantiation of it should lie in the controller.

Answer 2

However, if it was up to the view, this is in theory liable to conflict with how it has been stored in the document

Why? The document is data, with some semantic information. How much of that data you display on a page is not something you want to store in the document.

Keep your document completely ignorant of page numbers, page sizes, or what contents go on a page, and you'll be able to keep all your presentation logic in your view.

Think of the relationship between HTML and your browser - the HTML knows nothing about pages, how it's viewed, how it's printed, and so on.

Answer 3

If the concept of a "page" is, in fact, data that needs to remain persisted with the rest of the data regardless of how it's viewed, then I would vote that it goes in the model. It's unorthodox, that much is certain. But you're implying in your description that "pages" are actual entities of the data. If that's the case, then a Page model should know everything it needs to know about itself, including how much text it can fit (which shouldn't be terribly difficult given that your data model assumes/requires a specific font for display... which will need to be enforced from within the model somehow, and I'm not sure how).

It doesn't sound like the view is really deciding how to display the pages, but that the requirements of the display are business logic in this case. The view is just handling the actual display according to those requirements.

The standard thought on the subject is that "if it's about display, it doesn't belong in the model." But every rule has an exception. If the data being stored is typesetting data, then the model has little choice but to know about something that would intuitively feel like display. You'll want to document it well in comments and such, but this sounds like a good exception case to the intuitive rule.