I find that a better way to deal with asynchronicity of UI-related calls
without creating spaghetti-code is to build handlers that you pass to dialogs.
[algorithm]
do_something()
okfunc = function () { //do something here }
elsefunc = function () { //do something else here }
ask_user(okfunc, elsefunc)
[/algorithm]
[generic dialog button handler]
if (buttonclicked==okbutton) okfunc()
else elsefunc()
[/generic dialog button handler]
This is not really a Laszlo-specific pattern. It's often a good way to deal
with modality when you're writing UI or network-related code that runs in a
non-blocking environment.
If you want to pass state, may want to build build and pass Delegates rather
than functions or you may want to pass an object that encodes state similar to
the code that you suggested below. Passing handlers is really the way to go if
you want to generalize your dialog and keep all handler logic in one place.
-e
On Sat, 14 Jan 2006, Michael Pliskin wrote:
> Hello Dan,
>
> The basic problem of Laszlo modality implementation, from my
> experience, is that it makes really difficult to program some user
> interaction in an organized way. Consider traditional approach:
>
> do_smth();
> ask_user();
> if (user_said_ok) {
> do_smth();
> } else {
> say_good_bye();
> }
>
> At least the logic of the entire process is quite clear now. You can
> easily code a sophisticated algorithm in this way. In Laszlo,
> however, things are different. The code is split into multiple
> pieces (corresponding to individual event handlers), and, to make
> things worse, the state is not preserved!
>
> [algorithm starts]
> do_smth();
> ask_user();
> [method ends here]
>
> [on_ok event handler]
> do_smth();
> [/on_ok event handler]
>
> [on_cancel event handler]
> say_good_bye();
> [/on_cancel event handler]
>
> In each event handler you need to think more and more about what has
> happened in the past, what is the application state etc.
>
> Do you know a good or at least acceptable way to fight this problem
> in Laszlo? I was thinking about passing the state to doModal()
> function in a way like
> doModal({var1: var, var2: var2});
> and make dialog fire some event when closing passing two parameters:
> - this saved state
> - some kind of result code
>
> At least, the problem of state transition can be solved this way...
> Any thoughts about that?
>
> DS> Ah, yes, the Java dialog idiom ;). Modal dialogs do not work this way in
> DS> LZX.
>
> DS> If you need to retrieve a value corresponding to what the user clicked,
> DS> you can have the button's onclick method generate an event (or set the
> DS> value, or call method that sets the value, etc.).
>
>
> --
> Regards,
> Michael mailto:[EMAIL PROTECTED]
>
> _______________________________________________
> Laszlo-user mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
