Adam,
Your right that they should be the same. Unfortunatly they are not.
It's one of the many things that's wrong about Portals in the JSF spec
and it comes with dabbling in theory rather then actually trying to get
something valuable (like an complete and complex renderkit) working with
a portal. My guess is they had a series of "Hello World" apps that they
tested with the RI taglib in a portal. As a result, the IBM guys didn't
do a very good job on considering all the implications. That's one of
the reasons JSR-301 started with a renderkit like Trinidad as one of
it's primary test cases.
The reason that Martain believe these should be resouce urls is that the
PortletResponse.encodeResourceUrl will correctly resolve "external"
links. This means that passing in http://www.google.com will return
http://www.google.com. Things in the portal web application will return
urls and links to something inside the portal application. The problem
is that once this resouce url gets set on the outside page, you have the
potential of being out-of-context and you will most definatly switch
from running in a portal engine to running in a servlet engine. Also,
if the link your encoding is to a FacesResource, the bridge cannot be
referenced by the goLink because the bridge is a portlet which needs to
be referenced by a portlet (Action) url.
That's the reason that in 301, we take this encoding complexity into the
bridge and the symantic becomes much simpler. The rule of thumb for
encoding (and you'll be right say 90% of the time) is that if it's
appropriate for the portal to add it's own markup (including other
portlets) to your returned content then it should be an action url.
Otherwise it should be a resource url. There are certainly exceptions
to this (unfortunately) but the rule of thumb generally works.
Things that you would "think" are the same (such as goLinks and Iframes)
you'll discover are NOT the same if you apply that rule of thumb. It's
appropriate to have portal content in the base page referred to by the
goLink. It is NOT appropriate for an iframe.
Scott
Adam Winer wrote:
> It sounds like you're saying that a goLink should
> be an action, but an iframe should be a resource?
> I've always assumed the two should be identical.
>
> The Javadoc for ExternalContext is incredibly unhelpful
> here. I wish the IBM EG member who contributed that
> API had made this clear back then! Especially confusing
> is the text:
>
> Portlet: This must be the value returned by the
> javax.portlet.PortletResponse method encodeURL(url).
>
> ... included on *both* encodeActionURL() and
> encodeResourceURL(). This makes it sound as though
> the two are required to have exactly the same behavior!?!
>
> -- Adam
>
>
>
> On 6/14/07, Scott O'Bryan <[EMAIL PROTECTED]> wrote:
>> I agree with Adam. The distinction is NOT post vs. get, rather the
>> distinction is something that's a piece of a page v.s something
that's a
>> complete page.
>>
>> So what's the difference. The difference is that the Portal sees
action
>> urls as needing to be posted in context of the main page. On an
action
>> url, the portal will process all other portlets as well and return a
>> page with markup generated from the portal (not directly from the
>> portlet). With resource urls, the portal doesn't muck with anything.
>>
>> Now Faces somewhat confuses this issue as there is an encode for both
>> the action and the resource URL. I can tell you that, in general,
>> JSR-168 would expect you to encode goLinks as stuff as "action" urls.
>> The encode action url method in 301 is smart enough to figure out
>> whether the resource your trying to reference is a Faces viewId or
some
>> other external page. If it's an external url the encoded url will
hit
>> that resource directly. If it's a faces page, the bridge will
generate
>> an actionUrl that will make a request to the new view id through the
>> bridge. Without encoding this as an action url though, you would
loose
>> all of your portal context.
>>
>> There are some instances where you may want to use a resource url
>> (iframes and PPR are a perfect example), but usually links should be
>> action urls.
>>
>> Scott
>>
>> Adam Winer wrote:
>> > I don't see why - what is the difference between
>> > a link to a page and an iframe pointing at that page?
>> > It's exactly the same HTTP request. If <a href>
>> > should use getActionUrl(), then iframe and frame
>> > srcs also should.
>> >
>> > -- Adam
>> >
>> >
>> > On 6/13/07, Jesse Alexander (KSFD 121)
>> > <[EMAIL PROTECTED]> wrote:
>> >> Adam mentions iframe/frame-src attributes... I guess those would
>> >> qualify as resource-url's ?
>> >>
>> >> regards
>> >> Alexander
>> >>
>> >> -----Original Message-----
>> >> From: Martin Marinschek [mailto:[EMAIL PROTECTED]
>> >> Sent: Thursday, June 14, 2007 6:25 AM
>> >> To: MyFaces Development
>> >> Subject: Re: Portlets & <a href="">: resource or action URL?
>> >>
>> >> Definitely encodeActionUrl, yes, from what I read in the portlet
>> spec.
>> >> Obviously the original link implementors thought the
distinction was
>> >> about form post versus get - but the distinction is about query
>> >> links/form submissions versus inclusion of resources in the page.
>> >>
>> >> regards,
>> >>
>> >> Martin
>> >>
>> >> On 6/14/07, Adam Winer <[EMAIL PROTECTED]> wrote:
>> >> > Simple (I imagine) question:
>> >> >
>> >> > For a link's "href", should we be calling encodeResourceURL()
>> >> > or encodeActionURL()?
>> >> >
>> >> > I've always assumed these are action URLs. I see other
>> >> > code out there (MyFaces outputLink, for example) that
>> >> > considers these resource URLs.
>> >> >
>> >> > (Whatever answer we arrive at should apply equally to
>> >> > iframe and frame "src" attributes, I believe).
>> >> >
>> >> > -- Adam
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> http://www.irian.at
>> >>
>> >> Your JSF powerhouse -
>> >> JSF Consulting, Development and
>> >> Courses in English and German
>> >>
>> >> Professional Support for Apache MyFaces
>> >>
>> >
>>
>>
>
