[mcclim-devel] Push or Pull data in application

[Oliver Uvman]

Oh, Matthieu, thanks! That is perfect :D! I didn't know :after
functions could be defined away from the function itself. Does this
also work with normal (defun ..) functions? We are not using the OS
part of CLOS in this lab series, so the entire lab is implemented with
just normal functions (not even macros).

If this can't be managed, it seems like the 'incremental redisplay'
facility is just what I need. Always a pity to reinvent the wheel.

/Oliver

On Tue, Jul 13, 2010 at 16:48,  <matthieu.villeneuve at free.fr> wrote:
> ----- "Oliver Uvman" <oliver.uvman at gmail.com> a écrit :
>> Matthieu: Yes, that would be the push-type mechanism. The problem
>> about it then is that the backend would have to know when a gui is
>> running or not, and be able to send messages to that gui (keeping
>> some
>> address reference to it or whatever). I'd rather not touch the
>> backend
>> code at all, as that would muddy the waters for the people who are
>> looking at the first large lisp app in their lives.
>
> The thing is, even if the :after methods I was talking about are
> "attached" to backend generic functions, I consider that they
> belong to the GUI code, so the backend code doesn't have to
> maintain information about the GUI. Something like this:
>
>  (in-package :app-gui)
>
>  (defun draw-foo (object)
>    ...)
>
>  (defmethod app-backend:set-coords :after ((object foo) x y)
>    (when *application-frame*
>      (draw-foo object)))
>
> That way, the backend code doesn't depend on the GUI code.
>
> If you group those :after methods in a separate file, you could
> even choose to load it or not, depending on whether you want to
> allow direct modifications of backend data (which should be
> reflected in the GUI).
>
>> Maybe I should also note that this is the first time the students
>> meet
>> layered abstraction, so the app so far has a strict top-down
>> dependency model. Code in one layer may not depend on code in a layer
>> above it. Preferably I'd like to keep the gui in a layer of its own,
>> above all other layers. This would keep things simple for the
>> students, they'd never need to look in the gui code (if they don't
>> want to).
>>
>> /Oliver
>>
>> On Tue, Jul 13, 2010 at 16:01,  <matthieu.villeneuve at free.fr> wrote:
>> > Hello,
>> >
>> > ----- "Oliver Uvman" <oliver.uvman at gmail.com> a écrit :
>> >> The problem I know I will eventually run into is updating the Clim
>> >> interface when changes to data have been made through manual
>> >> interaction with the backend. The solutions are either push or
>> pull
>> >> based, I guess. Push based is not really prefered, because the
>> backend
>> >> would have to keep track of the gui so it can send messages to it.
>> >
>> > [Disclaimer: I don't remember much about GUIs and CLIM...]
>> >
>> > Couldn't you define, as part of your GUI code, and for every
>> "relevant"
>> > backend method that updates the application data, an :after method
>> that
>> > updates or refreshes the interface contents?
>
>
> --
> Matthieu Villeneuve
>