I'm curious why #createComponents doesn't fail if you spell a view
wrong? It seems to quite happily continue even though you now have a presenter connected to nothing? Why would you want to do that? To me - it would seem better to throw an error (you could always catch it if thats what you intended) and then you can write a simple test that just tries to show your view (and not get any exceptions) to make sure its wired up correctly? Tim |
Tim,
> I'm curious why #createComponents doesn't fail if you spell a view > wrong? It seems to quite happily continue even though you now have a > presenter connected to nothing? > > Why would you want to do that? It is by design. The idea is to allow several different views to be connected to the same presenter framework. Often one might create an "all singing, all dancing" presenter view combination that provides a full and complete interface to the undferlying model. We wanted to allow stripped down, simplified UIs to be easily created by non-programmers using only the View Composer and an easiy way for them to do this would be simply by removing views. We actually used this method to distribute a simplified class browser view in earlier versions of Dolphin either for people wanted the simplicity or for those who had less screen real estate. > > To me - it would seem better to throw an error (you could always catch > it if thats what you intended) and then you can write a simple test > that just tries to show your view (and not get any exceptions) to make > sure its wired up correctly? I will admit, however, that throwing a Notification when a view doesn't connect correctly might be a better response. That way such situations would be automatically logged to the Transcript at development time. Still, it should be pretty easy to see if a view isn't connected correctly; just use the Visual Object Finder and click on the suspect view and you should see the presenter link is to the view itself. Best regards, -- Andy Bower Dolphin Support www.object-arts.com |
Andy,
> I will admit, however, that throwing a Notification when a view doesn't > connect correctly might be a better response. That way such situations > would be automatically logged to the Transcript at development time. > Still, it should be pretty easy to see if a view isn't connected > correctly; just use the Visual Object Finder and click on the suspect > view and you should see the presenter link is to the view itself. I have long wanted to see you make the notification behavior optional, off by default, given the long history in MVP. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Bill/Andy
>> I will admit, however, that throwing a Notification when a view >> doesn't connect correctly might be a better response. That way such >> situations would be automatically logged to the Transcript at >> development time. Still, it should be pretty easy to see if a view >> isn't connected correctly; just use the Visual Object Finder and >> click on the suspect view and you should see the presenter link is to >> the view itself. >> > I have long wanted to see you make the notification behavior optional, > off by default, given the long history in MVP. It feels like a policy option to me - i would like an Exception policy, others want a Silent policy and others want a logging policy. (I like fail fast, and prefer checks I can automoate - e.g. a good test is to close and open the window and make sure no exceptions occured). Still it can't be that hard to plug in such a policy can it? Tim |
Tim,
> It feels like a policy option to me - i would like an Exception policy, > others want a Silent policy and others want a logging policy. I agree as long as it is class-specific vs. image-wide; the latter would prevent the kinds of things that lead OA to make it fail silently. Have a good one, Bill -- Wilhelm K. Schwab, Ph.D. [hidden email] |
Free forum by Nabble | Edit this page |