Post Reply 
Thread Rating:
  • 276 Votes - 2.79 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sonntag MVC without strings or name
08-05-2011, 06:15 AM (This post was last modified: 08-06-2011 11:53 AM by RobertShiplett.)
Post: #1
Sonntag MVC without strings or name
I have a strong sense that we should not have used Visual "name" property as the Sonntag key

I would suggest that name is just too useful when inspecting a layout.

From my experience, the use of a string such as "content" or "clear" in the example code is already problematic. We have a lot of content and things that may not be clear in comments.

I have built an alternative (the project is from the Linux IDE, not eclipse) which exposes no strings in the code.

You can go to one place to inspect all messsages, another for all commands, another for all graphical tags. I think that a case can be made that in the Sonntag framework a Graphic class should have a set of tags. Perhaps the actual tags should be integers which map to meaningful tag names.

The one exception is the use of an identifier with a name matching the action in the macro

{define-macro public
|| rs: uses Prefer to construct the Identifier using a token

When the above is passed an expression ScrnCommand.cmd-indentifier as the "name", any change can be made in one place for any one feature. I hope we will consider this minor macro alteration, if only to allow either an identifier or an expression.

Please find the zip attached for

MVC never had a gentle slope - Curl should always have it. In this version everything is known by its name. As a test, you might search the project for the string "clear".

Comments and constructive criticism are most welcome. i post it here as it is the only forum for which I have permission.
Of course somethings are a matter of taste ...

Attached File(s)
.zip (Size: 48.47 KB / Downloads: 284)

Robert Shiplett, Curlr
Fredericton NB

Visit this user's website Find all posts by this user
Quote this message in a reply
08-05-2011, 08:55 PM (This post was last modified: 08-05-2011 08:57 PM by RobertShiplett.)
Post: #2
RE: Sonntag MVC without strings or name
(08-05-2011 06:15 AM)RobertShiplett Wrote:  If you run my alternate version of the demo, you will see "clear" and "content" in the main applet and each sub-pane This is my best obvious case for not using strings as identifiers to search on and code against in MVC. At least in Smalltalk after 1980 we were using Smalltalk symbols. I will post on the recent Smalltalk Announcements framework over at and
(08-05-2011 06:15 AM)RobertShiplett Wrote:  A strong case for re-thinking MVC was also made by Dolphin Smalltalk at
(08-05-2011 06:15 AM)RobertShiplett Wrote:  MVC was a strength of Smalltlalk ( still in use at JP Morgan and other major corp's - more widely used than Curl and for a decade longer) - but it is also what made for a steep learnng curve.
(08-05-2011 06:15 AM)RobertShiplett Wrote:  We might also remember that Struts 1.0 got MVC wrong - as did the first pass at Java so I hope we are open to learning from other engineering experience over the years.
(08-05-2011 06:15 AM)RobertShiplett Wrote:  It was our experience over decades in Smalltalk that >> perform #symbol ( the equivalent of Curl's {do-command cmd-string} had to be held in check.
(08-05-2011 06:15 AM)RobertShiplett Wrote:  We have macros and traits, so we could enforce a pattern {mvc-command a-command-object}
(08-05-2011 06:15 AM)RobertShiplett Wrote:  I hope we can look back at Sonntag as "Smart-tag" and get this tagging pattern right on a 2nd or 3rd iteration and incorporate it into the defaults for the AdvancedUI.
(08-05-2011 06:15 AM)RobertShiplett Wrote:  And we must beware of the simple demo - something that we also learned in Smalltalk. The only test of a framewrk is a real app that is "handed-off" by the expert and that then goes on to survive the code change-request and maintenance cycle.
(08-05-2011 06:15 AM)RobertShiplett Wrote:  When the authors of Annuncements were asked why their framework was different, they said because now we were using objects. That should be sobering for the original OOP + MVC language. MVC is not easy to get right the first time.

Robert Shiplett, Curlr
Fredericton NB

Visit this user's website Find all posts by this user
Quote this message in a reply
08-08-2011, 10:42 PM
Post: #3
RE: Sonntag MVC without strings or name
Do you mean we should not use strings as key things?
Putting all strings into one place as in your example might be a good practice, and as you know Sonntag doesn't restrict that way.

Unfortunately 'define-screen-command' doesn't take string name (but identifier).
Instead, you can write as following to use string:

{define-class FooScreen {inherits {Screen-of FooGraphic}}
  {constructor {default}
            "my-command", || string name
            execute-proc = {fn => |# do your command #|}

This is not proposed way of Sonntag but another way that will work.

As to event bus messages, send-message takes 'any' value (not just only string) so
it is recommended you to use specific object as a message.
String messages in Umemura's example are probably for the sake of simple to describe how to use it.

|| declare message object
{define-class public ApplicationTerminatingMessage}

|| send message
{screen.send-message {ApplicationTerminatingMessage}}

|| handle message
  {method protected {handle-message
     case msg:ApplicationTerminatingMessage do
        || handle here

Anyway, Sonntag's screen command stuff has much room for improvement so any suggestions are welcome.
Find all posts by this user
Quote this message in a reply
08-09-2011, 01:12 AM
Post: #4
RE: Sonntag MVC without strings or name

The intention is to always keep plain text "logic" strings out of exposed logic in code. The example shows multiple exposure of the same string in different pieces of source logic. This is one case where it is not "less" that is more, but "fewer is better."

The macro requires the addition of another syntax-switch to accommodate an expression or a token for the identifier and for that reason I have requested to join that group for Sonntag.

In fact, the current macro reconstructs an Identifier from that which is passed in by using only its name - so better to pass an object in the first place. The changes required are really that simple.

Real-world code is too complex for us to needlessly leave strings lying about - even disquiesed as identifier names for macros - and the example is excellent for it uses such common strings as "clear" and "content".

If you then add the complication that strings must have some "command" format, you needlessly add complexity and expose that complexity - when all that was required was
1) encapsulate (as an option)
2) a more flexible macro that also accepts an expression to support 1)

That way no one is forced to fully separate in the way I advocate, but neither is such separation precluded by the macro alone.

Yes, message is Any type. But the macro is expecting only an Identifier. It is then up to the macro to ensure that the expression is acceptable.

Robert Shiplett, Curlr
Fredericton NB

Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Sonntag で別画面(Screen)のイベントを呼ぶ umemura 2 3,747 08-04-2011 02:47 AM
Last Post: RobertShiplett
  Sonntag でCommand を呼び出す umemura 4 3,754 08-02-2011 09:24 AM
Last Post: fukuta
Forum Jump:

User(s) browsing this thread:
1 Guest(s)