Re: [html-formfu] ExtJS::REST
Am 11.05.2009 um 01:24 schrieb Mario Minati: OK I see. I think we can make this the default behaviour. This will cause a database roundtrip but I think it's the best way to make sure that the data we give back is the same as the data the user will get when he requests that item. You are right, but FF itself doesn't take db changes into account by default. And the db processing for more complex forms with repeatables and so one takes quite some time. I could accept to copy FF's default behaviour. Hi, I was trying to tell you that respond_with_model_values = 1 should be the default :-) and remove it altogether. I think that database round trip wouldn't hurt anyone. moritz ___ HTML-FormFu mailing list HTML-FormFu@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Re: [html-formfu] ExtJS::REST
Am Montag 11 Mai 2009 11:34:01 schrieb Moritz Onken: Am 11.05.2009 um 01:24 schrieb Mario Minati: OK I see. I think we can make this the default behaviour. This will cause a database roundtrip but I think it's the best way to make sure that the data we give back is the same as the data the user will get when he requests that item. You are right, but FF itself doesn't take db changes into account by default. And the db processing for more complex forms with repeatables and so one takes quite some time. I could accept to copy FF's default behaviour. Hi, I was trying to tell you that respond_with_model_values = 1 should be the default :-) and remove it altogether. I think that database round trip wouldn't hurt anyone. Doing so the test suite fails in user.t line 50. We expect PUT to return success == '1', but it sends 'true'. That is because we set it once as '\1' and the other time as '1' in ExtJS. Do you know if ExtJS makes a difference between those two values? Greets, Mario Minati ___ HTML-FormFu mailing list HTML-FormFu@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Re: [html-formfu] customize display of error messages
I know this is old, but here is the fastest way I have seen to
accomplish this. Just add some css code to handle the error_message
display. Ffor example:
form .error_message {
color: #CC !important;
display: block;
}
Carl Franks wrote:
2009/2/4 abhishek jain abhishek.netj...@gmail.com:
hello,
I wish to customize the error messages displayed after applying a
constraint,
I mean the template / display and not the text of error message.
Have you tried...
http://search.cpan.org/~cfranks/HTML-FormFu-0.03007/lib/HTML/FormFu/Manual/Cookbook.pod#ADVANCED_CUSTOMISATION
http://search.cpan.org/~cfranks/HTML-FormFu-0.03007/lib/HTML/FormFu.pm#ADVANCED_CUSTOMISATION
http://search.cpan.org/~cfranks/HTML-FormFu-0.03007/lib/HTML/FormFu/Element/_Field.pm#RENDERING
?
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Re: [html-formfu] Repeatable displays every row in table (bug?)
This fixed the problem, but it brings up another issue. From the
DBIx::Class::Resultset documentation:
| Note: find_or_new is probably not what you want when creating a
| new row in a table that uses primary keys supplied by the
| database. Passing in a primary key column with a value of undef
| will cause find to attempt to search for a row with a value of
| NULL.
That's exactly what's happening to me, and it causes the insert that
follows to fail.
I'm not sure where to go with this. Write a test that fails?
Somethings else?
Greg
Greg Coates wrote:
Yep, that solved it for me too.
Greg
Ascii King wrote:
I had this same problem back in this thread
http://lists.scsys.co.uk/pipermail/html-formfu/2009-March/001884.html
the answer was how I was calling the new record. I eeded to use
find_or_new to call a new record.
my $book = $c-model('DB::MyTable')-find_or_new({ id = $id });
Mario Minati wrote:
OK. Let me try again, then.
I have a form that is used to display invoices from a table called
'invoices'. It contains a Repeatable that is used to display the
individual lines for those invoices. These lines come from a table
called 'invoice_items'.
When the form is used on an existing record, all is well. However,
when
I use the form to create a new record, I have a problem. Instead of
the
Repeatable being blank, every row from the 'invoice_items' table is
displayed.
Greg
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Fwd: Re: [html-formfu] ExtJS::REST
Am Montag 11 Mai 2009 11:34:01 schrieb Moritz Onken: Am 11.05.2009 um 01:24 schrieb Mario Minati: OK I see. I think we can make this the default behaviour. This will cause a database roundtrip but I think it's the best way to make sure that the data we give back is the same as the data the user will get when he requests that item. You are right, but FF itself doesn't take db changes into account by default. And the db processing for more complex forms with repeatables and so one takes quite some time. I could accept to copy FF's default behaviour. Hi, I was trying to tell you that respond_with_model_values = 1 should be the default :-) and remove it altogether. I think that database round trip wouldn't hurt anyone. Doing so the test suite fails in user.t line 50. We expect PUT to return success == '1', but it sends 'true'. That is because we set it once as '\1' and the other time as '1' in ExtJS. Do you know if ExtJS makes a difference between those two values? I introspected some more and am thinking, that ExtJS would do fine if change FF::ExtJS to return \0 and \1 all the time. I prepared the necessary changes for tests and code. Shall I apply them? Greets, Mario Minati ___ HTML-FormFu mailing list HTML-FormFu@lists.scsys.co.uk http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
