You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Adam Winer <aw...@gmail.com> on 2007/06/14 02:42:57 UTC
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
Posted by Scott O'Bryan <da...@gmail.com>.
Couple more clairifications:
1. You can post into resource and action urls. Portals always allow a
post for sending parameters. They just don't allow you to muck with the
url on client side.
2. The distinction should be based solely on whether the resource is the
main page or not. You generally won't want a copy of your portal and
all it's portlets being displayed as an iframe source. Rather you'll
just was the resource your trying to hit (be it static content or a
servlet).
3. Action urls allow for state changing and run via the portlet
container while resource urls are run though the portal in a servlet
container. The caviat to this is that any bridge (none of them
currently do this but 301 will) needs to have special handling of the
action request to determine whether the url is an internal url handled
by the bridge or whether it is a url to something not handled by the
bridge. In this case, the url should be encoded as a "direct" url.
It's important to understand that although a servlet developer may think
of these as "clear cut", a portal does not. There are always exceptions
to the rule and a lot more complexity then people give the problem
credit for. The difference between action and resource urls only makes
a difference in a portal environment so it's important to understand
what implications each of these urls has.
Maybe I should start up a wiki when we get the 301 project kicked off to
aid renderkit developers in understanding some of these concepts.
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)
> <al...@credit-suisse.com> wrote:
>> Adam mentions iframe/frame-src attributes... I guess those would
>> qualify as resource-url's ?
>>
>> regards
>> Alexander
>>
>> -----Original Message-----
>> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>> 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 <aw...@gmail.com> 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
>>
>
Posted by Scott O'Bryan <da...@gmail.com>.
LOL. I need to read everything before I respond. Yes, I agree with the
second part of your letter. Say we're 301 and fix the current bridge to
handle the encoding correctly. I should have that code fairly soon and
it wouldn't be an issue to move it into the current bridge implementation.
Scott
Scott O'Bryan wrote:
> :) I'm not being clear.....
>
> Ok, the current bridge implementations don't take into account the
> complexity of this issue. And as you said, Adam, the Faces spec isn't
> much help either. But someone who is using the current Faces
> implementation with the current bridge is expecting their application
> to perform incorrectly. Using the current bridges, encoding the URL's
> correct would cause things to get worse unless the bridge handled them
> correctly.
>
> I suppose we could modify everything to do the proper encoding in the
> renderkits and then fix the issue with the original bridge as well.
> Maybe that's the proper way to fix it.
>
> Scott
>
> Adam Winer wrote:
>> Wow, that really makes a total hash of things. So
>> you're saying there's one set of rules - which don't
>> really work at all - today, and another set of rules
>> tomorrow? Could you explain what the rules are
>> today?
>>
>> At any rate, if there are differences between the state
>> of affairs today (totally !#%#!%'ed up) and with the
>> 301 bridge (less !@%!@%'ed up), that should be
>> entirely hidden in base classes/utility methods.
>> In Trinidad, that should be in the CoreRenderer
>> base class.
>>
>> OTOH, perhaps we should just write to the 301
>> bridge, and force whoever maintains the current
>> bridge to stop doing the wrong thing to external
>> URLs. Asking 100s of renderer classes to change
>> one way and then back another way is insanity.
>>
>> In Trinidad, maybe we should deprecate
>> the existing CoreRenderer encodeActionURI()
>> and encodeResourceURI() methods, because no one
>> knows what the heck they mean, and come up with
>> new names that describe what sorts of URIs they
>> encode?
>>
>> -- Adam
>>
>
>
Posted by Scott O'Bryan <da...@gmail.com>.
:) I'm not being clear.....
Ok, the current bridge implementations don't take into account the
complexity of this issue. And as you said, Adam, the Faces spec isn't
much help either. But someone who is using the current Faces
implementation with the current bridge is expecting their application to
perform incorrectly. Using the current bridges, encoding the URL's
correct would cause things to get worse unless the bridge handled them
correctly.
I suppose we could modify everything to do the proper encoding in the
renderkits and then fix the issue with the original bridge as well.
Maybe that's the proper way to fix it.
Scott
Adam Winer wrote:
> Wow, that really makes a total hash of things. So
> you're saying there's one set of rules - which don't
> really work at all - today, and another set of rules
> tomorrow? Could you explain what the rules are
> today?
>
> At any rate, if there are differences between the state
> of affairs today (totally !#%#!%'ed up) and with the
> 301 bridge (less !@%!@%'ed up), that should be
> entirely hidden in base classes/utility methods.
> In Trinidad, that should be in the CoreRenderer
> base class.
>
> OTOH, perhaps we should just write to the 301
> bridge, and force whoever maintains the current
> bridge to stop doing the wrong thing to external
> URLs. Asking 100s of renderer classes to change
> one way and then back another way is insanity.
>
> In Trinidad, maybe we should deprecate
> the existing CoreRenderer encodeActionURI()
> and encodeResourceURI() methods, because no one
> knows what the heck they mean, and come up with
> new names that describe what sorts of URIs they
> encode?
>
> -- Adam
>
Posted by Adam Winer <aw...@gmail.com>.
Wow, that really makes a total hash of things. So
you're saying there's one set of rules - which don't
really work at all - today, and another set of rules
tomorrow? Could you explain what the rules are
today?
At any rate, if there are differences between the state
of affairs today (totally !#%#!%'ed up) and with the
301 bridge (less !@%!@%'ed up), that should be
entirely hidden in base classes/utility methods.
In Trinidad, that should be in the CoreRenderer
base class.
OTOH, perhaps we should just write to the 301
bridge, and force whoever maintains the current
bridge to stop doing the wrong thing to external
URLs. Asking 100s of renderer classes to change
one way and then back another way is insanity.
In Trinidad, maybe we should deprecate
the existing CoreRenderer encodeActionURI()
and encodeResourceURI() methods, because no one
knows what the heck they mean, and come up with
new names that describe what sorts of URIs they
encode?
-- Adam
On 6/15/07, Scott O'Bryan <da...@gmail.com> wrote:
> One more thing... We shouldn't fix these until the 301 bridge is
> available which does this special handling for encodeActionUrl. I don't
> think the current bridge properly encodes external urls so I don't want
> to break anyone for the time being. So at the very least the
> environment should be specified as 301. The 1.2 code I think we can
> change, but I havn't taken a look at the state of the portal stuff in
> that release yet.
>
> Scott
>
> Scott O'Bryan wrote:
> > Adam,
> >
> > I think Trinidad is working (although I havn't checked the inline
> > frame lately). Still, it would probably be prudent on general
> > principals. Do you want me to log the tickets?
> >
> > Scott
> >
> > Adam Winer wrote:
> >> And separate ones for Trinidad and Tomahawk too, I think!
> >>
> >> -- Adam
> >>
> >>
> >> On 6/14/07, Martin Marinschek <ma...@gmail.com> wrote:
> >>> We should open a JIRA issue to go through MyFaces and fix this
> >>> wherever necessary.
> >>>
> >>> thanks!
> >>>
> >>> regards,
> >>>
> >>> Martin
> >>>
> >>> On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> >>> > That's the rule of thumb. Yes.
> >>> >
> >>> > Martin Marinschek wrote:
> >>> > > May I try to put this shorter -
> >>> > >
> >>> > > actionUrl --> you'll see all portlets output, except you link to an
> >>> > > external page,
> >>> > >
> >>> > > resourceUrl --> you'll see only your output always
> >>> > >
> >>> > > is correct?
> >>> > >
> >>> > > regards,
> >>> > >
> >>> > > Martin
> >>> > >
> >>> > > On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> >>> > >> 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 <da...@gmail.com> 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)
> >>> > >> >> > <al...@credit-suisse.com> wrote:
> >>> > >> >> >> Adam mentions iframe/frame-src attributes... I guess
> >>> those would
> >>> > >> >> >> qualify as resource-url's ?
> >>> > >> >> >>
> >>> > >> >> >> regards
> >>> > >> >> >> Alexander
> >>> > >> >> >>
> >>> > >> >> >> -----Original Message-----
> >>> > >> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> >>> > >> >> >> 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 <aw...@gmail.com> 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
> >>> > >> >> >>
> >>> > >> >> >
> >>> > >> >>
> >>> > >> >>
> >>> > >> >
> >>> > >>
> >>> > >>
> >>> > >
> >>> > >
> >>> >
> >>> >
> >>>
> >>>
> >>> --
> >>>
> >>> http://www.irian.at
> >>>
> >>> Your JSF powerhouse -
> >>> JSF Consulting, Development and
> >>> Courses in English and German
> >>>
> >>> Professional Support for Apache MyFaces
> >>>
> >>
> >
> >
>
>
Posted by Scott O'Bryan <da...@gmail.com>.
One more thing... We shouldn't fix these until the 301 bridge is
available which does this special handling for encodeActionUrl. I don't
think the current bridge properly encodes external urls so I don't want
to break anyone for the time being. So at the very least the
environment should be specified as 301. The 1.2 code I think we can
change, but I havn't taken a look at the state of the portal stuff in
that release yet.
Scott
Scott O'Bryan wrote:
> Adam,
>
> I think Trinidad is working (although I havn't checked the inline
> frame lately). Still, it would probably be prudent on general
> principals. Do you want me to log the tickets?
>
> Scott
>
> Adam Winer wrote:
>> And separate ones for Trinidad and Tomahawk too, I think!
>>
>> -- Adam
>>
>>
>> On 6/14/07, Martin Marinschek <ma...@gmail.com> wrote:
>>> We should open a JIRA issue to go through MyFaces and fix this
>>> wherever necessary.
>>>
>>> thanks!
>>>
>>> regards,
>>>
>>> Martin
>>>
>>> On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
>>> > That's the rule of thumb. Yes.
>>> >
>>> > Martin Marinschek wrote:
>>> > > May I try to put this shorter -
>>> > >
>>> > > actionUrl --> you'll see all portlets output, except you link to an
>>> > > external page,
>>> > >
>>> > > resourceUrl --> you'll see only your output always
>>> > >
>>> > > is correct?
>>> > >
>>> > > regards,
>>> > >
>>> > > Martin
>>> > >
>>> > > On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
>>> > >> 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 <da...@gmail.com> 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)
>>> > >> >> > <al...@credit-suisse.com> wrote:
>>> > >> >> >> Adam mentions iframe/frame-src attributes... I guess
>>> those would
>>> > >> >> >> qualify as resource-url's ?
>>> > >> >> >>
>>> > >> >> >> regards
>>> > >> >> >> Alexander
>>> > >> >> >>
>>> > >> >> >> -----Original Message-----
>>> > >> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>>> > >> >> >> 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 <aw...@gmail.com> 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
>>> > >> >> >>
>>> > >> >> >
>>> > >> >>
>>> > >> >>
>>> > >> >
>>> > >>
>>> > >>
>>> > >
>>> > >
>>> >
>>> >
>>>
>>>
>>> --
>>>
>>> http://www.irian.at
>>>
>>> Your JSF powerhouse -
>>> JSF Consulting, Development and
>>> Courses in English and German
>>>
>>> Professional Support for Apache MyFaces
>>>
>>
>
>
Posted by Scott O'Bryan <da...@gmail.com>.
Adam,
I think Trinidad is working (although I havn't checked the inline frame
lately). Still, it would probably be prudent on general principals. Do
you want me to log the tickets?
Scott
Adam Winer wrote:
> And separate ones for Trinidad and Tomahawk too, I think!
>
> -- Adam
>
>
> On 6/14/07, Martin Marinschek <ma...@gmail.com> wrote:
>> We should open a JIRA issue to go through MyFaces and fix this
>> wherever necessary.
>>
>> thanks!
>>
>> regards,
>>
>> Martin
>>
>> On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
>> > That's the rule of thumb. Yes.
>> >
>> > Martin Marinschek wrote:
>> > > May I try to put this shorter -
>> > >
>> > > actionUrl --> you'll see all portlets output, except you link to an
>> > > external page,
>> > >
>> > > resourceUrl --> you'll see only your output always
>> > >
>> > > is correct?
>> > >
>> > > regards,
>> > >
>> > > Martin
>> > >
>> > > On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
>> > >> 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 <da...@gmail.com> 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)
>> > >> >> > <al...@credit-suisse.com> wrote:
>> > >> >> >> Adam mentions iframe/frame-src attributes... I guess those
>> would
>> > >> >> >> qualify as resource-url's ?
>> > >> >> >>
>> > >> >> >> regards
>> > >> >> >> Alexander
>> > >> >> >>
>> > >> >> >> -----Original Message-----
>> > >> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>> > >> >> >> 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 <aw...@gmail.com> 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
>> > >> >> >>
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >
>> > >
>> >
>> >
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
Posted by Adam Winer <aw...@gmail.com>.
And separate ones for Trinidad and Tomahawk too, I think!
-- Adam
On 6/14/07, Martin Marinschek <ma...@gmail.com> wrote:
> We should open a JIRA issue to go through MyFaces and fix this
> wherever necessary.
>
> thanks!
>
> regards,
>
> Martin
>
> On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> > That's the rule of thumb. Yes.
> >
> > Martin Marinschek wrote:
> > > May I try to put this shorter -
> > >
> > > actionUrl --> you'll see all portlets output, except you link to an
> > > external page,
> > >
> > > resourceUrl --> you'll see only your output always
> > >
> > > is correct?
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> > >> 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 <da...@gmail.com> 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)
> > >> >> > <al...@credit-suisse.com> wrote:
> > >> >> >> Adam mentions iframe/frame-src attributes... I guess those would
> > >> >> >> qualify as resource-url's ?
> > >> >> >>
> > >> >> >> regards
> > >> >> >> Alexander
> > >> >> >>
> > >> >> >> -----Original Message-----
> > >> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> > >> >> >> 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 <aw...@gmail.com> 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
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >
> > >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Posted by Martin Marinschek <ma...@gmail.com>.
We should open a JIRA issue to go through MyFaces and fix this
wherever necessary.
thanks!
regards,
Martin
On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> That's the rule of thumb. Yes.
>
> Martin Marinschek wrote:
> > May I try to put this shorter -
> >
> > actionUrl --> you'll see all portlets output, except you link to an
> > external page,
> >
> > resourceUrl --> you'll see only your output always
> >
> > is correct?
> >
> > regards,
> >
> > Martin
> >
> > On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> >> 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 <da...@gmail.com> 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)
> >> >> > <al...@credit-suisse.com> wrote:
> >> >> >> Adam mentions iframe/frame-src attributes... I guess those would
> >> >> >> qualify as resource-url's ?
> >> >> >>
> >> >> >> regards
> >> >> >> Alexander
> >> >> >>
> >> >> >> -----Original Message-----
> >> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> >> >> >> 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 <aw...@gmail.com> 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
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Posted by Scott O'Bryan <da...@gmail.com>.
That's the rule of thumb. Yes.
Martin Marinschek wrote:
> May I try to put this shorter -
>
> actionUrl --> you'll see all portlets output, except you link to an
> external page,
>
> resourceUrl --> you'll see only your output always
>
> is correct?
>
> regards,
>
> Martin
>
> On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
>> 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 <da...@gmail.com> 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)
>> >> > <al...@credit-suisse.com> wrote:
>> >> >> Adam mentions iframe/frame-src attributes... I guess those would
>> >> >> qualify as resource-url's ?
>> >> >>
>> >> >> regards
>> >> >> Alexander
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>> >> >> 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 <aw...@gmail.com> 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
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>>
>
>
Posted by Martin Marinschek <ma...@gmail.com>.
May I try to put this shorter -
actionUrl --> you'll see all portlets output, except you link to an
external page,
resourceUrl --> you'll see only your output always
is correct?
regards,
Martin
On 6/14/07, Scott O'Bryan <da...@gmail.com> wrote:
> 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 <da...@gmail.com> 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)
> >> > <al...@credit-suisse.com> wrote:
> >> >> Adam mentions iframe/frame-src attributes... I guess those would
> >> >> qualify as resource-url's ?
> >> >>
> >> >> regards
> >> >> Alexander
> >> >>
> >> >> -----Original Message-----
> >> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> >> >> 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 <aw...@gmail.com> 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
> >> >>
> >> >
> >>
> >>
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Posted by Scott O'Bryan <da...@gmail.com>.
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 <da...@gmail.com> 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)
>> > <al...@credit-suisse.com> wrote:
>> >> Adam mentions iframe/frame-src attributes... I guess those would
>> >> qualify as resource-url's ?
>> >>
>> >> regards
>> >> Alexander
>> >>
>> >> -----Original Message-----
>> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>> >> 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 <aw...@gmail.com> 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
>> >>
>> >
>>
>>
>
Posted by Adam Winer <aw...@gmail.com>.
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 <da...@gmail.com> 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)
> > <al...@credit-suisse.com> wrote:
> >> Adam mentions iframe/frame-src attributes... I guess those would
> >> qualify as resource-url's ?
> >>
> >> regards
> >> Alexander
> >>
> >> -----Original Message-----
> >> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> >> 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 <aw...@gmail.com> 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
> >>
> >
>
>
Posted by Scott O'Bryan <da...@gmail.com>.
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)
> <al...@credit-suisse.com> wrote:
>> Adam mentions iframe/frame-src attributes... I guess those would
>> qualify as resource-url's ?
>>
>> regards
>> Alexander
>>
>> -----Original Message-----
>> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
>> 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 <aw...@gmail.com> 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
>>
>
Posted by Adam Winer <aw...@gmail.com>.
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)
<al...@credit-suisse.com> wrote:
> Adam mentions iframe/frame-src attributes... I guess those would
> qualify as resource-url's ?
>
> regards
> Alexander
>
> -----Original Message-----
> From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> 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 <aw...@gmail.com> 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
>
Posted by "Jesse Alexander (KSFD 121)" <al...@credit-suisse.com>.
Adam mentions iframe/frame-src attributes... I guess those would
qualify as resource-url's ?
regards
Alexander
-----Original Message-----
From: Martin Marinschek [mailto:martin.marinschek@gmail.com]
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 <aw...@gmail.com> 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
Posted by Martin Marinschek <ma...@gmail.com>.
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 <aw...@gmail.com> 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