Thread Rating:
  • 413 Vote(s) - 2.81 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.)
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 Files
.zip (Size: 48.47 KB / Downloads: 562)
Robert Shiplett, Curlr
Fredericton NB

08-05-2011, 08:55 PM, (This post was last modified: 08-05-2011, 08:57 PM by RobertShiplett.)
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

08-08-2011, 10:42 PM,
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.

08-09-2011, 01:12 AM,
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


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

Users browsing this thread:
1 Guest(s)

MyBB SQL Error

MyBB has experienced an internal SQL error and cannot continue.

SQL Error:
1017 - Can't find file: 'mybb_threadviews' (errno: 2)
INSERT INTO mybb_threadviews (tid) VALUES('187')