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
