Advice on views that don't need a presenter.

I am fiddling around with Dolphin again, after a rather long
break. Dolphin is so natural, what an environment to work
in!

In the process of porting a win32 C application to Dolphin, I
had to create some views that did custom drawing on a canvas, because
I didn't know how to "get" to the view object without having a
presenter, I just added an empty Presenter derived class to the Views
and it worked fine.

Now I am just curious to know how/if it is possible to forego creating
a presenter for the view?



--

Vennlig hilsen

Syver Enstad

Syver Enstad <[hidden email]> wrote in message
news:[hidden email]...
You can access a named view without a presenter from the primary presenter
via:

self view viewNamed: 'theNameOfTheView'.

I used to do that a lot, now I try to avoid it and use presenters instead.
I am not sure if it is a good idea.  Perhaps a proper Dolphin guru can
comment further.

I sometimes just use an instance of Presenter if I do not have a specific
presenter for a view.  Dolphin does this in a few places, so perhaps it is
not too bad an approach.

Chris

"Christopher J. Demers" <[hidden email]> writes:

> You can access a named view without a presenter from the primary
> presenter
>
> via:
>
> self view viewNamed: 'theNameOfTheView'.

Sorry if I am asking something really obvious, but how do you get the
view into the shell view in the first place. I can't use the resource
toolbox if I don't register the view with a presenter.


--

Vennlig hilsen

Syver Enstad

Syver Enstad <[hidden email]> wrote in message
news:[hidden email]...
>
> Sorry if I am asking something really obvious, but how do you get the
> view into the shell view in the first place. I can't use the resource
> toolbox if I don't register the view with a presenter.

I think I misunderstood your original question.  I think I understand now.
I would advise that the view be registered to some class, even if it may not
be needed to support the view.  While I suspect that some low-level tricks
could be used to insert a view programmatically in the view composer that
seems to be really working against the intended way of doing things in
Dolphin.  It is not worth it unless there is an advantage to be gained in
doing so.

It seems that a view can actually be registered on its own class.  I am not
sure what the implications of this are, but it might be of use to you.  You
can do this by going to your view class and using the Views\New... command
on the class context menu in the browser.  It looks like it registers the
view on the class then opens an editor on it.  I am not sure if this is a
good idea, but Dolphin seems to support it, and it will let you use the
resource toolbox to insert that view.  Perhaps others can comment further.

Chris

"Christopher J. Demers" <[hidden email]> wrote in
message news:ap7alg$sdoge$[hidden email]...
> Syver Enstad <[hidden email]> wrote in message
> news:[hidden email]...
> >
> > Sorry if I am asking something really obvious, but how do you get the
> > view into the shell view in the first place. I can't use the resource
> > toolbox if I don't register the view with a presenter.
>
> I think I misunderstood your original question.  I think I understand now.
> I would advise that the view be registered to some class, even if it may
not
> be needed to support the view.  While I suspect that some low-level tricks
> could be used to insert a view programmatically in the view composer that
> seems to be really working against the intended way of doing things in
> Dolphin.  It is not worth it unless there is an advantage to be gained in
> doing so.
>
> It seems that a view can actually be registered on its own class.  I am
not
> sure what the implications of this are, but it might be of use to you.
You
> can do this by going to your view class and using the Views\New... command
> on the class context menu in the browser.  It looks like it registers the
> view on the class then opens an editor on it.  I am not sure if this is a
> good idea, but Dolphin seems to support it, and it will let you use the
> resource toolbox to insert that view.  Perhaps others can comment further.
>

There is no problem with doing that. Some views such as PushButtons do not
have an associated presenter. Other options are to add the view as a loose
resource of the Presenter class, or (when composing a view) you can add a
plain vanilla view as a placeholder for your view and then mutate it into
the required class.

Regards

Blair

"Blair McGlashan" <[hidden email]> writes:

> "Christopher J. Demers" <[hidden email]> wrote
> in message news:ap7alg$sdoge$[hidden email]...

<about registering a view on its own class>
>> I am not sure if this is a good idea, but Dolphin seems to support
>> it, and it will let you use the resource toolbox to insert that
>> view.  Perhaps others can comment further.


> There is no problem with doing that. Some views such as PushButtons
> do not have an associated presenter. Other options are to add the
> view as a loose resource of the Presenter class, or (when composing
> a view) you can add a plain vanilla view as a placeholder for your
> view and then mutate it into
> the required class.

Trying to make an overview:

You can register a View class that doesn't need a custom presenter
with the base Presenter class that comes with the image. This let's
you use the MVP framework with the view so that the model is properly
connected to the View (I am guessing here based on the fact that my
View didn't draw it's model when I didn't connect the model to the
view by using the presenter).

If your view doesn't use a model and doesn't need a presenter for
anything else either, you can register the View resource with the View
class itself.

I think for the time being I'll stick with registering my view with my
empty Presenter subclass, this seems neater as I get a proper name
into the Resource toolbox instead of just Presenter.


Sorry Blair, I did a reply instead of a followup and sent this post to
you by mail. Disregard the mail

--

Vennlig hilsen

Syver Enstad

"Syver Enstad" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> Trying to make an overview:
>
> You can register a View class that doesn't need a custom presenter
> with the base Presenter class that comes with the image. This let's
> you use the MVP framework with the view so that the model is properly
> connected to the View (I am guessing here based on the fact that my
> View didn't draw it's model when I didn't connect the model to the
> view by using the presenter).

Yes. It is possible to connect up a presenterless view that requires a
model, but it has to be done explicitly, e.g. in #onViewOpened:. Also event
registration must be "delayed" until then, rather than being done with all
the other event registration that normally takes place in
#createSchematicWiring. It's certainly easier to work with the MVP framework
and add a Presenter.

>
> If your view doesn't use a model and doesn't need a presenter for
> anything else either, you can register the View resource with the View
> class itself.

That is probably a good rule of thumb.

>
> I think for the time being I'll stick with registering my view with my
> empty Presenter subclass, this seems neater as I get a proper name
> into the Resource toolbox instead of just Presenter.

True.

Regards

Blair

Blair,

> It's certainly easier to work with the MVP framework
> and add a Presenter.

Seconded.  Would it make sense to have a pluggable graphics presenter
(anything that takes a block to do its drawing) for simple stuff?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]