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 [EMAIL PROTECTED]@%'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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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 >>> > >> >> >> >>> > >> >> > >>> > >> >> >>> > >> >> >>> > >> > >>> > >> >>> > >> >>> > > >>> > > >>> > >>> > >>> >>> >>> -- >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >> > >
