pass object from model to view in event

[mp]

amazing, i think this is working!!!

this is the output from some debug.print lines to trace action:

view creates presenter
presenter creates model
presenter asks model to subscribe to presenter's events
model subscribes to presenter events
presenter subscribes to models GotCriteriaDictionary event
presenter subscribes to view's events
view subscribe to presenter's GotCriteriaDictionary event
view raises event GetCriteriaDictionary
presenter catch event from view GetCriteriaDictionary
presenter raise event to model GetCriteriaDictionary
model catches event from presenter GetCriteriaDictionary
model gets data into sortedDictionary to pass back upstream
model raise event GotCriteriaDictionary and pass back CriteriaDictionary in
eventargs object
presenter catches event from model and raises event to view
view catches event from presenter and gets dictionary from event arg
view inserts dictionary into listview

does this look approximately right?
it appears to work...amazingly enough...
thanks to Peter and Jeff's collective patience

i wasn't sure about the last item
view inserts dictionary into listview

is that too much responsibility inside the view?
should presenter be filling the listview instead?
ie view exposes listview property which presenter fills?

thanks
mark

 

[mp]

apparently my enthusiasm was premature.
how do you get that damned cork back into the champagne bottle?

. It seems like there may be an over-reliance on events as a way of
object interaction.

i've gotten so caught up in trying to learn *how* to raise events
I guess i misunderstood what I was reading/hearing about *why*
I thought that was what i was being suggested to do, by the mvp info and
other previous 'conversations' like the push / pull analogy.


It's possible that it makes sense for the view to

raise an event saying that it needs data, but it seems odd to me that the
model would have to subscribe to such an event, rather than the presenter
simply retrieving the necessary data from the model.

i thought the presenter *was* retrieving the necessary data from the model,
by raising the event to which the model responded.
It would have been a heck of a lot easier to just read a property on the
model,
but I guess i misunderstood, thinking that was too much coupling,
and that events were somehow separating the players more???


And the

event from the view makes sense to me only if the need for data comes from
some user interaction.

in the future there will be some buttons requesting various actions/data
i've been trying to learn *how* to pass events back and forth for that.
in this first case, the event is called in the OnLoad sub.


Otherwise, at the very least the presenter

could just be initializing the view imperatively, and it's not
unreasonable to have a design where the view retrieves the data directly
via the model interface, or some more abstract wrapper around the model
interface.

again, i guess i'm misunderstanding a lot about the whole background

Having the model subscribe to an event that is raised when the view wants
data seems awkward at best, and at worst ties the model to the view
implementation in undesirable ways. The model data structure should be
completely agnostic regarding how the view is implemented, and having it
subscribe to an event in the presenter that simply mirrors a similar event
in the view doesn't seem right to me.

like i said, obviously i'm just being dumb as a box of rocks here.
I thought that's what "everyone" has been "suggesting"
for the view to be "dumb" - which i took to mean - it only raised events...
like when a button is pushed, or when it loads and needs to fill some
control with data
to request information, but not know where the info lived or how to get to
it>?????

so I have a form.
the form has a listview.
I want to put some items in the listview
the items are at the moment living in a spreadsheet on disk.

how "should" i be doing that?
(recognizing that there are different ways, but in your opinion, how would
you handle that?)




[...]

Pete

thanks again, and sorry for being so dense.,
mark

 

[mp]

amazing, i think this is working!!![]>>

Of course you can roll your own view and presenter, because that's the
beauty of MVP.

The control is with the presenter and not the view. The IView is just the
Interface between the UI and the Presenter. The only events you should be
raising are events on the IView that points to a method on the Presenter.

The Presenter should get/set any controls from the IView work with them
and getting/passing them back on the Interface, or the presenter should be
getting/setting an object if you are using an object or object graph.

It looks like you have lost focus, and you are raising events like
rabbits.



Did that tutorial show you any of what you have gone off and done?

yep, it's what i started with
the view creates the presenter and raises an event to the presenter
that's what i'm doing
then the presenter called a method on the model
that's where i went wrong...using an event instead

when the tutorial stopped at "fake getting product"
i went on and tried to do what my app needed to do
not in the right way evidently, but...

You just should have kept it simple. []
I say you need to go back to square one with the tutorial, and what you
are doing, keep it simple -- follow the tutorial.

i'll go back and review again,

so it's usually just the view that communicate via events?
the presenter just calls methods on the model and sets properties on the
view?

thanks
mark

 

[mp]

[...]

It's kind of like your brain.

no, no, as we've seen it's nothing like *my* brain


[...]

However, you do it, the important thing is that the controller should not
have any need to know about the ListView type, nor even that a ListView
object is being used to present the data to the user.

Hope that helps!
Pete

thank you very much
i'm going to read and re-read and re-read that
mark

 

[mp]

The UI/form communicates with the Presenter by raising an event on the
IView, the IView event will access a method on the Presenter, and the
Presenter will access a method on the Model/BLL.

A control, object, object graph or primitive data type will be represented
on the IView, which is shared between the UI and Presenter to pass things
in either direction using get/set.

That's it keep it simple.

thanks Steel,
that's for sure a problem for me, learning to keep it simple

mark