Localization and internationalization, VARCHAR foreign keys about phreeze

[jasonhinkle]

Hey Ales, I haven't added anything into the framework to deal with internationalization, but Phreeze should support whatever languages you like as long as it uses a consistent charset in the database (default is UTF8). I'm definitely open to any contributions in that area.

As for the primary and foreign key, it is fine to use varchar. It is a little easier if each table has an auto-increment primary key, but it's not necessary.

The only real issue with the primay key being non-auto-increment is that you have to explicitly tell Phreeze when saving that it must be an insert operation, for example:

$person->Save(true);  // <- passing in true argument forces Phreeze to do an insert instead of an update

If you run into any issues though, please feel free to post and I can try to address them.

[alesvaupotic]

Well, I was hoping for some directions as how to start translating the generator modules. Looks like like I'll have to go through each and every file on the builder side to make my own localized version. And patch a new one every time you release it. But, it would be a real pain to translate the many generated files each time I make a new build.

RE: varchar foreign keys. I asked you that because I couldn't get the generator to work correctly on them, INTs are OK, VARCHAR(3) as primaries and foreigns are not. Maybe it's just me, I'll try again.

Thanks,
Ales

[jasonhinkle]

Well, you shouldn't have to worry about framework updates, but like you said - re-generating code would create new views. For the most part I don't normally re-generate my views once I start building my app, but still I would like to see that feature. Since the builder templates use Smarty, I think that there are some solutions for internationalization that could work. And there really is not a huge amount of text in the templates except a few error messages and buttons. Everything else is just the table names and data.

As far as the varchar key thing - this schema seems to work just fine. If you have troubles you could post your schema and I can see if there's a problem with Phreeze or some certain structure.

CREATE TABLE `status_code` (
  `sc_id` varchar(3) NOT NULL,
  `sc_name` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`sc_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `status_code` VALUES ('C','Closed'),('O','Open');

CREATE TABLE `purchase` (
  `p_id` int(11) NOT NULL AUTO_INCREMENT,
  `p_status_code_id` varchar(3) DEFAULT NULL,
  `p_description` varchar(45) DEFAULT NULL,
  PRIMARY KEY (`p_id`),
  KEY `p_status_idx` (`p_status_code_id`),
  CONSTRAINT `p_status_code` FOREIGN KEY (`p_status_code_id`) REFERENCES `status_code` (`sc_id`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;

INSERT INTO `purchase` VALUES (1,'C','Purchase Order A'),(2,'C','Purchase Order B');

[alesvaupotic]

Hmm ... here is the screencast. Server is Ubuntu 12.04.1 LTS with LAMPP 1.8.1, shared web folder is mapped do Z: drive on Windows machine. I copied your schema into test database of MySQL server and ran the builder. Same thing happens, form select shows ID instead of Name. It works with integer IDs, though. Weird.

http://www.screenr.com/jSU7

[jasonhinkle]

ah, i see what you mean. well, basically the builder isn't very smart at determining which field to display in the drop-down. what it does, is it simply looks for the first varchar column that it can find in the table.

this is one thing that you do have to customize the generated code to show the correct column in the case where Phreeze guessed incorrectly. In this example that is done inside ~/scripts/app/purchases.js about half-way inside the function renderModelView. You can see the commented line below i changed "id" to "name"

        var statusCodeIdValues = new model.StatusCodeCollection();
        statusCodeIdValues.fetch({
            success: function(c){
                var dd = $('#statusCodeId');
                dd.append('<option value=""></option>');
                c.forEach(function(item,index)
                {
                    dd.append(app.getOptionHtml(
                        item.get('id'),
                        item.get('name'),   //  <!-- ### CHANGE THIS TO ANOTHER COLUMN ###
                        page.purchase.get('statusCodeId') == item.get('id')
                    ));
                });

            },
            error: function(collection,response,scope){
                app.appendAlert(app.getErrorMessage(response), 'alert-error',0,'modelAlert');
            }
        });

[alesvaupotic]

Oh, I see. I thought it literally looks for "Name" column and displays that in a select box. At least that is how it seemed after looking at your screencasts and my first few tables which really were set up with integer IDs.

All is well now, I'll adjust my code. Thanks for your time.

Ales

[jasonhinkle]

cool, if you come up with any ideas for il8n let me know

[alesvaupotic]

Sure, I'll just start translating the builder and see where it takes me.

Case closed.

[xtrasmal]

If you ever want to go international, then I will help getting the Dutch part translated.

[alesvaupotic]

Re: varchar keys. Usually first field is a key and one of the following fields is a descriptor. Would it hurt if you would start looking for description after first field?

/**
     * Returns name of the first varchar field which could be used as a "label"
     *
     * @access public
     * @return string
     */
    function GetDescriptorName($remove_prefix = true)
    {
        $i=0;
        foreach ($this->Columns as $column)
        {
            $i++;
            if ( ($column->Type == "varchar") and ($i>1) ) 
            {
                return ($remove_prefix) ? $this->RemovePrefix($column->Name) : $column->Name;
            }
        }
        // give up because there are no varchars in this table
        return $this->GetPrimaryKeyName($remove_prefix);
    }