Hey! Thanks to everyone for the detailed and intriguing responses so far.
I've got some stuff on my plate so will have to put off more detailed
responses, but wanted to send my thanks immediately and add a couple of
thoughts that might bring out a few more details. Also, I want to
acknowledge that this is fairly difficult stuff to talk about on a mailing
list. I want to wave my arms and use a white board to draw diagrams with
circles and arrows and paragraphs of text on the back...
Kirk and Arnaud, I'm not fully following what you're describing but I don't
think it's because you're explaining it poorly. I think it comes down to:
* Reading 4D code on the NUG is pretty had to do.
* You're into a level of fine implementation detail that makes perfect
since once you've gotten to that point, but possibly not before.
If I understand the gist of what you're describing, it's largely about the
organization of object/form methods within your 4D projects. You've made
what sound like slightly different choices and tradeoffs on where to put
control, what to pass, and how to pass it. I'll offer a short description
of one way I already handle events, and then describe a scenario I'm
planning to use V16 for that's quite different.
Tiny example: Right-click on a listbox. I've got a lot of listboxes and
they all tend to have right-click options. For those that haven't used
dynamic menus, you specify a label and a key (string) for each of the
right-click items. The user clicks, the labels are shown and you get back
the key. From there you code can do what it likes. So, if the menu reads
Copy
Save...
Reload
...and they select Save..., you get back whatever key you associated, like
"Save_Listbox_to_File". So what code handles that action? It's totally
generic so I like to use a pretty classic event cascade. Illustrated with
pseudo-code
RightClickListBoxHandler(Listbox name/pointer/whatever;$key)
The RightClickLIstBoxHandler method can deal with the event and you're
done. But that's kind of limited. Perhaps you want to do some calculations,
formatting, or filtering specific to the listbox. In that case, you might
want something like this for a listbox with employee salaries:
$key:=RightClickEmployeeSalaries(Listbox name/pointer/whatever;$key)
If ($key#"")// The key was not handled by the listbox-specific handler
$key:=RightClickListBoxHandler(Listbox name/pointer/whatever;$key)
if ($key#"")
// Unprocessed key. Bad.
End if
End if
Eh? The custom handler gets first crack at dealing with the action. If the
custom routine doesn't deal with it, the event remains unprocessed and
falls into the generic RightClickListBoxHandler. If that doesn't handle it,
you've got a bug. There are several advantages to this sort of cascade:
* You don't need to repeat yourself much in the code.
* Generic code can be used easily, or overridden easily.
* Your custom code can do something in response to a generic event and
*not* consume the event. Meaning, the custom handler could tweak the data
on "Save..." so that it's been filtered/formatted/etc. before it reaches
the generic handler. [A slightly different parameter list or unillustrated
call chain would probably work better in that case.]
* This can all be done 'off-screen' if you're in test mode. There's no
requirement to have an actual form on screen to make the objects work,
you're just passing messages.
* The generic code knows _nothing_ about specific listboxes.
* The specific code knows _nothing_ about the internals of the generic
routines.
It's a pretty tidy approach, supports testing, has a clean delegation of
responsibilities, division of labor, allows for customization and avoids
redundancy. But this is just a listbox thingy I'm talking about - and I'm
sure many people have something quite like this with way more features.
The main point of the previous description is to push towards describing
how messages and responsibility flow through the system. My next example is
what I'm excited about V16 for. Okay, here's the setup. (In this case, an
artificial example, but it's enough to get the idea across.) You've got a
form with three listboxes that interact:
[Available Territories] [Selected Territories]
[ Matching Records ]
You're searching based on a state/territory/region. So, MA for
Massachusetts, or NSW for New South Wales, or AB for Alberta, etc.,
depending on your setup. The list on the left shows what's available and
not yet selected. Click on it and an option disappears from this list and
appears in the selected list. As items appear in the 'selected' list, a
search is done on "Matching Records." Now here are the rules:
* None of the listboxes can know about the existence of any of the other
listboxes.
* This should take virtually no code to implement.
* If you want to add sorting to a listbox, there is one and only one place
for the code to go.
* If you want to add a '15 sales offices found' sort of message, you can
add it to the form and make it work without telling the 'matching records'
listbox that the label exists, needs to be populated, or how it's populated.
* Everything should be testable without a form displayed.
This finally all looks pretty achievable in 4D natively and is why I'm
talking and asking about MVC and messages.
Cannon, is this an approximation of what you're doing? Is anyone used to
other environments doing something like this in 4D?
**********************************************************************
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]
**********************************************************************
