Since I originally started this thread, it is time to update my comments ;-)
I solved the original load problem by having my turbine JSPAction (used by all of my StrutSpeed portlets) work in this way: in the perform method, it checks for a key naming the URI of a Struts action to use. It checks the request first (normal situation after a form is submitted, a link is followed, etc) and if it is not there it checks the portlet configuration for the parameter of the same name (initial load situation). if key is present, control is then forwarded to Struts as I described in the original mesage. I18n works as in normal Struts as long as I don't use depricated methods to get to MessageResources. I tried to get localized strings from JSP template (using bean:message) and from the Action (using getResources(request) ) and it worked in both cases. Validation via ActionErrors validate() method works as well. And yes, "truly awful approach" is the way to describe this ;-) -----Original Message----- From: Richard Berger [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 27, 2004 10:56 AM To: Jetspeed Users List; benja Subject: RE: using Struts for portlet development By strange coincidence, I just started integrating a Struts prototype with my current Jetspeed prototype, so this topic is indeed interesting. I was able to have some initial success with a hybrid of the Turbine Actions and the Struts Actions - resolving at least one of the problems noted below. Some of my portlets present themselves as JSP portlets, but "pre-loaded" with data from the server (e.g. a drop down list of stuff). I built those portlets as JSP portlets using "Turbine" actions (e.g. <parameter name="action"....> and in the action class I collect information and drop it into request (e.g. rundata.getRequest().setAttribute("foo", o)). Then in my JSP page, I can reference this information and build the drop down list. However, that JSP page is a "vanilla Struts" page - e.g. it has an <html:form> tag which has an action like "foo.do" - e.g. it is the same JSP I was using in my Struts prototype. Then, through the standard struts-config.xml, foo.do is mapped to a Struts action class - and the submit button on that JSP form calls that action - just as it always did. The only change I made to the Struts action class was to set the forward to "/index.jsp". So far (after 1/2 of work) this is looking reasonably well - and it solves the problem of the initial portlet loading correctly (the Struts stuff doesn't come in until the user pushes the button in the portlet, the initial rendering of the portlet is done through Turbine, so it is fine). Disclaimers/Weak Points: * I haven't tested validation yet (I was using the validation framework) * The localization I had done in Struts does not yet work in Jetspeed * This could be a truly awful approach (we product manager types aren't known for creating the worlds best software :) :) ) Enjoy, RB Twenty Years | One Mission | Accelerating Business Processes Richard Berger Action Technologies, Inc. VP, Product Management 510.748.1017 (Office) 510.769.0596 (Fax) www.actiontech.com NOTE: The opinions expressed herein are those of the writer and not necessarily those of Action Technologies, Inc. or its employees or its affiliates. -----Original Message----- From: benja [mailto:[EMAIL PROTECTED] Sent: Monday, January 26, 2004 9:33 AM To: Jetspeed Users List Subject: Re: using Struts for portlet development We are using a different approach for this. Our application is composed of a set of modules. Each module is developed as a Struts application without taking in account that finally the module will be displayed inside a portlet. The main benefit of this is that developers don't require more skills than usually (Struts, JSPs, ..). Jetspeed is not in the development environment. After developing the module, we integrate all the modules in the portal. Internal module actions (e.g. click on a button inside the panel) are handled by Struts. The request is processed as usually and the unique difference is in the forward. After processing the request, instead displaying the next page, the control is forwarded to Jetspeed. It will display the complete portal page. Actions over the portal (e.g. menu) or over the portlet bar are handled by Jetspeed. Struts is not aware of these. Integration basically means move resources (folder with jsp's. struts config, ...) from development to integration. We have standardized a lot and this is done automatically. Different behavior in the development env. and portal env. are handled by different implementations of common classes (e.g. the forward class performs a classic forward in development but a forward to the portal in integration). To do this, we did the following: - use session to store info about the current page displayed in each portlet - create the forward that sets this info (write in session the next page to display) before forwarding to the portal. - modify HTML Portlet to use this info The weak points are: - collaboration between portlets. One action in a portlet modifies the rest of portlets. The model is more complex due to modules are not isolated. That's all Benja ----- Original Message ----- From: "Mikhail Garber" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, January 26, 2004 3:55 PM Subject: using Struts for portlet development > Hi all > We use Jetspeed as the foundation of our portal. Plain vanilla 1.4. > We decided to use Struts with JSPs for the development of new portlets. > The basic strategy goes like that: > All portlets are based on JSP template and use the same Turbine Action > class. > I extended Struts form tag and Jetspeed portletlink tag to supply additonal > parameter - the URI of the Struts action to run. > The Turbine Action (in the perform method) stores the original "portal-like" > URI in the request object and does RequestDispatcher forward to > whatever was > specified as Struts URI. > The Struts action does whatever it supposed to do and at the end > extracts the original Turbine-style URI from the request and does doForward to it. > So far this seems to work and gives us the advantage of using Struts > while still doing work in the Portal. > does anyone else use the same or similar technique? Do you see any problems > with it? > So far I identitifed a few: for example, I do not know how to get the Struts > action to run during the very first loading of the portlet. > Also the Struts validation (either via validate() or a Validator) does > not work for some reason. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
