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 [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
