portals-pluto-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David H. DeWolf" <ddew...@apache.org>
Subject Re: Trying to understand test portal/portlet request handling
Date Wed, 09 Nov 2005 14:51:43 GMT
On 11/9/05, Graham Klyne <GK@ninebynine.org> wrote:
>
> David H. DeWolf wrote:
> > Sure:
> >
> >
> > You're correct, the PortalDriverServlet is the point of entry into the
> > portal system. Once it receives a request, it gathers configuration
> > information, processes any requested actions, and and determines which
> > resource is used to generate content for that page (that's what
> > pageConfig.getUri()). A request dispatcher is then retrieved for that
> > resource, and the request is handed off to that for handling...
> >
> > The configuration information which you're probably looking for (which
> > is what populates pageConfig.getUri()) resides in
> > WEB-INF/pluto-portal-driver-config.xml. This config file (amoung other
> > things) defines the Pages and their backing uri which can be used to
> > generate content. From this file, you can determine that "Test Page" is
> > rendered by /WEB-INF/fragments/portlet.jsp.
>
> This is great... just what I needed. Thanks!
>
> However (inevitably, perhaps), in the spirit on "no good deed goes
> unpunished", no good answer fails to beget another question ;-) ...
>
> I'm now looking at:
> [[
> <render-config default="Test Page">
> <page name="Test Page" uri="/WEB-INF/fragments/portlet.jsp">
> <portlet context="/testsuite" name="TestPortlet1"/>
> <portlet context="/testsuite" name="TestPortlet2"/>
> </page>
> <page name="Secondary Page" uri="/WEB-INF/fragments/portlet.jsp">
> <portlet context="/testsuite" name="TestPortlet1"/>
> <portlet context="/testsuite" name="TestPortlet2"/>
> </page>
> <page name="About Pluto" uri="/WEB-INF/fragments/about.jsp"/>
> </render-config>
> ]]
> -- pluto-portal/src/main/webapp/WEB-INF/pluto-portal-driver-config.xml
>
> and also: [http://www.developer.com/java/web/article.php/3554396],


There's a new article that should be coming out sometime this week that will
address Embedding Pluto. (I'll post an announcement to this list once it
goes up). It will probably answer many more of these "subsequent questions".
Feel free to continue to ask questions either way. . .

And I'm not clear about the 'context="/testsuite"' attribute here. From
> Tomcat configuration, I'm expecting the context to be the URI path
> through which resource rendering is retrieved, but that doesn't seem to
> be the case here. I might hazard a guess that this context is the
> directory, relative to the Tomcat webapps directory (or the effective
> root directory for servlets) in which the portlet code is run. Am I far
> wrong, or is there a completely different explanation.


Your first guess is correct. The context is the context path to which the
portlet app is deployed within the app server. I'm not sure why "that
doesn't seem to be the case here". ..is it perhaps because the war is
pluto-testsuite.war? If so, this seems to be a reocurring confusion point.
It still get's deployed to /testsuite through the context configuration file
placed in conf/Catalina/localhost/testsuite.xml. I've got several
enhancements to the installer that I'm working on right now -- one of htem
will fix this confusion.

I assume the "name=" attributes here are the names of the portlets (or
> servlets) whose joint content is included by <pluto:render> in the JSPs?



Correct. They are the portlet names. Since the container can read the
portlet.xml within the context, I'm considering removing these, but for now,
yes, define the portlets you want to use within this context here.

...
>
> Working my way down through the chain of command, I end up in class
> testPortlet.java, which I can see appears to run tests provided by
> various servlets and test pages, but I can't see any logic to render the
> front page of the test portal (the one with the names of the text cases
> and the "Test" links; e.g. included in the display of
> "http://localhost:8080/pluto/portal/").


This logic is in the jsp templates. Take a look at the PortalDriverServlet.
Specifically, these four lines initiate rendering:

PageConfig pageConfig = getPageConfig(currentURL);
request.setAttribute(AttributeKeys.CURRENT_PAGE, pageConfig);
String uri = pageConfig.getUri();
RequestDispatcher dispatcher = request.getRequestDispatcher(uri);
dispatcher.forward(request, response)

The page config's uri comes from the following configuration element that
you referenced before:

<page name="Test Page" uri="/WEB-INF/fragments/portlet.jsp">

The portlet.jsp page is what you're looking for. . .


Am I close, or just wandering in the woods here? Can you provide any
> further hint?


I think you're getting there -- and I'm really looking forward to your
suggestions on how to make things easier -- hopefully just documentation (
i.e. the new article) will help.

David

...
>
> I'm adding my notes about all this to the wiki page at:
> http://wiki.oss-watch.ac.uk/PlutoNotes
> (see section "Request flows in Pluto 1.1"). I'd appreciate any comments
> and corrections regarding what I've found.
>
> #g
>
> --
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>

Mime
View raw message