The situation:
//in some view I have:
<?php
echo $form->create(array("controller"=>"search", "action"=>"index"));
echo $form->input("Region.region_name");
echo $form->end();
?>
Straight forward, nothing to it... Now I want to post data via GET.
Cake doesn't have to worry about handling the 'posted' data because
that is delegated to another 3th party class that does the magic for
me.
But here comes the problem, the input name isn't "data[Region]
[region_name]" anymore, but "region_name". So apparently the form
helper notices the difference in the form method, and changes the way
the input names are printed. Wy? In this situation it is for example
impossible to create an array of checkboxes and post them as array
data because input names with "data[Option][1][option_title]" and
"data[Option][2][option_title]" etc are converted to "option_title"
only.
"Okay so don't be lazy and print the html yourself". Thats fine with
me to, but it would be great to have Cake support this problem. Or
does it and do I miss something?
If you are not using Cake to process the form why use FormHelper when
a good old hand-coded form in HTML works.
To me Helpers are great time savers when you are utilizing the
frameworks features: validations, auto read/write values to view,
posting to the next action in your controller. If your not using the
built features of cake for a form the helpers could slow down your
performance compared to hard-coded HTML that does not need processing.
Does anyone else agree with this opinion?
-Buddy
On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> The situation:
> //in some view I have:
> <?php
> echo $form->create(array("controller"=>"search", "action"=>"index"));
> echo $form->input("Region.region_name");
> echo $form->end();
> ?>
> Straight forward, nothing to it... Now I want to post data via GET.
> Cake doesn't have to worry about handling the 'posted' data because
> that is delegated to another 3th party class that does the magic for
> me.
> But here comes the problem, the input name isn't "data[Region]
> [region_name]" anymore, but "region_name". So apparently the form
> helper notices the difference in the form method, and changes the way
> the input names are printed. Wy? In this situation it is for example
> impossible to create an array of checkboxes and post them as array
> data because input names with "data[Option][1][option_title]" and
> "data[Option][2][option_title]" etc are converted to "option_title"
> only.
> "Okay so don't be lazy and print the html yourself". Thats fine with
> me to, but it would be great to have Cake support this problem. Or
> does it and do I miss something?
> If you are not using Cake to process the form why use FormHelper when
> a good old hand-coded form in HTML works.
> To me Helpers are great time savers when you are utilizing the
> frameworks features: validations, auto read/write values to view,
> posting to the next action in your controller. If your not using the
> built features of cake for a form the helpers could slow down your
> performance compared to hard-coded HTML that does not need processing.
> Does anyone else agree with this opinion?
Yup. But I'd go further.
The FormHelper is NOT there to 'help make forms'. It's there to help
make forms that correspond to the cakephp conventions, so that they
can be handled automagically by the rest of the framework.
If you're not doing this; if cake is not going to be intercepting,
validating and processing your data, then there's no point in using
the form helper.
What I love about the FormHelper is that you don't have to write much
code at all to get everything working. If you are, you're probably
doing something wrong.
I agree to. But it just doesn't make any sense to me that input names
are stripped to the column names of a table only when using GET. What
is the reason that cake handles get different from post?
I really want to stay as close as possible to the cake conventions so
I decided at first to use the formhelper. The great thing about the
form helper is that well, helps you build forms I think. But it is the
simple trivial stuff that the formhelper does for you independently
from the rest of the framework. For example, automaticly setting the
'posted' value of an input field, or showing validation errors.
But what if there will be an extension in the functionality later, and
cake should do something with the data? That would be another reason
to stick with the formhelper I think.
Anyways, getting my hands 'dirty' by writing some extra non cake-ish
isn't that big a deal but in my opinion not necessary :-)
On 16 mei, 14:56, mydesignbuddy <mydesignbu...@gmail.com> wrote:
> If you are not using Cake to process the form why use FormHelper when
> a good old hand-coded form in HTML works.
> To me Helpers are great time savers when you are utilizing the
> frameworks features: validations, auto read/write values to view,
> posting to the next action in your controller. If your not using the
> built features of cake for a form the helpers could slow down your
> performance compared to hard-coded HTML that does not need processing.
> Does anyone else agree with this opinion?
> -Buddy
> On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > Hi!
> > The situation:
> > //in some view I have:
> > <?php
> > echo $form->create(array("controller"=>"search", "action"=>"index"));
> > echo $form->input("Region.region_name");
> > echo $form->end();
> > ?>
> > Straight forward, nothing to it... Now I want to post data via GET.
> > Cake doesn't have to worry about handling the 'posted' data because
> > that is delegated to another 3th party class that does the magic for
> > me.
> > But here comes the problem, the input name isn't "data[Region]
> > [region_name]" anymore, but "region_name". So apparently the form
> > helper notices the difference in the form method, and changes the way
> > the input names are printed. Wy? In this situation it is for example
> > impossible to create an array of checkboxes and post them as array
> > data because input names with "data[Option][1][option_title]" and
> > "data[Option][2][option_title]" etc are converted to "option_title"
> > only.
> > "Okay so don't be lazy and print the html yourself". Thats fine with
> > me to, but it would be great to have Cake support this problem. Or
> > does it and do I miss something?
> But it just doesn't make any sense to me that input names
> are stripped to the column names of a table only when using GET. What
> is the reason that cake handles get different from post?
Surely the handling differs because arrays can't be passed as simply
via GET as they can via POST?
the data[x][y] naming system is used (at least in part) because this
is converted as an array in $_POST.
$_GET vars don't work that way in PHP (to my knowledge) so the naming
system is completely pointless for a GET request!
I'd love to be proved wrong on this one, it'd sure expand my
knwoledge :)
On May 16, 7:14 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> I agree to. But it just doesn't make any sense to me that input names
> are stripped to the column names of a table only when using GET. What
> is the reason that cake handles get different from post?
> I really want to stay as close as possible to the cake conventions so
> I decided at first to use the formhelper. The great thing about the
> form helper is that well, helps you build forms I think. But it is the
> simple trivial stuff that the formhelper does for you independently
> from the rest of the framework. For example, automaticly setting the
> 'posted' value of an input field, or showing validation errors.
> But what if there will be an extension in the functionality later, and
> cake should do something with the data? That would be another reason
> to stick with the formhelper I think.
> Anyways, getting my hands 'dirty' by writing some extra non cake-ish
> isn't that big a deal but in my opinion not necessary :-)
> On 16 mei, 14:56, mydesignbuddy <mydesignbu...@gmail.com> wrote:
> > If you are not using Cake to process the form why use FormHelper when
> > a good old hand-coded form in HTML works.
> > To me Helpers are great time savers when you are utilizing the
> > frameworks features: validations, auto read/write values to view,
> > posting to the next action in your controller. If your not using the
> > built features of cake for a form the helpers could slow down your
> > performance compared to hard-coded HTML that does not need processing.
> > Does anyone else agree with this opinion?
> > -Buddy
> > On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > > Straight forward, nothing to it... Now I want to post data via GET.
> > > Cake doesn't have to worry about handling the 'posted' data because
> > > that is delegated to another 3th party class that does the magic for
> > > me.
> > > But here comes the problem, the input name isn't "data[Region]
> > > [region_name]" anymore, but "region_name". So apparently the form
> > > helper notices the difference in the form method, and changes the way
> > > the input names are printed. Wy? In this situation it is for example
> > > impossible to create an array of checkboxes and post them as array
> > > data because input names with "data[Option][1][option_title]" and
> > > "data[Option][2][option_title]" etc are converted to "option_title"
> > > only.
> > > "Okay so don't be lazy and print the html yourself". Thats fine with
> > > me to, but it would be great to have Cake support this problem. Or
> > > does it and do I miss something?
> > But it just doesn't make any sense to me that input names
> > are stripped to the column names of a table only when using GET. What
> > is the reason that cake handles get different from post?
> Surely the handling differs because arrays can't be passed as simply
> via GET as they can via POST?
> the data[x][y] naming system is used (at least in part) because this
> is converted as an array in $_POST.
> $_GET vars don't work that way in PHP (to my knowledge) so the naming
> system is completely pointless for a GET request!
> I'd love to be proved wrong on this one, it'd sure expand my
> knwoledge :)
> On May 16, 7:14 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> > I agree to. But it just doesn't make any sense to me that input names
> > are stripped to the column names of a table only when using GET. What
> > is the reason that cake handles get different from post?
> > I really want to stay as close as possible to the cake conventions so
> > I decided at first to use the formhelper. The great thing about the
> > form helper is that well, helps you build forms I think. But it is the
> > simple trivial stuff that the formhelper does for you independently
> > from the rest of the framework. For example, automaticly setting the
> > 'posted' value of an input field, or showing validation errors.
> > But what if there will be an extension in the functionality later, and
> > cake should do something with the data? That would be another reason
> > to stick with the formhelper I think.
> > Anyways, getting my hands 'dirty' by writing some extra non cake-ish
> > isn't that big a deal but in my opinion not necessary :-)
> > On 16 mei, 14:56, mydesignbuddy <mydesignbu...@gmail.com> wrote:
> > > If you are not using Cake to process the form why use FormHelper when
> > > a good old hand-coded form in HTML works.
> > > To me Helpers are great time savers when you are utilizing the
> > > frameworks features: validations, auto read/write values to view,
> > > posting to the next action in your controller. If your not using the
> > > built features of cake for a form the helpers could slow down your
> > > performance compared to hard-coded HTML that does not need processing.
> > > Does anyone else agree with this opinion?
> > > -Buddy
> > > On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > Straight forward, nothing to it... Now I want to post data via GET.
> > > > Cake doesn't have to worry about handling the 'posted' data because
> > > > that is delegated to another 3th party class that does the magic for
> > > > me.
> > > > But here comes the problem, the input name isn't "data[Region]
> > > > [region_name]" anymore, but "region_name". So apparently the form
> > > > helper notices the difference in the form method, and changes the way
> > > > the input names are printed. Wy? In this situation it is for example
> > > > impossible to create an array of checkboxes and post them as array
> > > > data because input names with "data[Option][1][option_title]" and
> > > > "data[Option][2][option_title]" etc are converted to "option_title"
> > > > only.
> > > > "Okay so don't be lazy and print the html yourself". Thats fine with
> > > > me to, but it would be great to have Cake support this problem. Or
> > > > does it and do I miss something?
It is for a search engine :-) Build completly from scratch without
cakephp last year. The SearchController (which is a cake controller)
catches the GET request, includes the main search class and it wil
handle the search request. And it is a requirement that search results
can be bookmarked so the easy way to do this is using GET.
Hope this info helps :-)
On 17 mei, 00:56, Stephen Orr <mrtu...@gmail.com> wrote:
> I'm having trouble understanding why you'd want to use GET for
> something... what's the specific situation you're attempting?
> Steve
> On May 16, 7:48 pm, the_woodsman <elwood.ca...@gmail.com> wrote:
> > > But it just doesn't make any sense to me that input names
> > > are stripped to the column names of a table only when using GET. What
> > > is the reason that cake handles get different from post?
> > Surely the handling differs because arrays can't be passed as simply
> > via GET as they can via POST?
> > the data[x][y] naming system is used (at least in part) because this
> > is converted as an array in $_POST.
> > $_GET vars don't work that way in PHP (to my knowledge) so the naming
> > system is completely pointless for a GET request!
> > I'd love to be proved wrong on this one, it'd sure expand my
> > knwoledge :)
> > On May 16, 7:14 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> > > I agree to. But it just doesn't make any sense to me that input names
> > > are stripped to the column names of a table only when using GET. What
> > > is the reason that cake handles get different from post?
> > > I really want to stay as close as possible to the cake conventions so
> > > I decided at first to use the formhelper. The great thing about the
> > > form helper is that well, helps you build forms I think. But it is the
> > > simple trivial stuff that the formhelper does for you independently
> > > from the rest of the framework. For example, automaticly setting the
> > > 'posted' value of an input field, or showing validation errors.
> > > But what if there will be an extension in the functionality later, and
> > > cake should do something with the data? That would be another reason
> > > to stick with the formhelper I think.
> > > Anyways, getting my hands 'dirty' by writing some extra non cake-ish
> > > isn't that big a deal but in my opinion not necessary :-)
> > > On 16 mei, 14:56, mydesignbuddy <mydesignbu...@gmail.com> wrote:
> > > > If you are not using Cake to process the form why use FormHelper when
> > > > a good old hand-coded form in HTML works.
> > > > To me Helpers are great time savers when you are utilizing the
> > > > frameworks features: validations, auto read/write values to view,
> > > > posting to the next action in your controller. If your not using the
> > > > built features of cake for a form the helpers could slow down your
> > > > performance compared to hard-coded HTML that does not need processing.
> > > > Does anyone else agree with this opinion?
> > > > -Buddy
> > > > On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > > Straight forward, nothing to it... Now I want to post data via GET.
> > > > > Cake doesn't have to worry about handling the 'posted' data because
> > > > > that is delegated to another 3th party class that does the magic for
> > > > > me.
> > > > > But here comes the problem, the input name isn't "data[Region]
> > > > > [region_name]" anymore, but "region_name". So apparently the form
> > > > > helper notices the difference in the form method, and changes the way
> > > > > the input names are printed. Wy? In this situation it is for example
> > > > > impossible to create an array of checkboxes and post them as array
> > > > > data because input names with "data[Option][1][option_title]" and
> > > > > "data[Option][2][option_title]" etc are converted to "option_title"
> > > > > only.
> > > > > "Okay so don't be lazy and print the html yourself". Thats fine with
> > > > > me to, but it would be great to have Cake support this problem. Or
> > > > > does it and do I miss something?
What I did with my own Cake app was to POST the search request, but
then process that request into a series of named parameters and
redirect. That way, if a request came in via POST it was a new search,
if it came in with named params it was an existing one - and the
search didn't happen until the second stage.
You're getting more or less the same result by just sending a GET
request, but my way was just a little more predictable - and works
well I think (check out http://www.bcfw.co.uk to see it in action).
Steve
On May 17, 7:39 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> It is for a search engine :-) Build completly from scratch without
> cakephp last year. The SearchController (which is a cake controller)
> catches the GET request, includes the main search class and it wil
> handle the search request. And it is a requirement that search results
> can be bookmarked so the easy way to do this is using GET.
> Hope this info helps :-)
> On 17 mei, 00:56, Stephen Orr <mrtu...@gmail.com> wrote:
> > I'm having trouble understanding why you'd want to use GET for
> > something... what's the specific situation you're attempting?
> > Steve
> > On May 16, 7:48 pm, the_woodsman <elwood.ca...@gmail.com> wrote:
> > > > But it just doesn't make any sense to me that input names
> > > > are stripped to the column names of a table only when using GET. What
> > > > is the reason that cake handles get different from post?
> > > Surely the handling differs because arrays can't be passed as simply
> > > via GET as they can via POST?
> > > the data[x][y] naming system is used (at least in part) because this
> > > is converted as an array in $_POST.
> > > $_GET vars don't work that way in PHP (to my knowledge) so the naming
> > > system is completely pointless for a GET request!
> > > I'd love to be proved wrong on this one, it'd sure expand my
> > > knwoledge :)
> > > On May 16, 7:14 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > I agree to. But it just doesn't make any sense to me that input names
> > > > are stripped to the column names of a table only when using GET. What
> > > > is the reason that cake handles get different from post?
> > > > I really want to stay as close as possible to the cake conventions so
> > > > I decided at first to use the formhelper. The great thing about the
> > > > form helper is that well, helps you build forms I think. But it is the
> > > > simple trivial stuff that the formhelper does for you independently
> > > > from the rest of the framework. For example, automaticly setting the
> > > > 'posted' value of an input field, or showing validation errors.
> > > > But what if there will be an extension in the functionality later, and
> > > > cake should do something with the data? That would be another reason
> > > > to stick with the formhelper I think.
> > > > Anyways, getting my hands 'dirty' by writing some extra non cake-ish
> > > > isn't that big a deal but in my opinion not necessary :-)
> > > > > If you are not using Cake to process the form why use FormHelper when
> > > > > a good old hand-coded form in HTML works.
> > > > > To me Helpers are great time savers when you are utilizing the
> > > > > frameworks features: validations, auto read/write values to view,
> > > > > posting to the next action in your controller. If your not using the
> > > > > built features of cake for a form the helpers could slow down your
> > > > > performance compared to hard-coded HTML that does not need processing.
> > > > > Does anyone else agree with this opinion?
> > > > > -Buddy
> > > > > On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > > > Straight forward, nothing to it... Now I want to post data via GET.
> > > > > > Cake doesn't have to worry about handling the 'posted' data because
> > > > > > that is delegated to another 3th party class that does the magic for
> > > > > > me.
> > > > > > But here comes the problem, the input name isn't "data[Region]
> > > > > > [region_name]" anymore, but "region_name". So apparently the form
> > > > > > helper notices the difference in the form method, and changes the way
> > > > > > the input names are printed. Wy? In this situation it is for example
> > > > > > impossible to create an array of checkboxes and post them as array
> > > > > > data because input names with "data[Option][1][option_title]" and
> > > > > > "data[Option][2][option_title]" etc are converted to "option_title"
> > > > > > only.
> > > > > > "Okay so don't be lazy and print the html yourself". Thats fine with
> > > > > > me to, but it would be great to have Cake support this problem. Or
> > > > > > does it and do I miss something?
> What I did with my own Cake app was to POST the search request, but
> then process that request into a series of named parameters and
> redirect. That way, if a request came in via POST it was a new search,
> if it came in with named params it was an existing one - and the
> search didn't happen until the second stage.
> You're getting more or less the same result by just sending a GET
> request, but my way was just a little more predictable - and works
> well I think (check outhttp://www.bcfw.co.ukto see it in action).
> Steve
> On May 17, 7:39 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> > It is for a search engine :-) Build completly from scratch without
> > cakephp last year. The SearchController (which is a cake controller)
> > catches the GET request, includes the main search class and it wil
> > handle the search request. And it is a requirement that search results
> > can be bookmarked so the easy way to do this is using GET.
> > Hope this info helps :-)
> > On 17 mei, 00:56, Stephen Orr <mrtu...@gmail.com> wrote:
> > > I'm having trouble understanding why you'd want to use GET for
> > > something... what's the specific situation you're attempting?
> > > Steve
> > > On May 16, 7:48 pm, the_woodsman <elwood.ca...@gmail.com> wrote:
> > > > > But it just doesn't make any sense to me that input names
> > > > > are stripped to the column names of a table only when using GET. What
> > > > > is the reason that cake handles get different from post?
> > > > Surely the handling differs because arrays can't be passed as simply
> > > > via GET as they can via POST?
> > > > the data[x][y] naming system is used (at least in part) because this
> > > > is converted as an array in $_POST.
> > > > $_GET vars don't work that way in PHP (to my knowledge) so the naming
> > > > system is completely pointless for a GET request!
> > > > I'd love to be proved wrong on this one, it'd sure expand my
> > > > knwoledge :)
> > > > On May 16, 7:14 pm, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > > I agree to. But it just doesn't make any sense to me that input names
> > > > > are stripped to the column names of a table only when using GET. What
> > > > > is the reason that cake handles get different from post?
> > > > > I really want to stay as close as possible to the cake conventions so
> > > > > I decided at first to use the formhelper. The great thing about the
> > > > > form helper is that well, helps you build forms I think. But it is the
> > > > > simple trivial stuff that the formhelper does for you independently
> > > > > from the rest of the framework. For example, automaticly setting the
> > > > > 'posted' value of an input field, or showing validation errors.
> > > > > But what if there will be an extension in the functionality later, and
> > > > > cake should do something with the data? That would be another reason
> > > > > to stick with the formhelper I think.
> > > > > Anyways, getting my hands 'dirty' by writing some extra non cake-ish
> > > > > isn't that big a deal but in my opinion not necessary :-)
> > > > > > If you are not using Cake to process the form why use FormHelper when
> > > > > > a good old hand-coded form in HTML works.
> > > > > > To me Helpers are great time savers when you are utilizing the
> > > > > > frameworks features: validations, auto read/write values to view,
> > > > > > posting to the next action in your controller. If your not using the
> > > > > > built features of cake for a form the helpers could slow down your
> > > > > > performance compared to hard-coded HTML that does not need processing.
> > > > > > Does anyone else agree with this opinion?
> > > > > > -Buddy
> > > > > > On May 15, 4:52 am, Marcelius <mraaijmak...@gmail.com> wrote:
> > > > > > > Straight forward, nothing to it... Now I want to post data via GET.
> > > > > > > Cake doesn't have to worry about handling the 'posted' data because
> > > > > > > that is delegated to another 3th party class that does the magic for
> > > > > > > me.
> > > > > > > But here comes the problem, the input name isn't "data[Region]
> > > > > > > [region_name]" anymore, but "region_name". So apparently the form
> > > > > > > helper notices the difference in the form method, and changes the way
> > > > > > > the input names are printed. Wy? In this situation it is for example
> > > > > > > impossible to create an array of checkboxes and post them as array
> > > > > > > data because input names with "data[Option][1][option_title]" and
> > > > > > > "data[Option][2][option_title]" etc are converted to "option_title"
> > > > > > > only.
> > > > > > > "Okay so don't be lazy and print the html yourself". Thats fine with
> > > > > > > me to, but it would be great to have Cake support this problem. Or
> > > > > > > does it and do I miss something?
|
