stepharo wrote
cleaning Spec API.
+10 ! just general remarks i have about Spec: I think the role of Spec may be clarified. If Spec is just an UI builder we may remove the "overengineering" and we need another framework that provides someting like MVC, MVP, MVVM or ... If Spec intent to be an "app" framework, it is too confused now, and yes, it needs a clear separation between the presentation, the presentation logic, the domain logic, ... Maybe, extending the SpecLayout's responsibility should be one idea to handle the full "presentation" part, like the role played by markup languages. I'm not saying I want to transform Spec to XML :), but its role is basically the same. The existing separation between the widget declarations (instance side) and the widgets composition (class side) seem confusing to me. And we need also a clearest way to bind domain models to widgets. Using #whenSomethingChangedDo:aBlock everywhere make code a bit hard to read and to debug, if not completly ugly in complex UI... For me, the first goal of an UIBuilder (graphical or programmatic) is to ease the presentation and to ease the two-way data-binding with domain data/logic. If the ease-of-use of Spec is not more obvious compared to the underlying widget libraries (Morph / Bloc soon maybe...), it will be difficult to convince people to use it in future developments... But it is maybe a bit off topic -> "cleaning Spec API". Cheers, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/call-for-cleaning-ideas-around-Spec-tp4893494p4893625.... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.