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 |
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 |
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 |
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 |
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 |
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 |
"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 |
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 |
Free forum by Nabble | Edit this page |