Using models from within models

[eluser]intractve[/eluser]
[quote author="XedinUnknown" date="1261150591"]

intractve,

What you have shown me is exactly what I am trying to do, and I can confirm that it kinda works. However, imagine a situation like this:

Code:

// Inside a controller
$this->load->model('customer', 'user');

// Inside the 'Customer' model
$this->load->model('user', 'user');

This code didn't work for me. As far as I could tell, the second one was either not beind loaded at all, or was overriding the first one, I am not sure. I could not know from inside the Customer model, what other models where loaded before. I think the cause of the problem is the absence of Namespaces and Singletons. Correct me if I'm wrong.[/quote]

You cannot access (as far as I know) two models using the same namespace, when you load the second model, it replaces the first's namespace 'user'.

The namespace user is available throughout the instance once its loaded, whether it be in the model , view or controller. You can access that namespace using this->user, but when u assign something else to this->user the first model is replaced.

for eg.
if u load model 'customer' , 'user' in your controller and following that u load a model called 'user','user1':
inside of the user1 model's functions you can access $this->user->function();
even without explicitly calling for load model in the user1 model. because the current instance already has the $this->user loaded by the controller.

Hope i am clear, I do not mean to teach or anything, just puttin it out here for the benefit of anyone else too.

[eluser]jedd[/eluser]
[quote author="jedd" date="1260999994"]
For example, whether you have a one-model-per-table design, or if you've got multiple database tables managed by each model.
[/quote]

With this unanswered question in mind,



[quote author="XedinUnknown" date="1261150591"]jedd,
As an example, I have a model "Customer", a model "Order", and a model "Product".
. . .
Could you offer an alternative to this..?
[/quote]

Three approaches spring to mind.

Have a model that manages those three entities and their relationships. That is, the model will own (sole access to) the 5 or more tables involved.

Allow models to read tables other than the one(s) they own - with this approach it's easier if you can orchestrate it such that any given table is modified by one model only.

Give the controller some control, and have it interrogate multiple models in order to generate the full data set.

[eluser]XedinUnknown[/eluser]

if u load model ‘customer’ , ‘user’ in your controller and following that u load a model called ‘user’,‘user1’:
inside of the user1 model’s functions you can access $this->user->function();
even without explicitly calling for load model in the user1 model. because the current instance already has the $this->user loaded by the controller.

intractive,

This is precisely my point. I do not know from inside "user1" that "user" is loaded, because it may be built by other people, obfuscated, and what not. I also believe that I am not supposed to know, what or which model, view or controller called the model that I am writing, because you can never know that for sure. And thus, you don't know what models you can (cannot) load from inside your model, or what names you may give them. This is the problem. Such complications are, in my oppinion, a sign of poor system (framework) design.


[quote author="jedd" date="1261157033"][quote author="jedd" date="1260999994"]
For example, whether you have a one-model-per-table design, or if you've got multiple database tables managed by each model.
[/quote]

With this unanswered question in mind,

[/quote]
jedd,

Here's the answer. I may have models that handle a table each, together with models, that handle multiple tables, such as EAV entities. Whatever the case, I, in my oppinion, should be able to manage these models alltogether or separately if i wish at any point in time.

Three approaches spring to mind.

Have a model that manages those three entities and their relationships. That is, the model will own (sole access to) the 5 or more tables involved.

Allow models to read tables other than the one(s) they own - with this approach it's easier if you can orchestrate it such that any given table is modified by one model only.

Give the controller some control, and have it interrogate multiple models in order to generate the full data set.

All these approaches, as opposed to what I want, greatly complicate the development process and lack the flexibility I need. Why should I think, how me, ore someone else want to manage my table/model relationship..? You cannot possibly think of all the combinations one may need. All these complications are needless. Why not just create many models, each responsible for their own data, and enable them to call each other how they want..?

[eluser]intractve[/eluser]
I got nothing more to put forward for you except maybe that CodeIgniter is not for you.
I hope you find the flexibility to do what you want elsewhere.

CodeIgniter is pretty awesome that it bends to all my whims and fantasies and I love it, I hardly do anymore php which is not CodeIgniter.

So I wish you well in what you are trying...

[eluser]XedinUnknown[/eluser]
Thanks, intractive. Unfortunately, CI does not bend how I want it to. Perhaps, you're right, and it is simply not for me. However, I don't know, what IS. So, I decided to do this: http://code.google.com/p/x-tool/. Maybe once you will be one of it's testers =)

[eluser]intractve[/eluser]
Well, all the best to you, but before you leap into starting off an entire framework, you should look into Zend, that is the framework (I believe) behind magento. I agree with you on magento, Ive used it on a currently live shop project I completed, It's really cool.

[eluser]jedd[/eluser]
Just this morning, when I was on the phone to my mum, I was saying 'Ya know, Mum, a lot of people think there are too many frameworks out there, but really I don't think there's enough.'

Your decision to start a new framework seems quite prescient, in this context.

Seriously, though, if you reckon it's easier to write and document and test a whole new framework from scratch - rather than just attending to the bug(s) that wiredesignz has highlighted, and that others have posted (apparently) one-line fixes to - then .. well, I'm at a loss to come up with something witty if that's really what you do believe.

Is this a reasoned reaction to the one design deficit you have so far identified with CI? As I understand it, you can talk from one model to another - this was the stated position from the start of this thread. Have you looked inside other Big Projects (eg. Bamboo Invoice, Unravel the music, PyroCMS etc) to see how functioning large systems handle this problem?

[eluser]XedinUnknown[/eluser]
intractive,

I have tried Zend, but it just seems too difficult and big to install, let alone use. I would like to be based on my own libraries, instead of employing all of that heavy stuff. Obviously, some things I will take from Zend, but I will not base the new framework on it.


jedd,

No, the described is not the only thing that CodeIgniter is lacking in my oppinion. And those bugs are not one line fixes, as you will see below. I think these are also a good idea to facilitate:

- Singletons. Efficient and flexible, allowing any model to call any other model or library.
- Namespaces. What can I say..? They are a great way to organize things an allow for greater compatibility and flexibility.
- Blocks. Similar to Magento, blocks would be a functional unit on the page.
- Layouts. Just like the previous, these come from Magento. These are XML pages that determine the hierarchy of blocks on a page. They may also tie the Blocks to their templates.
- XML configuration. No comments.
- Templates. There would be an option to use an XML templating engine I have in mind. It would render valid XHTML markup in any case, all properly formatted. The support for normal PHP templates will remain. Templates are to be rendered from inside a Block.
- Models. I would like to include special ORM and EAV models, apart from the regular ones.

As some may notice, most of these things come from Magento. Indeed, I love it's functional flexibility, but it is either too complex, or too poorly documented. I would like to improve a bit of the first, and most of the second.

I have not looked at the projects you have mentioned, but from their names one may guess that they are not frameworks as such. However, it is a good idea to inspect everything to produce one framework, which will contain the best feeatures that exist. Everyone is welcome to join and work on it.

[eluser]Jondolar[/eluser]
Isn't your problem really just a namespace problem? When you use a 3rd party library, don't all languages have this problem? Isn't the solution to publish libraries with classes named with a prefix such as zz_View, zz_Client, etc? Since your 3rd party libraries may not have this, isn't the answer that you prefix your own classes with your own special prefix code? Once you have solved the namespace problem, all of the functionality you want is available. You can load any model from any model, etc.