Unknown column 'email' in 'field list'

[eluser]TheFuzzy0ne[/eluser]
[quote author="stoefln" date="1236013855"]i think this should be done in CI by default- cause emails shouldnt be sent out of models anyway. CI should support a good programming-style IMO.[/quote]

I disagree. Often it's necessary to access libraries from models. The Email library is just one example that perhaps you may not need to use from within a model, but I see no reason why Config, Encryption, FTP, Language, Loader,pagination, URI (to name but a few), as well as any libraries I create should be available to the model by default. Rather than tell you would you "should" have access to, CodeIgniter gives you access to all of it. If you don't need access to all of it, you can override the functionality. I'm quite sure that if we voted on the subject, the majority would disagree with you. Perhaps it's worth starting a poll.

[eluser]stoefln[/eluser]
[quote author="TheFuzzy0ne" date="1236018974"][quote author="stoefln" date="1236013855"][quote author="TheFuzzy0ne" date="1236013505"]i think this should be done in CI by default- cause emails shouldnt be sent out of models anyway. CI should support a good programming-style IMO.[/quote]

I disagree. Often it's necessary to access libraries from models. The Email library is just one example that perhaps you may not need to use from within a model, but I see no reason why Config, Encryption, FTP, Language, Loader,pagination, URI (to name but a few), as well as any libraries I create should not be available to the model by default. Rather than tell you would you "should" have access to, CodeIgniter gives you access to all of it. If you don't need access to all of it, you can override the functionality. I'm quite sure that if we voted on the subject, the majority would disagree with you. Perhaps it's worth starting a poll. [/quote]

If you asked me some days ago i wouldnt have argued, but now i see things kind of different. you are right that its convenient to have libraries available everywhere, but not only libraries are made available everywhere- every member of a controller is accessible through models. i dont see why i cant assign my own variables in my controller which should only accessible from within that controller. (without having to stick to _conventions)

[eluser]xwero[/eluser]
I agree that the scoping of objects/variables/arrays could use a fine tuning. A possible solution would be to namespace the things that come from the controller, then you can call them like this

Code:

$value = $this->CI->uri->segment(3);

then there will be no collisions with internal variables/objects.

I think that not attaching things from the controller will lead to a lot of configuration for the bigger sites/applications.

[eluser]TheFuzzy0ne[/eluser]
I agree, and had thought of that, although I was trying to think of an alternative to storing variables native to the model in their own array. Having a $CI variable in the model never occurred to me, but now it's so obvious. Great suggestion. I could live with doing things like that, although it would be hard to implement into the core without messing with existing applications when people upgrade.

[eluser]stoefln[/eluser]
the way i will handle it is, to set an config-array with libraries which should be made available in models. nothing else.

[eluser]TheFuzzy0ne[/eluser]
Sounds very restrictive to me. Especially if you want to add more libraries, such as your own custom libraries; you'd have to keep adding them to the configuration file.

Personally, I think namespaces are the answer. That way, there's really only a single variable name you can't use within your model. It prevents name clashes (which is the problem you were experiencing), and allows you to use any loaded libraries you want if you choose to.

[eluser]stoefln[/eluser]
[quote author="TheFuzzy0ne" date="1236030028"]Sounds very restrictive to me. Especially if you want to add more libraries, such as your own custom libraries; you'd have to keep adding them to the configuration file.

Personally, I think namespaces are the answer. That way, there's really only a single variable name you can't use within your model. It prevents name clashes (which is the problem you were experiencing), and allows you to use any loaded libraries you want if you choose to.[/quote]

would be a good solution, but

$value = $this->CI->uri->segment(3);

is more to write than

$value = $this->uri->segment(3);

and, another thing, which maybe should not go into architectural considerations of CI, but what would bother me is, that netbeans' code completion is not able to cope with the first version.

[eluser]TheFuzzy0ne[/eluser]
If you need to make several calls to $this->CI, then you can just set a variable within the method to use:

Code:

function some_method()
{
    $CI =& get_instance(); // Just like you would in a helper.

    $value = $CI->uri->segment(3);
}

Don't get me wrong. I'm not saying that the way you're doing it is not right, I'm just suggesting some alternatives you may not have thought of.

[eluser]xwero[/eluser]
So we have four solutions:

- a object/variable white list for the models.
pro : flexible
con : configuration

- a namespace for controller connected objects/variables
pro : no collisions with local variables
con : additional typing (CI->)

- don't attach the instance, helper syntax
pro : only code change to core is removing the attaching of the controller objects/variables
con : more code in the models

- don't attach the instance, kohana syntax
pro : controller variables/objects stay in controller scope
con : will require ugly php4 hack

If we look at the resources, i don't know if it really matters, the namespace solution is as wastefull as the current solution or even a bit more. The white list is a little less wastefull and the don't attaching solutions are the most resource friendly.

If we look at the backwards compatibility the white list solution is the best way to go as it requires no changes in the current models code.

[eluser]TheFuzzy0ne[/eluser]
Very well said. I wish I were as sensible as you!