myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: Portlets & <a href="">: resource or action URL?
Date Fri, 15 Jun 2007 16:06:54 GMT
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 <darkarena@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 <martin.marinschek@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 <darkarena@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 <darkarena@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 <darkarena@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)
> >>> > >> >> > <alexander.jesse@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 <awiner@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
> >>>
> >>
> >
> >
>
>

Mime
View raw message