Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
Thank you for the explanations, guys. I have no problems accepting a solution that seems to be suboptimal in my opinion when can comprehend your motivations behind it. :-) On Sat, Nov 13, 2010 at 5:36 PM, mark_story wrote: > One of the main reasons it was changed to a view property, was that > people had the propensity to make view variables that shared the name > of their helpers. Bad things ensued. There were frequent enough > issues that it was changed. Unlike PHP and CakePHP rails benefits > from ruby magic, in the form of mixins. Since PHP has no mixins, we > can't really do the same things as rails can. Moving helpers to view > properties, has also enabled runtime loading of helpers and lazy > loading of helpers for 2.0, which was another motivation to change > things. > > As for a decision log, its mostly in the form of tickets on > lighthouse, as well as some discussion on the mailing list, and wiki > pages that existed while 1.3 was being developed. > > -Mark > > On Nov 12, 8:18 am, Joshua Muheim wrote: >> I'd really like to know why it has switched to $this->Html. Is there a >> decision log or something for CakePHP? >> >> Coming from the RoR world (which is far more widespread in the >> webworld than CakePHP, I guess) I like things as simple as anyhow >> possible, even if you have to stick to some conventions for its sake. >> I haven't worked with RoR since 2 years or so, so maybe things have >> changed now, but up then as far as I remember things like helper >> methods had been mixed right into the view *without* anything like a >> $helper method or so. >> >> E.g. a helper Bla with methods abc and xyz were accessible in the view >> directly by calling abc and xyz, so you had to see for yourself that >> no collisions appeared (and if one did, I guess you would still have >> been able to distinguish your helpers by prepending the helper's name, >> e.g. Bla.abc or Foo.abc). >> >> So RoR went the way that's the most convenient to use, and by having a >> good test battery in the background conflicts like the mentioned above >> were located and fixed easily while still having all the convenience >> in those spots that didn't have collisions (which are in most cases >> many more than the ones that do). >> >> Well, just writing some thoughts down here, no intention to blame >> CakePHP or something... I'm just curious about some stuff... ;-) >> >> >> >> >> >> >> >> On Fri, Nov 12, 2010 at 1:41 PM, euromark wrote: >> > actually its the other way around >> > it used to be $html and NOW is $this->Html (cake >=1.3) >> > and yes, there are plenty reasons why this is now a view object (and >> > not just an object variable) >> >> > it is a bad idea to want to go back to the old syntax >> >> > and your argument is bad: For the sake of simplicity $this->Html makes >> > more sense (no collisions in the view anymore) >> >> > hope that clears things up >> >> > On 12 Nov., 11:42, psybear83 wrote: >> >> Hi everybody >> >> >> For the sake of simplicity I'd like to make my helpers available in my >> >> views not as $this->Helper but as $helper using the set(...) method in >> >> the controller. >> >> >> Is there any reason why this could be a bad idea? Or is there already >> >> an option to tell CakePHP to make the helpers available this way? >> >> >> Thanks for help >> >> Josh >> >> > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others >> > with their CakePHP related questions. >> >> > You received this message because you are subscribed to the Google Groups >> > "CakePHP" group. >> > To post to this group, send email to cake-php@googlegroups.com >> > To unsubscribe from this group, send email to >> > cake-php+unsubscr...@googlegroups.com For more options, visit this group >> > athttp://groups.google.com/group/cake-php?hl=en > > Check out the new CakePHP Questions site http://cakeqs.org and help others > with their CakePHP related questions. > > You received this message because you are subscribed to the Google Groups > "CakePHP" group. > To post to this group, send email to cake-php@googlegroups.com > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group at > http://groups.google.com/group/cake-php?hl=en > Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
One of the main reasons it was changed to a view property, was that people had the propensity to make view variables that shared the name of their helpers. Bad things ensued. There were frequent enough issues that it was changed. Unlike PHP and CakePHP rails benefits from ruby magic, in the form of mixins. Since PHP has no mixins, we can't really do the same things as rails can. Moving helpers to view properties, has also enabled runtime loading of helpers and lazy loading of helpers for 2.0, which was another motivation to change things. As for a decision log, its mostly in the form of tickets on lighthouse, as well as some discussion on the mailing list, and wiki pages that existed while 1.3 was being developed. -Mark On Nov 12, 8:18 am, Joshua Muheim wrote: > I'd really like to know why it has switched to $this->Html. Is there a > decision log or something for CakePHP? > > Coming from the RoR world (which is far more widespread in the > webworld than CakePHP, I guess) I like things as simple as anyhow > possible, even if you have to stick to some conventions for its sake. > I haven't worked with RoR since 2 years or so, so maybe things have > changed now, but up then as far as I remember things like helper > methods had been mixed right into the view *without* anything like a > $helper method or so. > > E.g. a helper Bla with methods abc and xyz were accessible in the view > directly by calling abc and xyz, so you had to see for yourself that > no collisions appeared (and if one did, I guess you would still have > been able to distinguish your helpers by prepending the helper's name, > e.g. Bla.abc or Foo.abc). > > So RoR went the way that's the most convenient to use, and by having a > good test battery in the background conflicts like the mentioned above > were located and fixed easily while still having all the convenience > in those spots that didn't have collisions (which are in most cases > many more than the ones that do). > > Well, just writing some thoughts down here, no intention to blame > CakePHP or something... I'm just curious about some stuff... ;-) > > > > > > > > On Fri, Nov 12, 2010 at 1:41 PM, euromark wrote: > > actually its the other way around > > it used to be $html and NOW is $this->Html (cake >=1.3) > > and yes, there are plenty reasons why this is now a view object (and > > not just an object variable) > > > it is a bad idea to want to go back to the old syntax > > > and your argument is bad: For the sake of simplicity $this->Html makes > > more sense (no collisions in the view anymore) > > > hope that clears things up > > > On 12 Nov., 11:42, psybear83 wrote: > >> Hi everybody > > >> For the sake of simplicity I'd like to make my helpers available in my > >> views not as $this->Helper but as $helper using the set(...) method in > >> the controller. > > >> Is there any reason why this could be a bad idea? Or is there already > >> an option to tell CakePHP to make the helpers available this way? > > >> Thanks for help > >> Josh > > > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > > with their CakePHP related questions. > > > You received this message because you are subscribed to the Google Groups > > "CakePHP" group. > > To post to this group, send email to cake-php@googlegroups.com > > To unsubscribe from this group, send email to > > cake-php+unsubscr...@googlegroups.com For more options, visit this group > > athttp://groups.google.com/group/cake-php?hl=en Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
It was mainly so that user variables don't overwrite helper variables. I ran into this problem a few times during my 1.2 days. If it really bothers you that much. $f = $this->Form; On Nov 12, 5:25 am, Joshua Muheim wrote: > I don't see the big deal, too. I just wondered whether there's a > knockout argument for doing it the CakePHP-way. But I guess I will > stick to the CakePHP-way now for some time and see later if I still > want to change it... :-) > > On Fri, Nov 12, 2010 at 2:23 PM, Jeremy Burns | Class Outfit > > wrote: > > I like the way Cake does it, regardless of what else others do. I can > > imagine that if you had a helper function called "display" and then you > > added another helper that had a function with the same name you *could* > > isolate and rectify the clashes, but I'd rather avoid that extra work in > > the first place by just pre-pending the helper name in the first place. I > > don't see the big deal. > > > Jeremy Burns > > Class Outfit > > > jeremybu...@classoutfit.com > >http://www.classoutfit.com > > > On 12 Nov 2010, at 08:18, Joshua Muheim wrote: > > >> I'd really like to know why it has switched to $this->Html. Is there a > >> decision log or something for CakePHP? > > >> Coming from the RoR world (which is far more widespread in the > >> webworld than CakePHP, I guess) I like things as simple as anyhow > >> possible, even if you have to stick to some conventions for its sake. > >> I haven't worked with RoR since 2 years or so, so maybe things have > >> changed now, but up then as far as I remember things like helper > >> methods had been mixed right into the view *without* anything like a > >> $helper method or so. > > >> E.g. a helper Bla with methods abc and xyz were accessible in the view > >> directly by calling abc and xyz, so you had to see for yourself that > >> no collisions appeared (and if one did, I guess you would still have > >> been able to distinguish your helpers by prepending the helper's name, > >> e.g. Bla.abc or Foo.abc). > > >> So RoR went the way that's the most convenient to use, and by having a > >> good test battery in the background conflicts like the mentioned above > >> were located and fixed easily while still having all the convenience > >> in those spots that didn't have collisions (which are in most cases > >> many more than the ones that do). > > >> Well, just writing some thoughts down here, no intention to blame > >> CakePHP or something... I'm just curious about some stuff... ;-) > > >> On Fri, Nov 12, 2010 at 1:41 PM, euromark > >> wrote: > >>> actually its the other way around > >>> it used to be $html and NOW is $this->Html (cake >=1.3) > >>> and yes, there are plenty reasons why this is now a view object (and > >>> not just an object variable) > > >>> it is a bad idea to want to go back to the old syntax > > >>> and your argument is bad: For the sake of simplicity $this->Html makes > >>> more sense (no collisions in the view anymore) > > >>> hope that clears things up > > >>> On 12 Nov., 11:42, psybear83 wrote: > Hi everybody > > For the sake of simplicity I'd like to make my helpers available in my > views not as $this->Helper but as $helper using the set(...) method in > the controller. > > Is there any reason why this could be a bad idea? Or is there already > an option to tell CakePHP to make the helpers available this way? > > Thanks for help > Josh > > >>> Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > >>> with their CakePHP related questions. > > >>> You received this message because you are subscribed to the Google Groups > >>> "CakePHP" group. > >>> To post to this group, send email to cake-php@googlegroups.com > >>> To unsubscribe from this group, send email to > >>> cake-php+unsubscr...@googlegroups.com For more options, visit this group > >>> athttp://groups.google.com/group/cake-php?hl=en > > >> Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > >> with their CakePHP related questions. > > >> You received this message because you are subscribed to the Google Groups > >> "CakePHP" group. > >> To post to this group, send email to cake-php@googlegroups.com > >> To unsubscribe from this group, send email to > >> cake-php+unsubscr...@googlegroups.com For more options, visit this group > >> athttp://groups.google.com/group/cake-php?hl=en > > > Check out the new CakePHP Questions sitehttp://cakeqs.organd help others > > with their CakePHP related questions. > > > You received this message because you are subscribed to the Google Groups > > "CakePHP" group. > > To post to this group, send email to cake-php@googlegroups.com > > To unsubscribe from this group, send email to > > cake-php+unsubscr...@googlegroups.com For more options, visit this group > > athttp://groups.google.com/group/cake-php?hl=en Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You re
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
I don't see the big deal, too. I just wondered whether there's a knockout argument for doing it the CakePHP-way. But I guess I will stick to the CakePHP-way now for some time and see later if I still want to change it... :-) On Fri, Nov 12, 2010 at 2:23 PM, Jeremy Burns | Class Outfit wrote: > I like the way Cake does it, regardless of what else others do. I can imagine > that if you had a helper function called "display" and then you added another > helper that had a function with the same name you *could* isolate and rectify > the clashes, but I'd rather avoid that extra work in the first place by just > pre-pending the helper name in the first place. I don't see the big deal. > > Jeremy Burns > Class Outfit > > jeremybu...@classoutfit.com > http://www.classoutfit.com > > On 12 Nov 2010, at 08:18, Joshua Muheim wrote: > >> I'd really like to know why it has switched to $this->Html. Is there a >> decision log or something for CakePHP? >> >> Coming from the RoR world (which is far more widespread in the >> webworld than CakePHP, I guess) I like things as simple as anyhow >> possible, even if you have to stick to some conventions for its sake. >> I haven't worked with RoR since 2 years or so, so maybe things have >> changed now, but up then as far as I remember things like helper >> methods had been mixed right into the view *without* anything like a >> $helper method or so. >> >> E.g. a helper Bla with methods abc and xyz were accessible in the view >> directly by calling abc and xyz, so you had to see for yourself that >> no collisions appeared (and if one did, I guess you would still have >> been able to distinguish your helpers by prepending the helper's name, >> e.g. Bla.abc or Foo.abc). >> >> So RoR went the way that's the most convenient to use, and by having a >> good test battery in the background conflicts like the mentioned above >> were located and fixed easily while still having all the convenience >> in those spots that didn't have collisions (which are in most cases >> many more than the ones that do). >> >> Well, just writing some thoughts down here, no intention to blame >> CakePHP or something... I'm just curious about some stuff... ;-) >> >> On Fri, Nov 12, 2010 at 1:41 PM, euromark wrote: >>> actually its the other way around >>> it used to be $html and NOW is $this->Html (cake >=1.3) >>> and yes, there are plenty reasons why this is now a view object (and >>> not just an object variable) >>> >>> it is a bad idea to want to go back to the old syntax >>> >>> and your argument is bad: For the sake of simplicity $this->Html makes >>> more sense (no collisions in the view anymore) >>> >>> hope that clears things up >>> >>> On 12 Nov., 11:42, psybear83 wrote: Hi everybody For the sake of simplicity I'd like to make my helpers available in my views not as $this->Helper but as $helper using the set(...) method in the controller. Is there any reason why this could be a bad idea? Or is there already an option to tell CakePHP to make the helpers available this way? Thanks for help Josh >>> >>> Check out the new CakePHP Questions site http://cakeqs.org and help others >>> with their CakePHP related questions. >>> >>> You received this message because you are subscribed to the Google Groups >>> "CakePHP" group. >>> To post to this group, send email to cake-php@googlegroups.com >>> To unsubscribe from this group, send email to >>> cake-php+unsubscr...@googlegroups.com For more options, visit this group at >>> http://groups.google.com/group/cake-php?hl=en >>> >> >> Check out the new CakePHP Questions site http://cakeqs.org and help others >> with their CakePHP related questions. >> >> You received this message because you are subscribed to the Google Groups >> "CakePHP" group. >> To post to this group, send email to cake-php@googlegroups.com >> To unsubscribe from this group, send email to >> cake-php+unsubscr...@googlegroups.com For more options, visit this group at >> http://groups.google.com/group/cake-php?hl=en > > Check out the new CakePHP Questions site http://cakeqs.org and help others > with their CakePHP related questions. > > You received this message because you are subscribed to the Google Groups > "CakePHP" group. > To post to this group, send email to cake-php@googlegroups.com > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group at > http://groups.google.com/group/cake-php?hl=en > Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
I like the way Cake does it, regardless of what else others do. I can imagine that if you had a helper function called "display" and then you added another helper that had a function with the same name you *could* isolate and rectify the clashes, but I'd rather avoid that extra work in the first place by just pre-pending the helper name in the first place. I don't see the big deal. Jeremy Burns Class Outfit jeremybu...@classoutfit.com http://www.classoutfit.com On 12 Nov 2010, at 08:18, Joshua Muheim wrote: > I'd really like to know why it has switched to $this->Html. Is there a > decision log or something for CakePHP? > > Coming from the RoR world (which is far more widespread in the > webworld than CakePHP, I guess) I like things as simple as anyhow > possible, even if you have to stick to some conventions for its sake. > I haven't worked with RoR since 2 years or so, so maybe things have > changed now, but up then as far as I remember things like helper > methods had been mixed right into the view *without* anything like a > $helper method or so. > > E.g. a helper Bla with methods abc and xyz were accessible in the view > directly by calling abc and xyz, so you had to see for yourself that > no collisions appeared (and if one did, I guess you would still have > been able to distinguish your helpers by prepending the helper's name, > e.g. Bla.abc or Foo.abc). > > So RoR went the way that's the most convenient to use, and by having a > good test battery in the background conflicts like the mentioned above > were located and fixed easily while still having all the convenience > in those spots that didn't have collisions (which are in most cases > many more than the ones that do). > > Well, just writing some thoughts down here, no intention to blame > CakePHP or something... I'm just curious about some stuff... ;-) > > On Fri, Nov 12, 2010 at 1:41 PM, euromark wrote: >> actually its the other way around >> it used to be $html and NOW is $this->Html (cake >=1.3) >> and yes, there are plenty reasons why this is now a view object (and >> not just an object variable) >> >> it is a bad idea to want to go back to the old syntax >> >> and your argument is bad: For the sake of simplicity $this->Html makes >> more sense (no collisions in the view anymore) >> >> hope that clears things up >> >> On 12 Nov., 11:42, psybear83 wrote: >>> Hi everybody >>> >>> For the sake of simplicity I'd like to make my helpers available in my >>> views not as $this->Helper but as $helper using the set(...) method in >>> the controller. >>> >>> Is there any reason why this could be a bad idea? Or is there already >>> an option to tell CakePHP to make the helpers available this way? >>> >>> Thanks for help >>> Josh >> >> Check out the new CakePHP Questions site http://cakeqs.org and help others >> with their CakePHP related questions. >> >> You received this message because you are subscribed to the Google Groups >> "CakePHP" group. >> To post to this group, send email to cake-php@googlegroups.com >> To unsubscribe from this group, send email to >> cake-php+unsubscr...@googlegroups.com For more options, visit this group at >> http://groups.google.com/group/cake-php?hl=en >> > > Check out the new CakePHP Questions site http://cakeqs.org and help others > with their CakePHP related questions. > > You received this message because you are subscribed to the Google Groups > "CakePHP" group. > To post to this group, send email to cake-php@googlegroups.com > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group at > http://groups.google.com/group/cake-php?hl=en Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
I'd really like to know why it has switched to $this->Html. Is there a decision log or something for CakePHP? Coming from the RoR world (which is far more widespread in the webworld than CakePHP, I guess) I like things as simple as anyhow possible, even if you have to stick to some conventions for its sake. I haven't worked with RoR since 2 years or so, so maybe things have changed now, but up then as far as I remember things like helper methods had been mixed right into the view *without* anything like a $helper method or so. E.g. a helper Bla with methods abc and xyz were accessible in the view directly by calling abc and xyz, so you had to see for yourself that no collisions appeared (and if one did, I guess you would still have been able to distinguish your helpers by prepending the helper's name, e.g. Bla.abc or Foo.abc). So RoR went the way that's the most convenient to use, and by having a good test battery in the background conflicts like the mentioned above were located and fixed easily while still having all the convenience in those spots that didn't have collisions (which are in most cases many more than the ones that do). Well, just writing some thoughts down here, no intention to blame CakePHP or something... I'm just curious about some stuff... ;-) On Fri, Nov 12, 2010 at 1:41 PM, euromark wrote: > actually its the other way around > it used to be $html and NOW is $this->Html (cake >=1.3) > and yes, there are plenty reasons why this is now a view object (and > not just an object variable) > > it is a bad idea to want to go back to the old syntax > > and your argument is bad: For the sake of simplicity $this->Html makes > more sense (no collisions in the view anymore) > > hope that clears things up > > On 12 Nov., 11:42, psybear83 wrote: >> Hi everybody >> >> For the sake of simplicity I'd like to make my helpers available in my >> views not as $this->Helper but as $helper using the set(...) method in >> the controller. >> >> Is there any reason why this could be a bad idea? Or is there already >> an option to tell CakePHP to make the helpers available this way? >> >> Thanks for help >> Josh > > Check out the new CakePHP Questions site http://cakeqs.org and help others > with their CakePHP related questions. > > You received this message because you are subscribed to the Google Groups > "CakePHP" group. > To post to this group, send email to cake-php@googlegroups.com > To unsubscribe from this group, send email to > cake-php+unsubscr...@googlegroups.com For more options, visit this group at > http://groups.google.com/group/cake-php?hl=en > Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Re: Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
actually its the other way around it used to be $html and NOW is $this->Html (cake >=1.3) and yes, there are plenty reasons why this is now a view object (and not just an object variable) it is a bad idea to want to go back to the old syntax and your argument is bad: For the sake of simplicity $this->Html makes more sense (no collisions in the view anymore) hope that clears things up On 12 Nov., 11:42, psybear83 wrote: > Hi everybody > > For the sake of simplicity I'd like to make my helpers available in my > views not as $this->Helper but as $helper using the set(...) method in > the controller. > > Is there any reason why this could be a bad idea? Or is there already > an option to tell CakePHP to make the helpers available this way? > > Thanks for help > Josh Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
Is there a reason why I shouln't make $this->Html available in views as $html? --psybear
Hi everybody For the sake of simplicity I'd like to make my helpers available in my views not as $this->Helper but as $helper using the set(...) method in the controller. Is there any reason why this could be a bad idea? Or is there already an option to tell CakePHP to make the helpers available this way? Thanks for help Josh Check out the new CakePHP Questions site http://cakeqs.org and help others with their CakePHP related questions. You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com To unsubscribe from this group, send email to cake-php+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
