VC suggestion

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

VC suggestion

Chris Uppal-3
I think it would be a useful extension to the existing VC if we could drag View
subclasses from the CHB into the composition pane(s), just as we can drag
existing View Resources from the toolbox.  That would create a default instance
of the View class (using #new) and add it to the composition.

I had a quick hack at an implementation, and though it's probably not done
right (I don't understand how the VC works) it was quite easy and /seems/ to
work, more-or-less.

What do people think ?

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

Chris Uppal-3
I wrote:

> What do people think ?

Anybody ?

(My mistake of course: I know perfectly well that asking for feedback is almost
bound to ensure you don't get any ;-)

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

Bruno Brasesco
Chris Uppal escribió:
> I wrote:
>
>
>>What do people think ?

Well until now i never need this behavior for VC.

But:
In which cases is useful to you ?

Regards Bruno


Reply | Threaded
Open this post in threaded view
|

useful i think

Howard Oh
In reply to this post by Chris Uppal-3
Chris,

I think i can understand why you are wanting this.
Resources id are "Presenter name + name string" which give very weak
hint what view is actually used. Situation like knowing what view to
add into VC's content, but not knowing which reasource id has it. Your
idea can help people speed up their GUI designs, still remains that
presenter class name is still required to be written on Presenter side
of MVP. It semms like a delay for the problem not a solution. "I will
find out the name of its presenter later." strategy.  It can help
people focus on their view design rather than running up and down to
find the right presenter.


Drag & Drop is always so hard to me, since i loose those icons while
delivering it to a target pane. I think of a way to avoid drag&drop if
possible like...

ClassBuilder moveClass: MyObject toSuperclass: Model.

For that reason, I would just evaluate following expression in the
workspace of VC.

self addSubView: TextEdit new name: 'your name'


Nice to a know that I can give an answer to Chris. It rarely happens,
although this is not an answer for question but a simple feedback.

Brest Regards,
Howard


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

tgkuo
In reply to this post by Chris Uppal-3
On Wed, 7 Jun 2006 14:30:01 +0100, "Chris Uppal"
<[hidden email]> wrote:

>I wrote:
>
>> What do people think ?
>
>Anybody ?
>
I cann't get the point clearly, but in the official site,
http://www.object-arts.com/content/blog/2005Dec14-BSM.html,  Blair
wrote on the view composer issue: "Rather than working on a static,
unconnected, representation of the view as now, you could edit the
view of a live MVP triad, and so eliminate the edit/run cycle."

  It means that Blair is busy working on more enhancement on VC to
make it as dynamic as possible, and IMO, even to the point that
Dolphin will host Morph's prototype-based view-centered environement
someday by the way.

   It's a fascinating idea and solve many issues about Smalltalk's
MVP, which might include yours, I think, maybe this is not to the
point in this post.

Best regards,

Tk Kuo


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

Chris Uppal-3
In reply to this post by Chris Uppal-3
Thanks for the responses, everyone.


Bruno,

> In which cases is useful to you ?

Well, one big use for it is to create the /first/ template instance of a new
View class.  Currently, there is no IDE-level operation for doing that, and
it's a hole in the system.

More importantly, I think it would help underline what the VC does by showing
how draging a view-resource from the Toolbox is just creating an new instance
of a view class, ready for further configuration.

Perhaps equally important, there doesn't seem to be any reason /not/ to be able
to do this.  So you might say that it's an arbitrary restiction in the system.

Lastly, view resources have a tendency to get out of date with time.  Resources
that originally were in the default state for their View class are not updated
when their class is changed to have a new (and presumably better) default.  I
don't know if you develop new View classes much, but I have found that whilst
doing so, it's a bit of a pain always having to refresh the view resources
before testing.  I would like to be able to work more directly, and on a
guaranteed "clean" instance.

BTW, if anyone from OA's reading this (and has any interest in the idea at all)
then I think a useful extension would be a parallel with the existing
ReferenceView, which took a View class name instead of a view resource name.
They would be created interactively by alt-dragging a View subclass into a view
resource.


Howard,

> For that reason, I would just evaluate following expression in the
> workspace of VC.
> self addSubView: TextEdit new name: 'your name'

That's a tip worth remembering.  Thanks.

    -- chris


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

Blair McGlashan-4
"Chris Uppal" <[hidden email]> wrote in message
news:448d4f30$0$663$[hidden email]...

> ....
> BTW, if anyone from OA's reading this (and has any interest in the idea at
> all)
> then I think a useful extension would be a parallel with the existing
> ReferenceView, which took a View class name instead of a view resource
> name.
> They would be created interactively by alt-dragging a View subclass into a
> view
> resource.
> ...

The idea of being able to drag a view class onto the VC design surface in
general (which I think you suggested before) seems perfectly natural, so
I've added it as an enhancement request. A ReferenceView with delayed
instantiation of the view instance again seems a natural extension of that
general idea. Not sure what the level of change would be, however, so these
may not be appropriate for minor release enhancements.

Regards

Blair


Reply | Threaded
Open this post in threaded view
|

Re: VC suggestion

Chris Uppal-3
Blair,

> The idea of being able to drag a view class onto the VC design surface in
> general (which I think you suggested before) seems perfectly natural, so
> I've added it as an enhancement request. A ReferenceView with delayed
> instantiation of the view instance again seems a natural extension of that
> general idea. Not sure what the level of change would be, however, so
> these may not be appropriate for minor release enhancements.

Fair enough, and thanks.

BTW, since we are talking about possible enhancements in later versions, may I
revive another suggestion for ReferenceViews.  I have several times thought it
would be handy if they had an #initialization aspect taking a <monadicValuable>
or nil.  That would be evaluated after the view had been created, passing the
view as parameter.  It would allow us to make small modifications to a view
imported by reference without loosing the considerable virtues of reference
views, or having to write view-specific code into our Presenters'
#onViewOpened.  Not something for a dot-dot release, though, even if you do
like the idea.

    -- chris