Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: domain of awiner@gmail.com designates
 64.233.162.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=SqfM6pzqNDKh5Pq/sWGq13qDkf7aL4hcVIekjGXB4M97Vpnmfe+kZotUqxKvBeNy8sJxvSjzgDB+LSlg3qxVOB8Qn/+/A8PtODHrbuJ4hb6J5vCgWq/v6aFOAOVZb0baIHfIUGAJwxPZzSDhTOk94bKUT0f5xjIOLEMchTuANiQ=
Message-ID: <6dac79b90706252347m479e2744l1b67ee2dda1eaa78@mail.gmail.com>
Date: Mon, 25 Jun 2007 23:47:24 -0700
From: "Adam Winer" <awiner@gmail.com>
To: "MyFaces Discussion" <users@myfaces.apache.org>
Subject: Re: [Trinidad] Detailstamp facet problem
In-Reply-To: <6dac79b90706251712k5999e879kdf05ee9900524234@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <464DB92F.3050806@kava.be> <4655339D.7050308@kava.be>
	 <467B9BFE.8090401@kava.be>
	 <6dac79b90706251011p5bddbcbdie32df205ed6119b1@mail.gmail.com>
	 <6dac79b90706251029l2d944439w47a9678d169105bc@mail.gmail.com>
	 <6dac79b90706251712k5999e879kdf05ee9900524234@mail.gmail.com>

BTW, to be clear:  the original behavior, where contents
are not submitted with the "details" are closed, is
currently "not a bug" - set immediate to false (the default).

What I fixed was the issue where the contents were
showing up blank, which was a bug that would
affect any use of nested tr:tables.

-- Adam


On 6/25/07, Adam Winer <awiner@gmail.com> wrote:
> OK, the detailStamp bug is fixed.
>
>
> -- Adam
>
>
> On 6/25/07, Adam Winer <awiner@gmail.com> wrote:
> > I've filed the detailStamp bug as:
> >
> > http://issues.apache.org/jira/browse/TRINIDAD-75
> >
> > It repros in the Trinidad demo bundle too.
> >
> > -- Adam
> >
> >
> > On 6/25/07, Adam Winer <awiner@gmail.com> wrote:
> > > On 6/22/07, Henk Vanhoe <Henk.Vanhoe@kava.be> wrote:
> > > > Finally, I have found some time to make a testproject where this
> problem
> > > > (bug?) can be duplicated...
> > > >
> > > > There is a jsp in this project
> > > > (/detailstamptest/faces/table/changeTable.jspx) which
> consists of a
> > > > table with one element. Next to this element there is a 'Show detail'
> > > > link. When you click on this link you see a new table with two
> > > > addresses. When you close the detail and reopen it, the detail-table
> is
> > > > empty and there are some error-messages in the logs ("Exception while
> > > > determining read-only state of value-binding").
> > > >
> > > > This problem can be solved by changing the
> > > > org.apache.myfaces.trinidad.CLIENT_STATE_METHOD param
> in web.xml from
> > > > "all" to "token".
> > >
> > > I can reproduce this.  It's strange - I assume it's a serialization
> > > issue somewhere in the table state saving code, but just a guess.
> > >
> > > > However, now there is a new problem... When you open
> > > > the detail, change one of the street-names, close the detail again and
> > > > then hit the save-button you can see in the log-messages that the
> > > > changes are not submitted to the server! When you leave the detail
> open
> > > > and hit the save-button, the changes are submitted...
> > >
> > > The tables have immediate="true" on them, which means that the
> > > values aren't pushed to the model when you toggle the table.
> > > Remove immediate="true".
> > >
> > > -- Adam
> > >
> >
>
>