Views: how to do this correctly?

[eluser]Martín M.[/eluser]
Maybe this is a stupid question. If it is, please do tell me :lol:

Let's imagine some kind of software built with CI with views which the user can edit. Imagine for example a forum, where somebody downloads the CI built forum and then edits the views to suit them to his liking, in order to integrate it in this existing webpage.

Now imagine that we have 10 pieces of data we pass from the controller to the view, and the user uses them in the view with the classical <?=$blah?>. The problem comes when the user doesn't need all of them, I mean, he only uses 2 or 3 variables that we are passing to the view, but the 7-8 variables are being calculated even they are not used (for example, results of a BD query).

The question: how to fix this waste of resources? Maybe calling functions from the view instead of using passed variables?

I hope somebody understands my concern and can shed some light on this. And if I'm wrong please tell me.

[eluser]Seppo[/eluser]
It is not stupid, although there is no much to do...

[quote author="Martín M." date="1214149405"]Maybe calling functions from the view instead of using passed variables?[/quote]
This go against the MVC pattern used in CI... you could do that, although you shouldn't.

There is no easy way to know which variables are gonna be used in your views.

[eluser]Martín M.[/eluser]
[quote author="Seppo" date="1214154236"]This go against the MVC pattern used in CI... you could do that, although you shouldn't.

There is no easy way to know which variables are gonna be used in your views.[/quote]

That's what I thought

[eluser]Chris Newton[/eluser]
For a few variables... is it really that big a deal? If it is, maybe the controllers use of variables should be set in a configuration file or function.

[eluser]Martín M.[/eluser]
Maybe the problem is not the memory ocuppied by the variables, since that is almost negligible. The problem is when the content of that variables comes from a query (or several queries) of a DB. That way, you would be doing queries but not using their results.

[eluser]Randy Casburn[/eluser]
@Martin my friend, if I understand your use case clearly, you are starting to discover the difference between the Web2.0 hyperbole and what your fictitious users everywhere want from an applications. You've sort of described what a "mashup" is all about. Or what a user customizable "business intelligence portal" is all about.

These things are easily done with the right tools. Seppo is correct in that they cannot be done if you pigeon-hole yourself into a singular Design Pattern (MVC) mindset constructed only with one API or tool set. In order to accomplish the kind of "variable, user-defined visual interface", you must rely on a very old concept called client-server services. That means you have Server API (CodeIgniter) but you must also rely on a Client API to handle the exact requirements you laid out in your use case. You see, CI is perfect for one aspect of your problem but not the other.

The Client side API is most frequently these JS API (frameworks) you hear so much about. The hype is all about AJAX - but it's just JS providing client services. The client services provided should be the UI plus "requesting only the required data that is consumed by the application's interface".

Kinda cool when thought of that way. CodeIgniter + JSFramework = Magic.

That's why some many folks are excited about JS being integrated into v2 of CI.

Hope this is helpful.

Randy

[eluser]Martín M.[/eluser]
Hi Randy,
Nope, a mashup is not exactly my target here, neither something 2.0. I'm talking about something more classic here.

Imagine a forum software built with CI, maybe one like the one I'm typing this words in. Maybe you are first making the software for your site, but then you release it to the public, giving the source, so other users can download it and install it in their servers, and customize the look of it however they want.

The problem here is the following: imagine that in order to show a view, you have done several queries, in order to get things like users, number of posts per user, post contents... But a user doesn't want to see, in his customization of the views, the number of posts which a user has made. So he deletes the <?=$numberOfPosts?> (just an example, remember) from the view, and he is happy because he has customized the look of his forum. But the software, internally, keeps asking the DB again and again the number of posts of an user, although nobody is using it. That's what I wanted to avoid, using something like <?=getNumberOfPosts(user)?>, but that breaks the MVC pattern.

It's only an example, maybe not the best, but I think it explains enough my point.

[eluser]xwero[/eluser]
You could monitor the view files for changes and check them against the list of original variables. And if there are changes you could adjust the data retrieval accordingly.

[eluser]Randy Casburn[/eluser]
I like xwero's idea (don't get that confused with "I like xwero" {jk ;-)}), but think you'll end up prompting the end user with something along the lines of "Hey, you've removed some data from the [View], but the [Model] is still collecting the data. You should go do something about that..."

It would be interesting to see a front end design tool scouring through all the Model files correcting queries (teehee)

Randy

[eluser]xwero[/eluser]
If you have a model method for each page it's doable.