Spec is all about *composing* models. If you want a GUI with many UI elements and try to build this with a single model, spec won't be much help.
2014-12-19 20:54 GMT+01:00 kilon alios <kilon.al...@gmail.com>: > > "Can you help me understand?" > > sure take this simple example I want to add a button for choosing > background color, I am giving you the list of my problems > > 1) If I want to initialise it I cant use the initialise method of my class > (why ? ) I have to use initializeWidgets > That's the distinction spec makes for composing models MyModel>>initialize "do whatever your model *implementation* needs MyModel>>initializeWidget "instantiate the (sub)models your model is build upon" MyModel>>initializePresenter "interconnect the internals of your (composed)model" > > 2) Inside initializeWidget I create an array that describes the name of > each button but no that is not enough > > 3) I have also have to initialise seperately the button with self > newButton but wait that is not enough > Not both are needed, either you call newXmodel for every model or you call instantatieModels with an array of "instanceVars and Models" > > 4) I have to define the action of the button the only step here that makes > sense to me but even that is not enough > > 5) I have to create a method that returns the name of the button and to > makes things even more verbose > spec is designed to provide *reusable* models. > > 6) I have to define a method at the class side for positioning the button > . No idea why this goes to the class side > A model is defined by its structure and layout, if you want to use a different layout, you can subclass the model and define your own defaultSpec, or a pragma, or you call it explicitly #buildWithSpec: > > And all that so I can say to Spec take this button which has this label > and will trigger this method and put it in that place. Java Swing is not > that verbose. > Take a look at DynamicComposableModel (the examples in pharo or the examples posted on this list), for a simple GUI you only need some few lines of code. > > Generally I dont like this approach that I need to generate so many method > and so many steps to define something so simple. > > So what happens right now is that I have a very simple GUI with 7 buttons > and 6 moprh that i use to display colors , guess how many methods my class > has . > Can you show me the UI (screenshot/ or a drawing of it) you try to develop? I would love to see how I would construct the UI based on spec. > > 36 !!! > > By the way in case you wonder 90% of the code is just Spec. For me thats > plain unacceptable. > That's not unusual. 90% spec means "not 90% morphic" > > So what happens if I have a GUI with over 100 buttons do I need 300 > methods just for Spec ? Really ?? > If you have 100 buttons in one GUI without the possiblity to divide it in small reusable parts, then spec may be your smallest problem. The existing API and implementation of spec is not well designed. Even though it is meant to be independent of the backend, the existing models and adapter pretty much resemble morphics (not well designed (or badly grown) ) api. Some parts of the exising models looks like: "hey look how easy it was to add this and that and ..." (Just look at the number of instVars and announcers and different whenXDo: methods) Both, spec and morphic are grown, and that is bad for most frameworks. Of course we can discuss this and try to fix bugs or cleanup the implementation - > bugtracker. The two years I am working with pharo and reading this list, I have read more complains than constructive critics (about morphic and spec). We have the following options: - complain - constructive critics - contribute - develop a new framework (develop *active*) choose wisely
