it could, but need modifications because a page belong to a unique portal.

so you need to issue the portal name as well.

like /pages/myportal/forums

"julien@jboss.com" wrote:
it could, but need modifications because a page belong to a unique portal.

so you need to issue the portal name as well.

like /pages/myportal/forums

for those who are interested the classes to look at are org.jboss.portal.core.impl.invocation.CoreInvocation and org.jboss.portal.impl.invocation.Invocation

they show how a request is decoded an turned down into an invocation and how an URL is generated.

it is really similar to the Invoker design we have in JBoss.

the important point at the end, is that it is not hardcoded and can be swapped easily.

my guess it is omething that will be tuned over time.

"roy.russo@jboss.com" wrote:

"julien@jboss.com" wrote:
it could, but need modifications because a page belong to a unique portal.

so you need to issue the portal name as well.

like /pages/myportal/forums

Correct, but I think this is ugly.

Also remember we are doing subdomain mapping for labs at the tomcat level, I believe.

Google will still index these pages, and the main pages at least are still able to be bookmarked.

"julien@jboss.com" wrote:

it is really similar to the Invoker design we have in JBoss.

an invoker role in AS is to take the invocation and make it travel to the server,
it is splitted between the client and the server.

In my case, when the portlet creates a portlet URL which targets a portlet, let's
say an action. The PortletURL object toString() method is responsible for creating
a URL that will invoke the processAction() method on the component. So this
represents an invocation. It has a target, the portlet ID, a server to send
the invocation to and a bunch of parameters.

So there is a need for a mechanism that takes all of these and creates a URL that
will invoke the processAction() on the object with the specified parameters.
That mechanism is on the PortletURL side responsible for creating the URL and
it also sits in the servlet to receive the request/response, decodes the request
(id and parameters) and invoke the portlet.

I am not sure of that, but the benefits of having that design could be with WSRP which is another way to invoke portlets. It is a protocol based on SOAP which express the same invocation semantics defined on portlets.

But I am just speculating here.