No one has replied to this post, so I thought I would add my two cents of
wit.
Many thanks for the example - any addition to the Spec documentation is
really useful and I've certainly learned some stuff from your code. But I
think if you are aiming to help people learn Spec, then you should add as
many comments to the code as you can. Also, allowing the user to edit
existing list entries would make the example much more complete.
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.
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).
It is this limitation I believe that has made you take the separate
instances route using a class method. The code for this just seems unnatural
to me:
DOPartyEditor>>on: aPartyClass
^self basicNew
partyClass: aPartyClass;
initialize;
yourself
A more natural approach would be to construct the instance as normal with
/DOPartyEditor>>new/ and then set the party class. Changing the party class
could then trigger the layout change, allowing the instance to rebuild
itself. But this is impossible because of the window resizing issue. I think
this is a clear case of Spec's limitations having a detrimental effect on
code quality.
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. 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.
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!./
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!
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?
--
View this message in context:
http://forum.world.st/Dynamic-example-for-spec-tp4756370p4756683.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
