Understanding the Zenphoto Code/Architecture

stef

@Trisweb

Architecture:
* In an other email you mentioned Zenphoto MVC. Can you explain this a little bit more in detail?
Also related to the PHP Code? I will use this information in the Zenphoto Docu/Comments.

Debug:
* How to use sajax_debug?

Thanks in advance

trisweb

Here's an excerpt from an email I sent someone asking about MVC a while back. It tells how Zenphoto uses the design pattern, I can be more specific in areas if you want, just ask. :-)

------------------------------------------------

So, you know the three parts by now: Model/View/Controller.

Model: Handles the data, takes input from the controller and passes output to whoever needs it.
View: Handles how all data and interaction (and, uh, everything) is displayed to the user.
Controller: Handles how the data passes between the view and the model, the model and the view, and how the views flow together.

There are a lot of ways you can modify this however you like, so as long as you understand the basic separation, you can just try it out and see how it really works. Try a simple application and see what you really need for each part.

Zenphoto, for example, sort of uses template-functions.php as a controller and a kind of "view engine", because it proxies between the model (data) and the view. The Model also does some of the work of the controller (incorrectly, alas) in creating i.php URLs for the view (the images at least). I think I did that either because I didn't know any better, or because it really was easier, I forget. In any case, there's room to fudge based on what you need, but stick to your separations. Every time I use the global objects in a theme (essentially accessing the Model directly from the View) I cringe a little bit, not because that's inherently bad, but because I defined that separation, it makes sense with the rest of the app, and I like to uphold it to keep things from getting out of control.

Like how, for example, admin.php is a total mess, acting as its own integrated controller and view, and using the model directly all over the place. I have to redesign it, badly. Breaking all those rules really is a pain, because it actually does make it unmanageable. If you've noticed, I haven't touched the admin.php in a long time, mostly because I can't wrap my head around it anymore. That's the reason for the separation, and that's all you really have to understand.

There's a lot of variation even between software using MVC about which parts play which roles -- some only use the controller for passing around URL's and sending requests to the model, which then does everything, including giving data to the views. In Zenphoto, the controller also has data input and output "translation and handling" responsibility, and the model is kind of a ramped-up customized database access class, that does what needs to be done with the data. It's true that most of the "real programming" in Zenphoto is in the model, classes.php. The point is, it should be separated in some way that makes sense to you, and more importantly, for your application. Obviously, in a Windows app the data model may very well be passing data directly to the view, and that would make perfect sense. It's all about the situation.

Oh, I was also going to say how well this pattern lends itself to Object Oriented programming, and how PHP isn't the best in that regard... it's not that bad, but it's just missing some features in php4, and php5 isn't widespread enough to use it yet. Anyway, it's ideal for the data model to represent each record as an Object in your application. That's very very very useful (seriously). It's also important to practice good Object Oriented programming and database schema design, and make your database tables and model objects correspond to actual "Things" in your application. Zenphoto, for example, uses a PersistentObject class for every database-accessing object (just to generalize the queries and such), then the subclasses of it are Image, Album, and Gallery. Those are the real things that make up Zenphoto, so it makes sense to make them your objects. (As a side story, that's one of the reasons Zenphoto came into existence-- I used to use Photostack, which was great, but I tried to modify it and realized it used two objects-- a "Photostack" (whatever that is) and an "Organize" -- that was bad Object orientation--those were parts of the program, not objects--and I refused to delve any deeper into the code, deciding to start from scratch instead).

I can't really find any good books off a quick search, but I just found this site that does it the way I like (this one's for Rails, but it applies to PHP and any other language as well)
http://www.slash7.com/articles/2005/2/22/mvc-the-most-vexing-conundrum
And here are a whole bunch of pre-wrapped MVC frameworks you can build applications off of (I have no idea about any of these)...
http://www.phpwact.org/php/mvc_frameworks
Ooh, and this is cool too, explains some of the different variations (Passive, active, etc.)
http://www.phpwact.org/pattern/model_view_controller

trisweb

sajax_debug has to be set in the Sajax.php file I believe. It just uses alerts to show the AJAX transaction. If that doesn't work, try setting it where it's included in the zenJavascript() function.

stef

@trisweb
The first effort to document Zenphoto and to create the "big picture".
Please look at http://www.zenphoto.org/trac/wiki/ZenphotoDev and feel free to review
the drawing.

PHP Files:
Do you have some hints to associate the Zenphoto PHP files to Model, View and the
Controller Block?

ToDo:
More will come...

trisweb

Stef - looks pretty good, right basic idea. I think I will make a better one, after all it's for helping people understand how it works and I certainly know that best :-) I think you would benefit from that more than trying to figure it out yourself, and it'd be the best way for me to answer your questions.