struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cedric Dumoulin <cedric.dumou...@lifl.fr>
Subject Re: TilesRequestProcessor (WAS: Re: How do I navigate from one subApp to another in Struts1.1?)
Date Mon, 22 Jul 2002 09:14:21 GMT

  Hello,

  In the latest TilesRequestProcessor the way URI are processed have 
change. Tiles now intercept URI before they are changed by Struts, and 
calls doInclude() to do the dispatch. So, you can overload this method 
to do your own URI resolution.

  I haven't change tags yet. I consider adding an overloadable method 
for the dispatching when I will modify them.
  There is no others places in Tiles where request dispatching occur.

       Cedric

 

Struts Newsgroup (@Basebeans.com) wrote:

>Subject: Re: TilesRequestProcessor (WAS: Re: How do I navigate from one subApp to another
in Struts1.1?)
>From: "Kevin Henrikson" <kevin.henrikson@openwave.com>
> ===
>Thanks for the reply Cedric.
>
>So basically what we've tried is to subclass TilesRequestProcessor
>so we ignore tiles definitions and apply our path resolution logic to URI's
>then call super.doInclude() or super.doForward().  Where we get stuck is
>when we use a tiles definition in the struts-config.xml in an <action ..
>forward...>
>for instance we aren't able to apply our path resolution logic to the URI
>after
>tiles resolves the definition but before it is the request is dispatched.
>Would it
>be possible to apply a hook(overridable method) by refactoring the last part
>of
>TilesRequestProcessr.doForward()?  Something like:
>
>protected void doDispatch(ServletContext ctx,
>                                          HttpServletRequest request,
>                                          HttpServletResponse response,
>                                          String uri
>                                          boolean doInclude)
>{
>      // Do dispatching : search dispatcher, then dispatch
>	      RequestDispatcher rd = ctx.getRequestDispatcher(uri);
>      if (rd == null)
>      { // error
>      response.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>                               getInternal().getMessage
>                               ("requestDispatcher", uri));
>      return;
>      } // end if
>
>    // Unwrap the multipart request, if there is one.
>    if (request instanceof MultipartRequestWrapper) {
>        request = ((MultipartRequestWrapper) request).getRequest();
>    }
>
>      // If request comes from a previous Tile, do an include.
>      // This allows to insert an action in a Tile.
>      if( doInclude )
>        rd.include(request, response);
>      else
>        rd.forward(request, response);   // original behavior
>}
>
>This way subclasses could have a chance to modify the URI
>or do some custom request/response handling.
>    As for the InsertTag it looks like in InsertHandler.doEndTag the call to
>pageContext.include(page) is the only other place request dispatching
>happens.
>If a method was added here to again allow subclasses to override this call
>and possible
>do custom URI resolutions maybe a doInclude(String page) that calls
>pageContext.include(page).  Then I guess we'd also need to subclass the
>GetTag since
>it extends the InsertTag.
>    Does this seem plausible?  Are there other places in tiles that do
>request dispatching?
> Any problems with this approach?
>
>-kevin
>
>"Cedric Dumoulin" <cedric.dumoulin@lifl.fr> wrote in message
>news:mailman.1026987420.21861.struts@basebeans.com...
>  
>
>>  The hooks you use (doForward and doInclude methods) have been
>>introduce to let Tiles catch the calls to RequestDispatcher() ;-).
>>  It is true that actually Tiles don't provide similar hooks. I am
>>currently working on a new version of  the RequestProcessor to solves
>>some problems with multi modules. So, things will change. I am not sure
>>to be able to provide one single point for catching calls to include,
>>but I will try to minimize the number of places where it happens.
>>Actually, Tiles do include in the RequestProcessor, and in the InsertTag
>>(in Struts1.1).
>>
>>   Cedric
>>
>>Struts Newsgroup (@Basebeans.com) wrote:
>>
>>    
>>
>>>Subject: TilesRequestProcessor (WAS: Re: How do I navigate from one
>>>      
>>>
>subApp to another in Struts1.1?)
>  
>
>>>From: "Kevin Henrikson" <kevin.henrikson@openwave.com>
>>>===
>>>Cedric,
>>>
>>>   We subclass the Struts RequestProcessor to provide some special
>>>      
>>>
>resource
>  
>
>>>resolving, (i.e. override the doForward and doInclude methods to do some
>>>special file path resolution).  Unfortunately if we try this same code
>>>      
>>>
>with
>  
>
>>>the TilesRequestProcessor (so we can get the cool ability to do
>>>includes/forwards with tiles definitions directly in the
>>>      
>>>
>struts-config.xml)
>  
>
>>>it won't work.  Is there a 'hook' per say inside a tiles that is easily
>>>subclassed to provide us access to do filepath resolution before the URI
>>>      
>>>
>is
>  
>
>>>passed to the RequestDispatcher or pageContext.include() is called?
>>>   If not I think this would be a very nice enhancement.  Basically
>>>      
>>>
>struts
>  
>
>>>allows us to hook in to it's RequestDispatcher calls but when tiles in
>>>present there is nolonger a single point of RequestDispatching.  To
>>>workaround this now we'd have to tweak some internals of the
>>>InsertTag/GetTag since it also call include directly.  Is there any plans
>>>      
>>>
>to
>  
>
>>>centralize calls to RequestDispatcher, and pageContext.include() in the
>>>      
>>>
>tile
>  
>
>>>code base now that tiles in more fully integrated with the Struts code
>>>      
>>>
>base?
>  
>
>>>thanks
>>>
>>>-kevin
>>>
>>>"Cedric Dumoulin" <cedric.dumoulin@lifl.fr> wrote in message
>>>news:mailman.1026900060.23255.struts@basebeans.com...
>>>
>>>
>>>      
>>>
>>>> Normally it doesn't matter.
>>>> The Tiles servlet was used from 1.1dev until 1.1b1 to initialize
>>>>Tiles. It contains some request processing methods used only by
>>>>        
>>>>
>Struts1.0.
>  
>
>>>> The TilesRequestProcessor should normally not impact on the normal
>>>>request processor work. It just check if a forward or include is done on
>>>>a (logical) definition name. If it is not the case, the uri is passed
>>>>"as is" to RequestDispatcher.include() or forward().
>>>>
>>>> Cedric
>>>>
>>>>Trieu, Danny wrote:
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Craig,
>>>>>
>>>>>Does it mater if my action servlet is the TilesActionComponentServlet?
>>>>>
>>>>>danny
>>>>>
>>>>>-----Original Message-----
>>>>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>>>>Sent: Tuesday, July 16, 2002 7:53 PM
>>>>>To: Struts Users Mailing List
>>>>>Subject: RE: How do I navigate from one subApp to another in Struts1.1?
>>>>>
>>>>>
>>>>>
>>>>>On Tue, 16 Jul 2002, Trieu, Danny wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>Date: Tue, 16 Jul 2002 19:22:08 -0700
>>>>>>From: "Trieu, Danny" <DTrieu@ebuilt.com>
>>>>>>Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>>>>>To: 'Struts Users Mailing List' <struts-user@jakarta.apache.org>
>>>>>>Subject: RE: How do I navigate from one subApp to another in
>>>>>>            
>>>>>>
>Struts1.1?
>  
>
>>>>>>Craig,
>>>>>>
>>>>>>I have an action=foo under subapp bar.
>>>>>>I register my subapp like this:
>>>>>>Web.xml
>>>>>>  <init-param>
>>>>>>    <param-name>config/bar</param-name>
>>>>>>    <param-value>/WEB-INF/struts-bar.xml</param-value>
>>>>>>  </init-param>
>>>>>>
>>>>>>
>>>>>>How come it give me a 404 error when I call my action in the browser
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>with
>>>
>>>
>>>      
>>>
>>>>>>this URL: http://localhost:7001/my_web_app/bar/foo.do
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>What does your servlet mapping look like?  It should still use the
>>>>>          
>>>>>
>"*.do"
>  
>
>>>>>pattern.
>>>>>
>>>>>Do you also have a "default" subapp configured with the plain "config"
>>>>>init parameter?  I've never tried it without, although conceptually it
>>>>>should work.
>>>>>
>>>>>Craig
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Craig R. McClanahan [mailto:craigmcc@apache.org]
>>>>>>Sent: Tuesday, July 16, 2002 6:38 PM
>>>>>>To: Struts Users Mailing List
>>>>>>Subject: Re: How do I navigate from one subApp to another in
>>>>>>            
>>>>>>
>Struts1.1?
>  
>
>>>>>>
>>>>>>On Tue, 16 Jul 2002, Trieu, Danny wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Date: Tue, 16 Jul 2002 18:11:48 -0700
>>>>>>>From: "Trieu, Danny" <DTrieu@ebuilt.com>
>>>>>>>Reply-To: Struts Users Mailing List <struts-user@jakarta.apache.org>
>>>>>>>To: "'struts-user@jakarta.apache.org'"
>>>>>>>              
>>>>>>>
><struts-user@jakarta.apache.org>
>  
>
>>>>>>>Cc: "'craigmcc@apache.org'" <craigmcc@apache.org>
>>>>>>>Subject: How do I navigate from one subApp to another in Struts1.1?
>>>>>>>
>>>>>>>For example: I am in a page of a sub-application of a Struts
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>application,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>>and I want to render a link that link you to another sub-application
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>within
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>the application using the <html:link/> tag.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>The tempting way to do this is to do something like
>>>>>>
>>>>>><html:link forward="foo"/>
>>>>>>
>>>>>>and mark the "foo" forward as being context relative.  However, this
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>will
>>>
>>>
>>>      
>>>
>>>>>>ONLY work if you are switching to the default sub-app, because you'd
>>>>>>            
>>>>>>
>be
>  
>
>>>>>>bypassing the controller servlet where sub-app selection is performed.
>>>>>>
>>>>>>The better way is to make your link go through an <action> that
uses
>>>>>>            
>>>>>>
>the
>  
>
>>>>>>standard SwitchAction class.  This wants you to send along the
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>application
>>>
>>>
>>>      
>>>
>>>>>>prefix of the sub-app you want to switch to, as well as a resource
in
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>that
>>>
>>>
>>>      
>>>
>>>>>>sub-app to forward to after the switch.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>danny
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Craig
>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>To unsubscribe, e-mail:
>>>>>><mailto:struts-user-unsubscribe@jakarta.apache.org>
>>>>>>For additional commands, e-mail:
>>>>>><mailto:struts-user-help@jakarta.apache.org>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>To unsubscribe, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>><mailto:struts-user-unsubscribe@jakarta.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>For additional commands, e-mail:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>><mailto:struts-user-help@jakarta.apache.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>            
>>>>>>
>>>>>--
>>>>>To unsubscribe, e-mail:
>>>>><mailto:struts-user-unsubscribe@jakarta.apache.org>
>>>>>For additional commands, e-mail:
>>>>><mailto:struts-user-help@jakarta.apache.org>
>>>>>
>>>>>
>>>>>--
>>>>>To unsubscribe, e-mail:
>>>>>
>>>>>
>>>>>          
>>>>>
>>><mailto:struts-user-unsubscribe@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>>For additional commands, e-mail:
>>>>>
>>>>>
>>>>>          
>>>>>
>>><mailto:struts-user-help@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>>
>>>>>          
>>>>>
>>>>--
>>>>To unsubscribe, e-mail:
>>>>
>>>>
>>>>        
>>>>
>>><mailto:struts-user-unsubscribe@jakarta.apache.org>
>>>
>>>
>>>      
>>>
>>>>For additional commands, e-mail:
>>>>
>>>>
>>>>        
>>>>
>>><mailto:struts-user-help@jakarta.apache.org>
>>>
>>>
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>>      
>>>
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>  
>
>>>For additional commands, e-mail:
>>>      
>>>
><mailto:struts-user-help@jakarta.apache.org>
>  
>
>>>
>>>      
>>>
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><mailto:struts-user-unsubscribe@jakarta.apache.org>
>  
>
>>For additional commands, e-mail:
>>    
>>
><mailto:struts-user-help@jakarta.apache.org>
>  
>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>
>
>  
>



--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message