Getting to grips with MVC

[GaryD]

I’m still trying to get to grips with MVC and I’ve read through the docs and watched James’ Smalltalk Daily clip on the GUI creation, the latter being particularly useful. I’ve also been reading some older literature on VW. Now I’m become confused (again).

In my mind I want to develop a separate data domain based on a bespoke class subclassed from Object (although it could be from UI.Model). I would also rather stick with the dependency mechanism rather than use the new event/notification mechanism.

For a true MVC approach that separate the data domain from the GUI, what is the preferred technique:
   setting up ScheduledWindow and assigning a model
   - or -
   setting up UI.WindowSpec and then assigning a model
   - or -
   some other way

General thoughts please?

[charles]

Gary:

c).some other way

its hard for at least me not to answer your question in a practical way and not in the context of traditional VW development. So it seems you are building a custom view i.e. not an application but a custom view in order to reflect aspects of a model in ways that the current set of widgets in VW can't. If that's the case, you are responsible for a defining/developing the following: a model class i.e. your domain class , a custom view which you would at the very least subclass from View and a custom controller class which at the very least would be subclassed from Controller. All of this would be incorporated into VW's presentation framework by using a View Holder i,e, when painting your application.

the mechanism for notification of change between your custom model and your custom view is up to you i.e.use changed:with etc or triggerEvent: etc. However, if you want your view to interact with the user for example in response to mouse activity you would have to implement event api on your custom controller.

If you are not building a custom view then let me know i.e. if your model aspects can be reflected by using input fields , text areas and so forth then what you may want to look into is AspectAdaptors.

But ask more questions , the more specific the better.

hth

[GaryD]

Thanks Charles

I am basing my approach on James' cast from
http://www.cincomsmalltalk.com/casts/stDaily/2006/smalltalk_daily-10-4-06.html
and I shall probably be adopting the BufferedValueHolder technique although I'm not ruling out AspectAdaptor.

My reference to "setting up ScheduledWindow and assigning a model" came from some older reading and I was assuming that this approach has been superseeded by that in James' cast (which even so is from 2006).

I hope that is clearer.
Gary

[charles]

Yes, so its not a custom view.

BufferedValueHolders are a close cousin to AspectAdaptors , with AspectAdapters every change happens immediately i.e. the moment the user inputs into a field upon tabbing and thus setting the change , the change is immediately propagated to the domain model. BufferedValueHolders trap all of those changes and allow the application to control when those changes actually dirty/modify the domain model. This is done by the tripping the trigger channel which you probably already read about.

[GaryD]

Thanks for confirming my understanding.

So, that's the way to go then, at least for simple stuff to get me started.

Gary

[charles]

yes, the only thing to reiterate i.e. as per previous conversations and which you know already is that to not mix in presentation code with other logic e.g. like data retrieval/persistence. Your app should interpret user requests e.g. press a button means "commit these changes" but that request should be delegated to a data access service provider and the parameters captured by the app should be passed accordingly to the data access provider.  This would go as well for the various services an application could engage. Thus making it all very pluggable.

[GaryD]

Hi Charles/all

I have started a basic app and would be grateful if somebody could tell me if I'm on the right lines by taking a quick look at what I've done so far (see attached).

Thanks
Gary

[charles]

Gary:

You are actually violating MVC in the sense that you are digging into the controllers/views , forcing widget invalidation etc. That's unnecessary instead instead the app should be able to interact with the aspect adaptors (buffered included) and the current subject channel.  You also look into setting up validation/notification callbacks, these will readily provide you with feedback on the input field changing including its underlying model i.e. valueHolder type. Read up on that in the appdevguide under docs.

I can provide some further feeback in the form of tweaks by making some quick mods to your prototype but it probably will have to wait till monday.

[GaryD]

Thanks Charles

I've had a pretty good read of the appdevguide but I'll take another look on those subjects.
I had quite a lengthy search of the class hieracrhy trying to find a GUI-based "dirty" method or equivalent, without success, hence my rather clumsy manual comparison method.

Anything you could provide to guide me would be most helpful.
Thanks.
Gary

[charles]

Gary:

sorry for my tardiness, had some pressing issues.

Anyhow, there's the proactive approach and then there's the reactive approac

Proactive

Use the validation callbacks e.g. a validation on change  from your "item" field , where you can ask the user if he wants the change persisted/applied i.e. since you are using BufferedValueHolders although the field value has changed the mod has been buffered and the domain not updated, if the user says "ok" then apply i.e. trip the triggerChannel i.e. "triggerChannel value: true"

Reactive

i.e. after the fact. BufferedValueHolders can be asked if they are "buffering" i.e. via "isBuffering" . A BufferedValueHolder will be buffering when an input field changed has updated the bVh but said changed has not been propagated to the subject i.e. domain model. In other words, the bvh is "dirty".

hth and ask more questions.


FYI: Notice attachments in parcel form, setup a callback , added some comments.

[GaryD]

Thanks Charles

I can see exactly what you mean now. I hadn't looked long enough at the callback/notification options, but now it makes sense.

I shall continue along the proactive route.

[GaryD]

Just when I thought I was getting somewhere...

I've hit a snag, most probable due to not fully undertanding what's going on despite much reading.

Best to repeat my tests. Attached parcel files...

Run in a workspace using: MVC01Form open
Cick on the Inspect button.
Click on the Next button to navigate to the 2nd item.
Change the value of #item from "item 2" to "something else" and then try to navigate away from the input field using Tab.
The confirmation dialog appears as I intended.
Clicking on "No" appears to work as intended. The new value is discarded and the original value of "item 2" is refreshed.
However, this is the problem -
Clicking on "Yes" does NOT appear to work as I intended. Looking in the inspector the new value has not been saved.
Furthermore, clicking on any of the First/Next/Previous/Last buttons continues to display #item as "something else" despite the value of #curr changing.
Despite "applying" the changes in #validationOnChange, the inspector still shows that the new value of #item is not propagated to the model.
It looks as if it is being retained in the buffer even though the trigger has been set to true.
I am assuming that although I am using "self trigger value: true" in my #applyChanges method, this isn't working as I expect and I am wondering if it is "out of context" in some way.
This is probably due to my understanding of the mechanism being wrong.
I've run numerous tests and made various code changes but nothing seems to overcome this problem.

I don't know if this is because of the way I am utilising the underlying data model as a kind of broker, although I don't see why it should given what I've done so far since when I used my original #okToProceed method it worked as intended.

I should mention that the technique I've adopted (and adapted) comes from the Smalltalk Daily at
http://www.cincomsmalltalk.com/casts/stDaily/2006/smalltalk_daily-10-4-06.html
rather than from the GUIDevGuide.pdf

[charles]

Gary:

In this scenario, the issue is that the appropriate callback to use is actually a notification callback i.e. with a notification callback you get the callback after "It" happened i.e. you get notified, which you want i.e. you want "it" to happen. In the case of the validation callback you basically get to "veto" or not the change i.e. the case of a validation on change. In other words the "change" only happens after you return "true".  In the case of using BufferedValueHolders that implies using the triggerChannel to apply or disallow the dirtiness.

So I took the liberty of just changing your spec to specify the callback on notification and it all seems to test out correctly , mind you I kept the same selector name , lazy me, and you ought to change it to correspond to what it is really about now. You'll see what I mean. I have attached the parcel and parcel source. BTW, you are now officially a package in my local StORE repository , for what that is worth

My next suggestion is to start using a repository if you are not already. SQLLite is lite , portable and it works, though it might be a Windows thing , not sure.

-Charles

[GaryD]

with a notification callback you get the callback after "It" happened

That's it - I should've spotted it!  I though the context might be something to do with the problem.
As good as the VW docs are, this is one area where I feel the docs could do with some embellishment, i.e. differentiating this sort of thing. The docs go into detail about what can be done and how, but not always why and the examples (as good as they are) don't always provide the why either.

It helps to have someone explain it so clearly. Thanks once again.

G

[Tags:]

Jump to: Please select a destination: ----------------------------- General Category ----------------------------- => General Discussion