On 7/5/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > So are you saying you've implemented the Portlet specification, or some > subset of it? > > If not, I'm not sure I see the point. > > If so, why would I choose this over an actual portlet implementation > (which can be built on top of Struts, which is exactly what we use at > work in the form of IBM's portal product). > > I'm not asking this in a confrontational way, it's a legitimate > question... convince me! :) > > Frank
* No, I am not implementing Portlet spec or subset of it. * I am not saying that my stuff is better than portlets. * Originally, the whole thing was not about portlets and controls. Have you read my answer to Don? Please do, it should explain a lot. Or my English is really that bad? Or it is not the language, it is my ability to explain? I will try once again. The original reason why I started this project, was to implement Post-redirect-Get pattern in Struts. If this pattern does not ring a bell, this is the idea: to split one "submit data with POST, return with page" request into two separate requests: * submit data with POST, update domain model, generate error messages, then redirect to result page; * load result page with GET. Why? To avoid implicit resubmits and POSTDATA messages. If you do not care for Refresh, Back and Forward buttons then this reasoning will not convince you. But for me this is important. I hate POSTDATA messages, I hate to answer "Yes" to "Do you want to resend POSTDATA?" messages, I hate to log in, then to click Back button and to see the same login form again. Is the above clear? I'm not asking this in a confrontational way, it's a legitimate question. :) By the way, this pattern is official in Ruby on Rails, is official in Wicket, can be easily configured in JSF, so I am not creating something controversial of ground-breaking. But Struts does not have it. Struts does not have _any_ UI support besides automatic form bean population and dispatching of submit buttons to DispatchAction. What I want is to add better support for stateful UI objects to Struts. Please, try this demo once again, I know you tried, but try once more: http://www.superinterface.com/strutsdialog/logincomponent.html Notice, that two pages, login page and logout page are served from the same location. This is important. You cannot log in and then go back and see login page. Also, you can refresh any page after you submitted an HTML form, and you won't get POSTDATA message. Also, despite how may login attempts you made, it takes only _one_ click on Back button to leave login component. This is what Struts Dialogs does. It also helps to manage error messages. After I implemented this, I realized that I could easily embed these components into a JSP page with little efforts. Why? Because of two-phase processing (aka redirect-after-post) that I implemented before. I am not saying that I implemented portlet API or created a framework competing with portlets. I am saying, that often all that needed, is to visually embed a component into a page. Do you really need portlet container and portlet API to do this simple thing? No, you don't. All you need is master JSP page and <jsp:include> directive to include a JSP component. Why <jsp:include> and not, for example, SSI? Because with <jsp:include> I can include dynamic component, and I can share data using standard servlet/JSP data structures like session. Why two-phase components make a difference? Because user data is submitted directly to the component instead of being submitted to the portal container or master JSP page. This allows to get rid of portlet container altogether _if all you need is simple inclusion of a component_. Please, check out the second demo with the same login component, but this one is embedded in JSP page: http://www.superinterface.com/strutsdialog/logincontrol.html The only changes are mappings in struts-config.xml, the Java code is _the same_ as in previous example. You can log in, and the master page is redrawn, and control shows current user logged-in state. Also, the prices on the servers are $50 lower, but this is just a sample page ;-) Wrapping up, the goals: * To provide better user experience and easier development of stateful components like, for example, login dialogs. * To develop JSP controls, which do not need any other container besides parent JSP page. Is it clearer, or I was not able to explain what my stuff does again ;-) ? No, really, if I could not explain it this time, I will try again and again, but remember that I know only this many English words :) This is what I can do. Do you have login page in your app? I can create a login control based on my sample, and you can just plug in it into your app. Actually, this is the direction I want to move. To create JSP controls. Try to search for "asp (component or control)" using Google. It would ask you back, 'Did you mean: "asp (component or control) " ' This is sad, but JSP has no notion of visual component or control. Ok, so now portlet spec and JSF give us the components. But ASP had them long ago, and ASP is no better than JSP. So, why not to create components using pure JSP? I showed that this is possible. If I could not explain it again, please reply, so I could think on better wording ;-) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
