On 6/9/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > Yes but what about Netscape 4? .... only kidding :) > > The effect is neat however you do have to implement the no-cache and you > have to turn off auto-validation and then rely on the browser, so I > wonder whether it is really neat enough to be worth it. I do prefer > things to be as simple as possible, if not for robustness then just to > make it easier for struts-newbies to take on board. > > Adam
I guess I am doing bad advertising for my product. (With the voice of car salesman) let's go over figures once again. The point is, that a dialog written with DialogAction will never work worse, than standard cached page. In the worst case scenario, when browser does not honor cache headers, and does add everything to page history, you will get the same behavior as a standard application. That is, when you click Back, you will see a stale page, cached by browser. And if you entered invalid value several times, then you might need to click Back as many times as you entered invalid value, to return from this dialog. But! This behavior is _no worse than standard caching, non-redirecting application_. DialogAction does not make your code or UI less robust. Also, according to statistics, Opera which is the mental case here, is used only by 2% of users. On the other hand, if you use any version of Netscape starting from 4.x, (yes, Netscape 4 works great), Mozilla/Firefox or Internet Explorer (I could not find IE4 for testing), then your users get immediate benefits in user experience and in overall application feel. And, you cannot create what I call a "web control" without redirection and two-phase I/O processing. Think of DialogAction, especially when you creating a control out of it, as of very simplified portlet. But portlets has a specific API, like doDispatch() or doView(). DialogAction does not have API, simple reload works as doView(). It is a actually a big thing, and ability to create a web control allows to have a simple portal without portlet container. You just drop an URL to master page, and you do not care about anything else. Whenever master page is reloaded, the control is reloaded too, and it displays content, reflecting current control state. About simplicity. Funny that you mentioned this, because creating a dialog using DialogAction is simple, just use your form bean fields, or use a nested business object within a form bean with session scope, and you get event model, storage for your dialog data, and message handling. It might be not a big deal for you, if you do not play with browser buttons like a kid. If you do not feel like clicking Refresh just because of fun of it, or clicking Back just to check what happened to previous page, if you are not annoyed by POSTDATA messages, then you might not appreciate what DialogAction does. But for me POSTDATA dialogs are infuriating, I simply hate them. And, if the above did not convince you: Ruby On Rails adopted the same two-phase approach to I/O forms. JSF provides the same features, if you look at JSF samples, all backing beans are defined with session scope, you just need to put <redirect> tag in config file. Spring MVC has similar features with RedirectView class. The DialogAction may not be perfect (yet), and may need some improvements, but it works and it is pretty stable. I will be glad hearing about possible updates and changes. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
