 |
|||||||||
|
|||||||||
|
|
I have been poking around inside Acropolis for a little while now and have been attempting to make it work for some sample, proof-of-concept style apps. Basically whenever I get a new technology in my grubby little hands, I don't stick to "Hello World" apps, I try and simulate a real-world app and see what happens. I've come across a couple of things that I really dislike about Acropolis. One of them I think is a design issue that might be personal taste (it might be influenced by my exposure to Cocoa, you be the judge). The other I think is a massive, gaping oversight by the Acropolis folks at MS that I surely hope they clear up in the next CTP or the Beta 1.
Notifications
Right now one thing that truly pisses me off about Acropolis is the communication between parts. While I am all for loose coupling, and clear separation of concerns, and encapsulation and limited visibility - all of those things make my inner architect squeal with delight. However, there are practical concerns here, too. Here's a sample scenario. I've got a Part that's a toolbar. I've got a bunch of parts in the middle of my window, many of which are dynamically placed there at runtime. I've got a bottom part on my window that is kind of like a toolbar also, but it's reactive as well (it changes in response to what part has focus). This is a pretty common paradigm for any app that has toolbars or toolstrips - so you shouldn't have any trouble identifying with the scenario.
Now let's look at how to do this in Acropolis. First, we take the toolbar and then set up notifications. These notifications will be fired any time a button is pressed. Now, rather than allowing a loosely coupled listening for button presses by "peer" Parts, the parent part must then listen for the notification and then explicitly, by name locate the part that might be interested in that notification and then manually send that notification to the child part. There might be a better way to do this with the data pub/sub controls, but I am talking about pure message-oriented notifications ... the freaking keystone of composite application building. What I found was that when building an application in this way using Acropolis, the maintenance of the notifications was extremely tedious. You can't rig any of it visually so you have to rig up the listens and the fires in various places in C#. So that's what you get with Acropolis. Here's what I want:
Any part in a part container can fire notifications into the ether (the container in which the part is found). The notification is seamlessly handled by the framework. Any other part in the same container that has registered that it is listening for notifications with that name will then be notified. So, in the case of the toolstrip, each part can say "yeah, I'd like to know when the user hits Save" if it wants. The part container, which should be relatively agnostic to the specific data types of its children, doesn't have to manually figure out "well, I got a Save notification..who gets it? Only the programmer knows, so let's hard code that logic." Note to Microsoft: make intra-part communication in Acropolis work like the NSNotificationCenter does in Cocoa and I will be a happy camper.
Applications with Multiple Windows (not singleframe MDI apps)
So my first complaint might have arisen from personal preference, stylistic taste, or the fact that I've been exposed to Cocoa programming and freaking love the NSNotificationCenter. The complaint I have about Apps spawning multiple windows can't be dismissed as subjective. Basically the problem that I've encountered with Acropolis is that it is designed specifically to have a single over-arching parent container window. That parent container window can be rigged to either contain individual Parts like it was a glorified controls container, or the container window can be rigged to be a document/MDI-style boss. Here's the rub: I can't create windows outside the Shell that contain parts. That's right. There's no such thing as File -> New -> Acropolis Window. A forum poster suggested that one workaround might be to create a standard WPF window, drop a partpane into it, and then programmatically, at runtime, use the pipeline manager to obtain an instance of a Part and stuff it into the part pane in the new window. Sorry - I don't buy it. If I have to hack in order to pop open a simple dialog box with a couple parts in it, then the framework is broken. Note to Microsoft: Beta 1 or CTP2 of Acropolis needs to have a Visual Studio "Orcas" template for creating a new Window that is a top-level part pane container. Period. This is a showstopper. While it might be nice to assume that in a perfect world all interaction with a user takes place in a single framed window, that's not how reality works. I can't think of any desktop apps that I've written in recent history that performed all their work in a single window.
Ok, I'm done ranting. Time to go back and spend some more time coding.
Kevin,
Kevin,
