Yes,
but let my first check in all my changes with tests, after that I'll come back
on that.
Greets,
Mario
Am Dienstag 30 Juni 2009 14:38:56 schrieb Moritz Onken:
> Am 13.05.2009 um 00:46 schrieb Mario Minati:
> > Am Dienstag 12 Mai 2009 12:56:39 schrieb Moritz Onken:
> >>> Doing so the test s
Am 13.05.2009 um 00:46 schrieb Mario Minati:
Am Dienstag 12 Mai 2009 12:56:39 schrieb Moritz Onken:
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 k
Am Dienstag 12 Mai 2009 12:56:39 schrieb Moritz Onken:
> > 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 di
Am Dienstag 12 Mai 2009 12:56:39 schrieb Moritz Onken:
> > 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 di
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 thinkin
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 t
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 t
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 a
I just uploaded a test for find_method.
Enjoy,
Mario Minati
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Am Sonntag 10 Mai 2009 18:57:08 schrieb Moritz Onken:
> >> respond_with_model_values is unnecessary because the -
> >> validation_response method returns the form data in the "data" key.
> >> Do you have any other reasons why we need this?
> >
> > The difference between calling the validation_respo
You were right, upgrading to Config::Any 0.17 (from 0.12) helped.
There is no according info in the Changes file of Config::Any about these
behaviour.
I updated the Makefile.PL to require Config::Any 0.17
Greets,
Mario Minati
Am Sonntag 10 Mai 2009 18:35:13 schrieb Moritz Onken:
> Hm yeah. It
I finished the skipend test (rev. 1498), which tests and demonstrates how to
use TT to render a form into a JS file.
Greets,
Mario Minati
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/htm
Fixed in 1497.
Greets,
Mario Minati
Am Sonntag 10 Mai 2009 18:34:08 schrieb Moritz Onken:
> I think we should.
> there is a $self->status_not_found. This is used in GET and DELETE
> already.
>
> Am 10.05.2009 um 20:24 schrieb Mario Minati:
> > Hi Moritz,
> >
> > I think PUT dies if $object is
respond_with_model_values is unnecessary because the -
validation_response method returns the form data in the "data" key.
Do you have any other reasons why we need this?
The difference between calling the validation_response or form_data
method is
in the call to '$self->model->default_values(
Hm yeah. It suddenly stopped working for me with the ->[0]. Could you
try to update Config::Any or whatever is responsible for that.
If it does not work for you we need to find a way that it works in any
case.
Am 10.05.2009 um 20:11 schrieb Mario Minati:
Hi Moritz,
in rev. 1479 you chan
I think we should.
there is a $self->status_not_found. This is used in GET and DELETE
already.
Am 10.05.2009 um 20:24 schrieb Mario Minati:
Hi Moritz,
I think PUT dies if $object is not defined, either because of $id is
not
existing or $id is undefined.
Shall we handle that?
Greets,
Hi Moritz,
I think PUT dies if $object is not defined, either because of $id is not
existing or $id is undefined.
Shall we handle that?
Greets,
Mario Minati
___
HTML-FormFu mailing list
HTML-FormFu@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin
Hi Moritz,
in rev. 1479 you changed in the 'object' mehod
-$config =
{ %{$self->_extjs_config->{model_config}},
%{$config->[0]->{$self->base_file}->{model_config} ||
{}} };
+$config =
{ %{$self->_extjs_config->{model_config}},
%{$config->{$self->base_file}->{model_config} ||
{}} };
Hi Moritz,
finally I have the timeto answer this email.
See my answers inline:
Am Sonntag 26 April 2009 17:54:31 schrieb Moritz Onken:
> Hi Mario,
>
> I had a quick look at your latest commit to ExtJS::REST. I think we
> should always call process_on_GET. The fact that I didn't call it was
> a bu
Hi Mario,
I had a quick look at your latest commit to ExtJS::REST. I think we
should always call process_on_GET. The fact that I didn't call it was
a bug. I removed the config option for that and hard coded process in
the GET method. I hope this is fine with you.
respond_with_model_values
20 matches
Mail list logo
