I am against the UI process block RRS feed

  • Question

  • User-1305149166 posted
    In first look, it's so attractive, but after think about it for a while, I don't know what problems it has solved. According to its documentation, here is the selling point of the UI block. 1. Allow WinForm/WebForm use the same UI flow control. It's true, but I seldom have such a situation. You still have to issue a command like this: State.Goto("Success") What I did before is: Repsonse.Redirect(....) It's simplified a little, I have to say. The price is you have to maintain a big navigation graph. 2. Navigation Graph will abstract the navigation. I feel ODD about this. The navigation graph simply defined the navigation POINT. The actual action still has to be fired in your code. What I am trying to say is: It helps, but doesn't worth the complexity it adds to your application. If any body has implemented this successfully, and actually felt the benefit, please speak out. Thanks.
    Tuesday, August 19, 2003 5:08 PM

All replies

  • User-1303368272 posted
    I think it could be good with a lot of additional work. There are a lot of issues up front though. For example, often times it loses the state moniker. Another example, the built in controller transfers control to the 'current' page if you use the back button and refresh. It would be very easy to implement a navigation graph without all the complexity. I've been using it for mock-ups, but would be very hesitant to use it in a real web environment due to the un-friendliness.
    Tuesday, August 19, 2003 6:00 PM
  • User-1305149166 posted
    >> Another example, the built in controller transfers control to the 'current' page if you use the back button and refresh. You point out a much more serious problem. I think this flaw could neglect the whole purpose of the UIP block. The approach (use server side session to save state) is just not right unless it simply disable the back button. (This will cause another problem though, would be user accept the fact that they can not use back button any more?) Anyway, too much problem is the current implementation. But I believe there has to be a UIP block. Maybe this one is a very good start. Let's see what we can get in a lter version. A UIP block is really necessary as my APP's navigation is out of control now. :-) Also, hope they include the "Keep page state when it's coming back from another page" functionality. This kills me now. :-) Calvin
    Tuesday, August 19, 2003 6:34 PM
  • User-1303368272 posted
    Well, the UIP block as distributed has an even more annoying problem than back + refresh, which is if you hit back and then navigate, it will try to navigate in the context of the 'current' page. e.g. you have page 1, page 2, page 3, you go to page 1, click next, hit back, click next, it goes to page 3, or throws an error if it can't find a next. I solved this by passing the current view from the page to the controller. Apparently this occurs before the controller looks at the current state.
    Wednesday, August 20, 2003 9:39 AM
  • User736975731 posted
    The problem is that with a web app, the controller doesn't really fully control the navigation, so you will have to 'synchronize'. The point of 'action' and 'navigation' I have also observed. The actions (which could even be interpreted in the UML sense of action) are the parts of a business process (with a graph between them). The fact that the controller now calls all actions plus navigation makes no sense to me. The navigation graph is also not fixed. The possible paths are determined by the view (depending upon what action is called next by the view). Usually a business process has a small set of next possible actions, but there is nothing to enforce this except the implementation of the view. All you have accomplished is that your navigation+business logic are now together in a controller. You still didn't seperate them. I think you could by modelling your business processes seperately.
    Friday, August 22, 2003 10:28 AM
  • User-1509016937 posted
    Hi, I sweep around google for information about the UI process block with webforms authentication. Have anyone use webforms authentication with the UI process block??? If not, how did you did the authentication process of your application???? And if i have some webforms that can be open from a authenticated user and from an unauthenticated user??? How can i do that????? Thx in advance Paulo Correia PS Sorry about my english
    Wednesday, October 15, 2003 11:09 AM
  • User1430000402 posted
    This UIP really sucks. That's all i can say... I'm using it now and my WebApp is getting more and more complex + out of control although it's now just a fairly simple WebApp. I'm back to traditional Response.Redirect().
    Sunday, November 9, 2003 9:05 PM