If I'm following your example, it's something like this:
-------------------------
Object script
-------------------------
-- Package up details about
-- what got the event
-- what the event is
-- Pass this package of data up to a project method for this form named
Proposals_FM
In native V13, this would be something like this:
Proposals_FM ("PROP_F029Networkrb";On Clicked)
(You're packaging more information than this, obviously...but just to
translate...)
Meaning that the object PROP_F029Networkrb got an on click, please deal
with it.
-------------------------
Proposals_FM
-------------------------
-- Unpackage the details provided
-- Generate pointers to the focus object and current object
-- Extract the name of the focus object
-- Extract the event code
Then you've got some kind of case like
Case of
:($form_event=On Clicked)
:($form_event=On Data Changed)
else
End case
Something like that?
It also looks like you've got various bits of housekeeping code. More
interesting is that you're being open-minded about setting events manually,
rather than just passing through events from 4D. If so, I'd say that's the
most powerful part of the system, as I understand it. You can then "send"
events "to" various objects without having to click (etc.) them at all.
That's great for complex widget interactions, testing mode emulations, etc.
So, am I on track with what you're suggesting? I'm primarily interested in
division of labor/delegation of responsibility questions and I've got
Model-View-Controller in the front of my mind.
For those that don't know, Model-View-Controller (MVC) is a common pattern
in most of the development world. Well, all of it. Aparajita explained it
to me once about 20 years ago. He's one of those people that makes complex
concepts easy to understand...I always feel so much smarter afterwards ;-)
MVC is one of those subjects that has gotten a bit messy as people use the
term in different ways, think they know what it is when they don't, mistake
a specific implementation they know for the pattern in general, use it
without realizing, etc. So, yeah, it's a bit of a struggle sometimes to
find a clear and meaningful description out there. And there are tons of
valid variants around. The basic idea is to have a clear "separation of
concerns" between your data (Model - but it might be a bit more than what
we normally think of as data - it's also the rules for the data),
presentation (View - like a form, in a 4D context) and the code to mediate
them (Controller - scripts, form methods and subroutines, in 4D.)
Since MVC comes from the OOA/OOD world, it's not an algorithm, it's a
"pattern." Implementation details are left as an exercise to the reader ;-)
But in a good way. It's a nice clean design, and then we hit the real
world. Sometimes it feels weird to have all of the rules in the Model and
it's quite tempting to put them into the Controller. Sometimes it's hard to
figure out if you've got one model or two. For example, let's say you use a
listbox to display some data calculated out of 4D. So, the data is in the
"model" and so are the calculations. The view is the listbox, and the
controller just needs to know how to ask the model for the data (think of
an API call for data), and knows how to pass it into the view for display.
Okay, that's not too hard to follow. But what if you want to do something
like track the state of the listbox? Like, what the user last clicked on to
sort, how they've resized columns, how they've reordered columns. Where
does that state data go? It's not part of the business data, it's part of
the current presentation. But it's important. If you reload the data, you
want to leave the users settings in place rather than wipe them out with
defaults. Anyway, you may end up with one of several designs - including
have a state manager that stores models of states.
A helpful (read: "essential") component of MVC is having a messaging system
to coordinate communications amongst the parts of the system.
Traditionally, what we had was
* Parameter passing:
Real 4D, straight from it's Pascal/Structured Programming roots. Very
respectable, but limited because there's only one thread of execution in a
process.
* Parameter passing (2):
Bundle stuff up into a BLOB, record, bag, OT object, etc. and pass that.
* Stuffing things into globals and sharing them:
Pathological, just a bad, bad idea. With rare exceptions, but this is the
source of so much pain in the 4D world. Well, in any language...but lots of
languages at least make it harder to do. (Still, programmers are a creative
lot...people always find a way to inject bad globals...they are so
temptingly, superficially "easier" than well managed, modular data.)
* SET PROCESS VARIABLE/Etc.
The date rape drug of 4D commands. They should never have been put in the
language. We should have had CALL WORKER and CALL FORM (or similar) all
along.
So, you can see why I'm interested in V15/V16 and am curious about how
other people are approaching UI development given the new option of a
message bus. We've got reliable *asynchronous* messaging. Too sweet. Anyone
deliberately implementing an MVC pattern in V16? Comments on trade-offs in
a 4D-specific implementation? Anyone want to chime in and correct whatever
errors that I've made in explaining MVC? I'm sure there are important parts
of left out and/or explained poorly/incorrectly.
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
