> I used very similar code in 5.3.7 without issue which is why I believe
this
is a bug.
Ah, ok... I agree that this does point in the direction of a 5.4 bug.
> I was hoping to manage the formloop through the use of my person
object rather than having to manage the form loop through the phone object
and then having to sync the two objects up on the backend. Like I said, no
issues in 3.7.
Can I see the related TML?
> The reason for the tempid is do to the fact I get this exception when I pass
a null id to the interface while trying to remove the row
Ah, I see what you're doing... you can do this without tempId.
Option 1: Save the empty Phone you've created in onAddRow() to the database
before returning so that it has an id and can be looked up later
Option 2: Your value encoder returns ***i-am-new*** in toClient() for a
phone who's id is null. It then returns new Phone() for ***i-am-new*** in
toValue()
Option 3: @Persist your phones in the session. Your ValueEncoder then
converts between object and string using the array index
On 23 November 2013 23:06, George Christman <gchrist...@cardaddy.com> wrote:
> On Sat, Nov 23, 2013 at 4:48 AM, Lance Java <lance.j...@googlemail.com
> >wrote:
>
> > I'm still not convinced this is a bug in tapestry... it might be but
> > there's still some suspect areas in your code.
> >
>
> I used very similar code in 5.3.7 without issue which is why I believe this
> is a bug. I was hoping to manage the formloop through the use of my person
> object rather than having to manage the form loop through the phone object
> and then having to sync the two objects up on the backend. Like I said, no
> issues in 3.7.
>
>
> >
> > 1. In hibernate, Phone has-a Person (@ManyToOne) and Person has Phones(s)
> > (@OneToMany) but you seem to be manipulating both:
> >
> > @CommitAfter
> > void onRemoveRow(Phone phone) {
> > person.getPhones().remove(phone);
> > session.delete(phone);
> > }
> >
> > I'm thinking you should manipulate one and get the other from hibernate.
> >
>
> Your correct, I do not need the person.getPhones().remove(phone); Not sure
> why I was thinking I needed it. I now just delete the phone object, but
> still no change.
>
> In my real project the fields are already added from the database so I was
> able to test the component by removing the encoder from the ajaxformloop.
> When I delete, still same issue. Even if I refresh the page after deletion,
> still holds onto the wrong values. I'd like to point out i'm using firefox
> too.
>
> >
> > 2. This whole @Transient temp id -System.nanoTime() thingy. Why is this
> > required?
> > It looks like you've let your UI implementation creep into your model.
> > Always a bad idea ;)
> >
>
> The reason for the tempid is do to the fact I get this exception when I
> pass a null id to the interface while trying to remove the row
>
> *The value for query parameter 't:rowvalue' was blank, but a non-blank
> value is needed.*
>
> >
> > 3. PhoneTypes doesn't relate to Person... these look like globals.
> > I'd really advise against initializing them in your page.
> > Looks more like a @Startup job or at least a synchronized method on a
> > service.
> >
> > This isn't production code, I just through some demo code together to
> illistrate the issue. I wrote the code enabling you guys to quickly be able
> to test the component and determine if what I found was a bug.
>
> I still believe it has something to do with how the form loop holds on to
> values. I notice serverside validation now works properly, so I wonder if
> the issue has something to do with that bug fix.
>
> >
> >
> > On 22 November 2013 20:50, George Christman <gchrist...@cardaddy.com>
> > wrote:
> >
> > > Your on :) you can just paypal me haha.
> > >
> > > Well the value encoder doesn't appear to be the issue. :( I can
> > completely
> > > remove the encoder parameter from the component and refresh the page
> and
> > it
> > > will still hold on to the wrong result despite the correct select
> option
> > > being selected in the select menu. I tried clearing my browser cache as
> > > well, no change. Should I file a bug report with JIRA?
> > >
> > >
> > > On Fri, Nov 22, 2013 at 3:24 PM, Lance Java <lance.j...@googlemail.com
> > > >wrote:
> > >
> > > > As I said... I haven't taken the time to fully understand the code.
> > > >
> > > > That being said, I'd be willing to bet you a fiver that it's causing
> > the
> > > > issue
> > > > :)
> > > >
> > >
> > >
> > >
> > > --
> > > George Christman
> > > www.CarDaddy.com
> > > P.O. Box 735
> > > Johnstown, New York
> > >
> >
>
>
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
