(responses inline) On Apr 27, 2014, at 10:17 AM, kmo <[email protected]> wrote:
> No one has replied to this post, so I thought I would add my two cents of > wit. Sadly, I did not have time to study the example because I’m traveling. There are some items in this mail that however I would like to quickly respond to. (Hopefully I will have network along the way somewhere.) > Beyond that, i have to say that the example just confirms my decision not to > use Spec at all - at least in its present state. From your comments below it is not 100% clear to me why you choose not to use Spec at all. Sure, there are some features that are missing. Are these showstoppers for you, and if so, why? Please list and explain. > Though this is supposed to be a /dynamic /Spec example, it's really not that > dynamic, is it?. You are creating separate instances of a data entry screen > here and each separate instance has its own layout - but a truly dynamic > Spec example would be one which dynamically/ changed an existing instance/. > But this cannot be done currently in Spec as there is no way to change the > size of the Spec window once it is created (Bug 13059). I do not agree with your generalization. Still it is possible to add and remove widgets on the fly, as we present in section 5.1 of the Spec chapter in the Pharo For The Enterprise book, […] > One thing I had not considered before seeing your code was the consequence > of Spec's decision to call its widgets /models/. This causes (at least in my > mind) a confusion between the ideas of a model as a problem domain object > and a Spec widget. As we say in the documentation in the book: a widget is something you see on the screen with all its associated state and behavior. But with Spec you don’t code the stuff you see on the screen, you just think about it’s state and behavior, i.e. the model *of the user interface*. > So, in your example, you have a /PartiesModel/ class. So > I have to look to see if this inherits from Object or Composable Model > because we now have two different ideas of model in the application. > > So in your code you have: > > DOPartyEditor>initializeWidgets > |models| > models := OrderedCollection new. > > when I read this I was thinking about models as in MVC, not as in > ComposableModel. To my mind these lines would be better written as: > > DOPartyEditor>initializeWidgets > |inputWidgets| > inputWidgets := OrderedCollection new. Or instead call them uiModels. > Finally, we have the finished product - which I would not show to anyone as > an example of a Pharo user interface. You know as well as I do that as soon > as the user types in anything they will immediately hit bug 13013 - the font > size is far too small and cannot be changed. Can you imagine in what a Java > or C# developer would think of this: /Good God these guys are so lame they > can't implement the most basic component of a data entry interface - a text > entry field. No wonder they can't get Pharo to open up two windows! And yet > they claim they have a better way of programming. What are they smoking!./ There is only so much that a group of, essentially volunteer, developers can do. Comparing it to the multi-million dollar investment that Sun/Oracle/Microsoft/ … have performed is in getting their infrastructure right, inevitably will find issues. The question is: are they showstoppers? What can we do, given our situation? > Who knows what they would think if they knew that an even simpler user > interface component - the label - was buggy as well. A /LabelModel /really > only has two properties: /label /and /emphasis /and one of them doesn't > work! Can you clarify the problem? Is there a bugreport? (I’m without network ATM, otherwise I’d check). > I really think some of this needs to be sorted out before Pharo 3 is > released, otherwise the problems with Spec are going to give a very bad > impression to any developers who take a look at Pharo hoping to find > something better than Java or C#. A possible public relations disaster? I think you are exaggerating. Spec is already an improvement on the UI builders that precede it, and no PR disasters have happened because of these previous frameworks. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
