I think that is where the problem arises... you don't explicity state the model as a parameter when calling a behaviours function. The whole point is so that you can attach behaviours to models and therefore allow any model to utilse the functionality of a behaviour by just calling it from the model as if the function belongs to the model.
you have to specify the model ref. parameter when coding the behaviour function, but when using it (calling it from a model) cake magically dispathes the call with the model parameter inserted and the user defined parameters shifted along 1 position each. It seems to be this part that kills the refential nature of the parameters I have been setting in the function call - it makes sense if the behavioues were only intended to implement the defined model callbacks as these already have well defined signatures that you can't change, but the book states that you can define functions so that models can utilise any behaviours function that is attached to it. Unless I'm missing something, it is a bit of a waste of time. Allow callback implementations in behaviours by all means, but if there are undocumented restrictions as to what you can do, then either document the restirctions, or restric the whole behaviour design to only allow callback implementations. sorry for the bad typing, got to sleep. On Nov 22, 5:46 pm, John Andersen <[email protected]> wrote: > I have a question with regard to your code example - you wrote: > > [code] > function behaviourFunction(&$i_Model, &$o_SomeDataOut) > { > $o_SomeDataOut = 'Data From behaviourFunction'; > return true;} > > [/code] > > and your usage of the above behaviour method: > > [code] > $someData = 'pre behaciour function call'; > MyModel->behaviourFunction($someData); > debug($someData); > [/code] > > Is the above a typo? Or did you forget that the method takes two > parameters? > Enjoy, > John > > On 22 Nov., 10:10, Tonu Tusk <[email protected]> wrote: > > > OK, so another couple of wasted days refactoring things that could > > have been avoided if behaviours had been properly documented. > > > sometimes cake sucks - it is a pretty big obstruction to be aiming for > > a fat model implementation, but also use a preferred reusability route > > of plugins and behaviours > > if the main way to implement reusable, cross-app, cross-plugin code is > > restricted like this. > > > It's hard to stick with the framework - as much as I appreciate I am > > not contributing code directly to the project, spotting bugs (if it's > > not documented, I consider it a bug) > > and reporting these to the dev team is still contribution. > > > When trying to search for solutions to this problem I stumbled upon a > > ticket someone had raised in trac a couple of years ago. result: dev > > rejected ticket with no further investigation into the "problem". > > > I have submitted tickets regarding the inadequacies of Acl / Auth if > > it is being used as the de-faco core mechanism, but it seems people > > are more worried about devving what > > JS lib to use, or mechanism to utilise a third party JS mech (or many > > other things) than actually fix core broken code. > > [snip] 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en
