MVC questoin
Hi there, this is a long blah - hope it makes some sort of sense! :-)
I have some data (lines of text) that represent keyboard and mouse commands among other things - each file might have say 500-2000 rows in it. It is possible to represent the data at theraw level (i.e. press mouse, release mouse, press Shift, press A, release A, release Shift) or at a higher level (click mouse, type "A"). It is also possible to represent the data in other ways. The file is always be saved in the raw format. Now the MVC pattern as I understand it (and I'll admit I've had no formal training on this), means I should generally hold this data once in a model, and then I can have multiple views on it.
However, the views I want to have are generally updateable, and based on JTable, which has its own MVC structure with an underlying TableModel. Okay, so why can't my model also be the table model? The problem then comes with the different views wanting the data in significantly different format - not just at the row level, but with multiple rows combined in some cases.
Note that currently only one view will ever be open at a time.
So, do I...
1. make my model clever enough to reformat the data in any of the possible formats that I might want to use as views so that I can use it as the TableModel. It can do the reformat once each time it is added to the view and back again to the standard raw format when the view is saved.
2. make the primary model clever enough to supply the data in forms that will support each of the view formats but pass that data to a separate TableModel for each view. They will then pass the updated data back when the user saves and the model will reformat back into its raw format.
3. Pass the raw format from the model to each specific view's TableModel and let that TableModel massage it into the shape it requires to support the particular view. The individual TableModel then must reformat back to the raw format before passing back to the primary model when the view is saved.
4. Use the model with its fixed raw format as the underlying model for each view's TableModel, but convert from/to the view's format on the fly for each getValueAt/setValueAt .
It seems to my untrained eye that option 4 is the "purest" MVC version, but scalability might well be an issue and the getValueAt/setValueAt may get complicated to write. Option 3 seems a reasonable compromise between performance and design to me.
Well congratulations if you got this far - please let me know what you think of my ideas.
Thanks,
Tim
[2629 byte] By [
TimRyanNZa] at [2007-10-3 2:59:40]
Hi Tim,
Before we start - what's the NZ for? Are you a Kiwi? Just curious.
I agree that the TableModel for JTable is not necessarily meant to be the Model for your problem. It's for Swing's use.
If we agree on that, I think you need one or more domain objects that represent this raw data as objects. They'll be smart enough to know how to reformat them according to the needs at hand.
Sounds like you've developed what amounts to a "little language" or a Domain-Specific Language in your raw text files:
http://www.martinfowler.com/articles/languageWorkbench.html
True?
%
This is really funny - it is exactly what I was talking about...
The fact that the editable representation is merely a projection of the abstract representation leads to a few points. Perhaps the most important is that there is no need for the editable representation to be complete - some aspects of the abstract representation can be missing if they aren't important to the task at hand. Furthermore you can have multiple projections - each showing different aspects of the abstract representation. Since the projection is inside the language workbench the editable representation is much more active than a text file. This projecting editor is tightly bound up with the language itself. As a result in thinking about your editable representations you actively think about how an editor works with them. This leads to different ideas than you would get from a purely passive editable representation such as text.
A language workbench separates the storage representation from the editable representation. The storage representation is now a serialization of the abstract representation. A common way to do this is XML - but this XML isn't designed for human editing. Having XML as the storage representation is helpful for tool interoperability - although such interoperability is likely to be very hard.
A bit off-topic but I love this quote too...
"On most projects I visit the biggest issue is the communication between the developers and the business. If that's working well, then you can make progress even with second rate technology. If that relationship is broken, than even Smalltalk won't save you."
I have definitely seen this in my current project. In general our team has a great and close relationship with the Business, but we had one developer who just didn't understand that - constantly went his own way, didn't communicate issues but instead made a "best guess". Whined continuously about the existing architecture and was always trying to change it, without bothering to query the reasons for it, and how it suited the Business in the narrow and broad sense. etc etc.
> If we agree on that, I think you need one or more
> domain objects that represent this raw data as
> objects. They'll be smart enough to know how to
> reformat them according to the needs at hand.
Yes indeed. One more quote and some blah and then I'll shut up...
"Figure 2 shows how this process works with a language workbench. The key difference here is that the 'source' is no longer the editable textual files. The key source that you manipulate is the abstract representation itself. In order to edit it, the language workbench projects the abstract representation into some form of editable representation. But this editable representation is purely transient - it's only there to help the human. The true source is the persistent abstract representation."
This seems to reflect my "type 1" solution. Make the Model clever enough to format the "raw" version to/from each editor format. Hmmmm, I can't help feeling that the downside of this solution is that it makes the Model own that conversion process for each possible editor. Is it possible that my "type 3" solution which gives the conversion responsibility to each editor, is a more scalable solution and puts the ownership of conversion in a better place (i.e. where it is required)? I can't help feeling the "type 1" idea means the primary Model becomes a little god-like. I guess you can argue that the model is the owner of the data in all its incarnations - editors just manipulate a single (given) format.
