> Err.. let me be more specific then.
>
> I assume that part of the view will be a view of the local filesystem.
> How would a Java controller notice non-UI invoked changes in the local
> filesystem?
First solution: it could just poll the directory tree and compare it with the model.
> Win32 provides a mechanism to do this. I was wondering if Java provides
> a similar mechanism.
>
> For example see:
> /subversion/subversion/clients/win32/svn_com/SVN.cpp:
> CSVNWorkingCopy::FileNotificationThreadProc()
Second solution: if there is already a mechanism like this built into SVN maybe
a coupling between such a controller and this mechanism via JNI.
Alex
>
>
> Bill
>
> -----Original Message-----
> From: Alexander Mueller [mailto:alex@littleblue.de]
> Sent: Thursday, July 12, 2001 11:33 AM
> To: Bill Tutt
> Subject: Re: GUI Notes
>
> ...
>
> Bill Tutt schrieb:
>
> > Hey, does Java allow you to catch event messages when a file you're
> > interested in changes?
>
> Depends the way you are implementing things. I am planning to implement
> at using the Model / View / Controller design pattern.
>
> the model is the data your interested in, the directory tree, the files,
> revision,
> props and so on.
>
> The View displays the data in a specific way, for example as a swing or
> whatever
> component. The view itself cannot modify the data in the model. So often
> it is used in conjunction with a controller.
>
> The controller modifies the data. In our example there may be a backend
> controller that requests data from the repository. Another controller
> may be
> used to reflectd directory and files changes to the model.
>
> Okay. As soon as the controller modifies the model (the data), the model
> notifies all of its views that a change has occured.
>
> The views may update...
>
> >
> >
> > Atm in the WinSVN COM layer, the most substantial part of its work is
> > involved in setting something like that up, so that the UI code will
> > know when it needs to refresh its file list view.
> >
> > Bill
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
>
> Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006