You might need to be familiar with Dolphin's MVP framework to care about this. It has long been accused of having a steep learning curve, but it also generates a lot of "This is great! Why did it seem so hard?" reactions. I certainly recall reacting that way, but like it enough that I want something at least close to it.
Seaside's approach to components is interesting too, and it might be possible to strike a balance between the two approaches.
Once I got the idea of MVP, I began to identify presenters with their contents. By that, I mean that I did not bother to name things like lastNamePresenter - the Presenter suffix is needless because the "presenterness" is clear from the context. The most common methods one writes are #createComponents, #createSchematicWiring (expressing interest in events triggered by components), and #model:.
Dolphin's framework expects one to name view resources when adding sub-presenters to a composite presenter. It might be useful to map that to providing the instantiating selector (or optionally a closure) that can ultimately realize the correct view/morph. The resulting views/morphs could be specified in code or by some type of graphical editor. Object Arts did much the same thing in D6 when they moved away from serialized view resources to ones saved in class methods. I am more interested in being able to write clean code than I am in having a graphical editor, though ultimately both end up being "needed" (programmatic creation of views will indeed be needed to do some things, graphical editors are convenient and might be demanded by some potential users).
IIRC, Gary did not think too much of my idea of having default models, but I like having working triads that can simply plug into a composite, or can be connected with a little work and value adapters.
Any strong opinions?
Bill
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Locked
