View resource confusion in D6

Hi,

I am missing something with views in D6.

I just created a Main Shell Application under Shell.

Then right click, View, new, (save) beautifully created the
resource_Default_view class method. It appears also in the view
composer under Shells as MyMainShellApplication.Default view.

But I cannot see the view as a subclass of any classes under View.

Because I would like to create some methods in the view...

How can I get that it appears as a subclass of ShellView?

(Or shall I apply the old D5 trick: create a MyMainShellView view under
the ShellView, and evaluate once:
MyMainShellApplication addView: MyMainShellView view asResource:
'Default View')?

But then what happens with the resource_Default_view class method?

Or I am on a perfectly wrong track? What is the correct approach?

Thank you,
Janos

Well,

the old trick solved everything:
creating MyMainShellView under Shellview and evaluating
MyMainShellApplication addView: MyMainShellView asResource: 'Default
view'
has even replaced the resource_Default_view class method by referring
to the MyMainShellView.

But it is a little bit mystical even now:
You have 2 ways:
- Starting to create the view (either from the belonging Presenter
class or by the View Composer), and at saving it will ask you for the
belonging presenter. This way creates "only" the resource_Default_view
class method.

- Create your view class explicitely as a subclass of the necessary
View class, and then execute (once) the #addview:asResource: This way
you have an explicit view subclass AND the resource_Default_view class
method in the presenter.

When do you need an explicit view? (above the need of adding specific
methods)

and when do you not need it? (i.e. the simple resource_Default_view
class method in the presenter is enough)

It seems it has to do something with (the difference between the)
resource and methods, but... can somebody explain?

Thank you,
Janos

Janos,

> When do you need an explicit view? (above the need of adding specific
> methods)
>
> and when do you not need it? (i.e. the simple resource_Default_view
> class method in the presenter is enough)
>
> It seems it has to do something with (the difference between the)
> resource and methods, but... can somebody explain?

I've tried a couple of times to compose a reply to this, but I keep getting
stuck because I'm not sure what you are asking.  Are you asking about what
"view resources" (which are /not/ classes) are, and how they are used by the VC
and in the rest of the Dolphin MVP framework ?  Or about how to decide whether
to implement some new feature by creating a new View class rather than a new
Presenter class ?  Or both ?  Or perhaps something else ?

    -- chris

Chris,

well, it was not very clear for me  too.

Basically my question is:

OK. I attach a resource to my Presenter. During execution it will
behave like a view. But the attached resource does not appear as a real
subclass of a View.

But I can create a "real" View in the class hierarchy, and then attach
it to a presenter. In that moment it will become also a resource.

Now I think I know what to ask: What can do with a "real" view, what I
cannot with one, which is "only" as a resource attached to the
presenter?

or:

Does the act of attaching the "resource view" to a real presenter
converts it to a real view when we start the presenter (obviously it
does)?
But then again: why do I need "real" views at all if I can do anything
with this view, ahich does not exist in the class hierarchy?

Sorry for the dumb questions, I am just lost in the concepts: when is a
view a real view, and when is it not...

Thanks,
Janso

Janos,

A resource is just an instance of a view that has been saved down to an
array of bytes. This array of bytes is then held in a method (usually
on the class side of a presenter) and the view can be reconstituted
from this array when necessary. Once the view has been rebuilt from the
array it is just as much a "real" view as any other. Perhaps a non-view
based example might help:

"Create an object, in this case a Color"
x := Color red: 255 green: 0 blue: 0. "Display it"

"Save the object down as a resource array"
resource := x literalStoreArray. "Display it"

"Rebuild the object from the resource"
y := Object fromLiteralStoreArray: resource. "Display it"

"See it's a real Color"
y class "Display it"

"Equivalent to the original but not identical to it"
y=x. "Display it"
y==x. "Display it"

Now let's look at how this works with views and why we use resources
rather than always create a new View subclass to represent a view that
can be attached to a presenter:

"Create a ShellView"
x := ShellView new show. "Display it"

"Parameterize it"
x backcolor: Color red.
x extent: 350@200.
x caption: 'My Shell'.

"Save the shell down as a resource array"
resource := x literalStoreArray. "Display it"

"Rebuild the object from the resource.
Note that this time we must provide a parent view as a context"
y := (Object fromLiteralStoreArray: resource context: View desktop)
show. "Display it".

"See it's a real ShellView, parameterized as before"
y class "Display it"

You can see that the key here is that we have been able to a
parameterise an instance of a view and save this down so that it can
later be re-created exactly.

It's certainly true that in MVP we could have chosen to save down all
views in their own separate classes but, frankly, this never seemed
quite right to us since a new class should really represent a new
behaviour rather than simply a parameterisation of existing behaviour.

This way, if you want to create a number of reusable view resources
(let's say they are TextEdits that simply have different background
colours: red, yellow and blue), then you can just save them down as
three separate TextPresenter resource methods (#resource_redtext,
#resource_yellowtext and #resource_blueetext) rather than having three
new subclasses of TextEdit (RedTextEdit, YellowTextEdit, BlueTextEdit),

I hope this goes some way towards clarifying the situation.

Best regards,

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> I hope this goes some way towards clarifying the situation.

yes, absolutely.

Many thanks for the excellent explanation,
Janos