Sonntag MVC without strings or name

[RobertShiplett]

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
{define-screen-command
?name:identifier || rs: uses name.name 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 Sonntag-Event-Bus-3.zip

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 ...

[RobertShiplett]

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 lcurlr.blogspot.com and lcurlr.tiddlyspace.com

A strong case for re-thinking MVC was also made by Dolphin Smalltalk at object-arts.com

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.

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.

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.

We have macros and traits, so we could enforce a pattern {mvc-command a-command-object}

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.

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.

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.

[fukuta]

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:

Code:

{define-class FooScreen {inherits {Screen-of FooGraphic}}
  {constructor {default}
    {self.add-command
        {SimpleCommand
            "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.

Code:

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

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

|| handle message
  {method protected {handle-message
                        sender:#BroadcastEventTarget,
                        message:any
                    }:void
    {type-switch
     case msg:ApplicationTerminatingMessage do
        || handle here
    }
  }

Anyway, Sonntag's screen command stuff has much room for improvement so any suggestions are welcome.

[RobertShiplett]

Hi

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 sourceforge.net 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.