On Sun, Nov 24, 2013 at 7:37 AM, Lance Java <lance.j...@googlemail.com>wrote:
> > 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? > <html t:type="layout" title="AjaxFormLoopDemo" xmlns:t=" http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"; xmlns:p="tapestry:parameter"> <t:form t:id="form"> <div t:type="ajaxformloop" t:id="phones" source="person.phones" value="phone" encoder="encoder"> <t:select t:id="type" model="selectModel" value="phone.phoneType"/> <t:textfield t:id="number" value="phone.number"/> <t:removerowlink>remove</t:removerowlink> </div> <input type="submit" value="Update"/> </t:form> </html> > > > 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 > In order to save the phone record, I would need to save the person record as well do to a not null constraint on person_id. 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() > I'm not sure I follow option 2, but sending a negative tempId to the frontend enables me to evaluate whether or not it will become a new object when the form is saved and toValue is called. toValue is called before setPhone, so if we return new Phone() in the encoder, the values of that field can be set from the frontend and eventually saved to the database with the person object. This approach prevents the user from saving unnecessary data to the database, prevents the need to use @Persist making it much more scalable, and handles the not blank value needed exception. > Option 3: @Persist your phones in the session. Your ValueEncoder then > converts between object and string using the array index > This is a possibility, however I don't believe this to be the most scalable approach do to the fact we are saving user data to the session. If you have sometime, you should try creating a new quickstart project using 5.4 and just just copy the code / classes I provided. It will give you a chance to see how this approach works, but more importantly demonstrate the bug. I've been able to determine this is a FireFox issue using 25.0.1. on both my pc and mac, so I'm not sure if that gets us any closer. Thanks Lance. > 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 > > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
