"Dressing up" my data

i would do that in model of application with method getYear or getBirthdate and i would do all checks inside that method (if year === 1900 etc.)

I would encourage making the afterFetch the place to start and making a variable for a view date and leave Birthdate alone.

Something like:

public function afterFetch()
    {
          // Check that birthdate is available and is set to the year 1900
          if(isset($this->birthdate) && !empty($this->birthdate) && date('Y', strtotime($this->birthdate)) == 1900) { 

                // It is 1900. Set to a day/month format
                $this->birthdate_for_view = date('d/m', strtotime($this->birthdate)); 
          } else {

                // Set to a day/month/year format
                $this->birthdate_for_view = date('d/m/Y', strtotime($this->birthdate));
          }

    }

The above presumes the birthdate from the database is like so: 1900-12-25 or 1900-12-25 00:00:00

@pixiesky: That's basically what I'm doing now. But if I don't query all fields in my table, {{ person.birthdate_for_view }} doesn't exist in the View, so I'm assuming that the event didn't fire or something. (I haven't gotten xdebug running yet, so I can't check that directly, but that's a different issue.) I'm not far along in my learning MVC to know how I'm supposed to handle situations where I need fields from multiple tables (a join) - whether I need a special model for that or if Phalcon will use the models for each table. I picked one of the simplest pages in the application as a starting point; most of the rest will need joins, concatenates, etc. When I get to that, I suppose I'll find out whether afterFetch fires in that case or not, but I bet I'll have the same problem.

And although the page I'm working on now is only for display, this will get added every time the model gets data, so for pages that do CRUD I'm concerned that save() will get confused by having extra stuff in the model that doesn't match the schema of the database.

Have you got in to relationships yet?

See: https://docs.phalcon.io/en/latest/reference/models.html#relationships-between-models

Venturing in to MVC in the early stages does kind of melt your head a bit but it's worth it.

Yeah, now that you mention it, I did set up some relationships a while ago, but then forgot about them after it didn't seem likely that I would use them very much. Using relationships and PHQL saves a few "ON" clauses in joins over simply writing raw SQL, but its drawbacks are far more significant for someone like me who is used to writing my own SQL anyway: it won't allow subqueries, GROUP_CONCAT(), and probably several other MySQL-specific techniques, and it does two extra queries before every data retrieval (a check to make sure the table exists and an EXPLAIN statement), adding to the MySQL engine overload significantly.

After spending a couple hours trying to figure out how to reference data from a join (if my table name is "person", my model must be "Person", and the join must use the model name, but the additional object layer added because of the join is named after the table, not the model - https://docs.phalcon.io/en/latest/reference/phql.html#creating-queries-using-the-query-builder didn't explain that), I finally got a little test running. It appears that my pseudo-fields do work as long as I ask for Person.*,Household.*. But if I try to ask for individual columns, the whole thing falls apart again.

Yes, brain melt is in full swing!

Yeah you have to stick to naming conventions for stuff to work in the code but an odd table name can be used by declaring in your model what the table is.

    class Robots extends \Phalcon\Mvc\Model
    {

        public function getSource()
        {
            return "the_robots";
        }

    }

But of course then things get start to get more confusing in the long run.

https://vimeo.com/63022489 << If you havn't seen that one yet then do. It demonstrates building a model file with phalcon tools and is worth knowing and seeing what the 'default' model file is. Gives you a feel for the place as well.

It sounds to me that PHQL is the way to go in your case. One the things about using a framework's system of talking to the database is that you can switch to a different database easily in the future in the case, say, MySQL can't handle the site anymore or a server move or whatever. You may also prefer to get arrays from your queries; in which case ->toArray() plonked on the end (technical term that) can be used.

I've never actually tried the following but I am presuming it works:

    $phql = "SELECT CONCAT(c.id, ' ', c.name) AS id_name FROM Cars AS c ORDER BY c.name";
    $cars = $manager->executeQuery($phql)->toArray();
    foreach ($cars as $car) {
        echo $car['id_name'], "\n";
    }

My point being once you have settled on how your model/s are going to function with the options available you can then do your best to keep data in the model. Models should have most of the code as well; controllers should be as slim as possible. If you need to manipulate the data then you should try to make that happen in the model; fat models thin controllers and views shouldn't have much logic at all unless it's for displaying something such as the date next to the copyright.