Raza left the following comment in another post so I figured I'd answer here:
---|-
Ian ,
I have been following your blog right from the start, i have been
working on a product for my client . Its a php application and support
multiple databases.Can you share a bit of technical details as to
1) Why Savant is better then smarty ?
2) Whats the best way to handle future need of internationalization ?
3) How to make sure that we avoid database specific query issues ,we plan to support my sql , ms sql and oracle and using adodb.
Would be greatful if you can brielf reply.
Thanks .
---|---|
I'd say my comments are opinions more than fact. Hopefully other readers will provide additional insights.
1) I prefer Savant because it uses PHP as it's template language. Smarty uses it's own new language to make it "easier" for designers theoretically. I tend to have a few problems with this. First is that everyone I've ever known who edited the website templates was a programmer not a designer. I've yet to meet a pure designer who goes in editing template tags. Usually they slice up the design and hand it off to a programmer for implementation. Second, as a programmer I'd much rather work with PHP tags in my templates than learn a new language. Third, because it's PHP I can add functionality to the template by simply using standard PHP functions and code.
Another experience here: http://www.brkstudio.com/blog/2005/10/03/i-was-wrong/
2) This is a huge topic and PHP doesn't make this as easy as it could, but here are some practical tips.
- Keep all your language strings in a separate file.
- In the language file store the charset information as separate variables. HelpSpot also stores the entire charset meta tag as a separate variable to keep things easy to edit.
*[This image was lost to time in my blog transition]*
3. Some PHP functions require you pass them a charset in order to work properly. For example htmlspecialchars. Another limitation here is that you can't just pass in any charset, there's only a few supported. I have a special variable in the language pack which stores the charset that should be passed to these type of functions.
4. If I could do this over again for my product, I'd probably research some of the more standard file types for storing these strings. There are already tools to help do these translations, but the file must be in a certain format. That would make doing translations much easier.
3) I've found that MySQL and MSSQL are very close. Depending on what version of MySQL you want to support you may have to be careful about not using subselects and so on. I don't know too much about Oracle, but it is a bit different. I know with PostgreSQL I ran into some issues. Things like LIKE. PostgreSQL has 2 version of it so if you want LIKE to act the same on all platforms you'll need to use ILIKE with PostgreSQL so that the LIKE search is case insensitive. On PostgreSQL regular LIKE is case sensitive.
I would also recommend using bind parameters. ADODB can simulate them for DB's that don't support them like MySQL.
Another area is searching. All the databases have very different full text search SQL so you'll need to abstract that out in your code to handle it differently for each database type.
You can also check these out:
http://www.userscape.com/blog/2005/08/26/helpspot-gets-postgresql-support/
http://phplens.com/lens/adodb/tips_portable_sql.htm
![*[This image was lost to time in my blog transition]*](http://www.ianlandsman.comlangvars.jpg){kind=link}