Ah, I see. You're using "server" state saving, so using the
underlying JSF implementation to save state. The
Trinidad StateManager (used for client state saving) doesn't
use colons.
-- Adam
On 5/30/07, D. Cardon <[EMAIL PROTECTED]> wrote:
I was looking at the StateManagerImpl class of the co
I was looking at the StateManagerImpl class of the com.sun.faces.application
package, line number
116 in jsf-impl-1.2_03. It seems like it uses a ':' separator character in
restoring the view...
Anyway, it turns out I was able to get it working anyway. After looking at the
HTML generated,
som
That doesn't sound right - we don't expect a colon at all
in the state token. What line of code are you looking at?
-- Adam
On 5/30/07, D. Cardon <[EMAIL PROTECTED]> wrote:
Adam,
Thanks for the info!
Since I'm using the trunk, the org.apache.myfaces.trinidad.faces.STATE is what
needs to be
Adam,
Thanks for the info!
Since I'm using the trunk, the org.apache.myfaces.trinidad.faces.STATE is what
needs to be sent
(at least, that's what's listed in my CoreResponseStateManager class).
So, I now have the GWT request send that variable set to its component's id.
I.e., the GWT widget
i
Now, I've tried trinidad 1.2 and 1.0.1 but both of them have same error
with decimal separator sign -
https://issues.apache.org/jira/browse/ADFFACES-427
(yes, client decimal number validator is still broken since
m1-incubating version). But now I get different error. There is no popup
alert win
once in a while, there is a new branch created for the JSF 1.2 stuff
that get's all trunk fixed bugs in it.
-M
On 5/30/07, Luka Surija <[EMAIL PROTECTED]> wrote:
and, all fixed issues in 1.0.1 are also fixed in 1.2?
Adam Winer wrote:
> If you're using JSF 1.2, it is more stable.
>
> -- Adam
>
and, all fixed issues in 1.0.1 are also fixed in 1.2?
Adam Winer wrote:
If you're using JSF 1.2, it is more stable.
-- Adam
On 5/29/07, Luka Surija <[EMAIL PROTECTED]> wrote:
How stable is Trinidad 1.2 comparing with 1.0.1?
Luka
Adam Winer wrote:
> The Trinidad 1.2 code sends javax.faces.V
If you're using JSF 1.2, it is more stable.
-- Adam
On 5/29/07, Luka Surija <[EMAIL PROTECTED]> wrote:
How stable is Trinidad 1.2 comparing with 1.0.1?
Luka
Adam Winer wrote:
> The Trinidad 1.2 code sends javax.faces.ViewState (the 1.2 spec
> requires this), but the trunk doesn't, instead se
How stable is Trinidad 1.2 comparing with 1.0.1?
Luka
Adam Winer wrote:
The Trinidad 1.2 code sends javax.faces.ViewState (the 1.2 spec
requires this), but the trunk doesn't, instead sending
org.apache.myfaces.trinidad.faces.STATE. If you're using JSF 1.2,
you could (and should) use the Trinid
The Trinidad 1.2 code sends javax.faces.ViewState (the 1.2 spec
requires this), but the trunk doesn't, instead sending
org.apache.myfaces.trinidad.faces.STATE. If you're using JSF 1.2,
you could (and should) use the Trinidad 1.2 code.
-- Adam
On 5/29/07, D. Cardon <[EMAIL PROTECTED]> wrote:
Thanks for your response, I looked into it and found out that when G4JSF builds
its request, it
send the javax.faces.ViewState variable in the request. Do I need to have it
send something
different for Trinidad?
--David
--- Adam Winer <[EMAIL PROTECTED]> wrote:
> If there's no tree, I suspect
If there's no tree, I suspect that the state parameter is
not getting submitted. Check the G4JSF code to see if
it has hardcoded a list of request parameters to submit.
-- Adam
On 5/29/07, D. Cardon <[EMAIL PROTECTED]> wrote:
Hi all,
I'm using MyFaces Trinidad and am integrating the Google W
Hi all,
I'm using MyFaces Trinidad and am integrating the Google Web Toolkit (GWT) to
work along with it.
I am using the G4JSF project along with some of my own modifications. So far,
everything on the
client side is working just fine, but I am having difficulty communicating with
the server
13 matches
Mail list logo