soledad penadés

repeat 4[fd 100 rt 90]

Dave Child loves to make cheat sheets! He surprised (helped) us in the past with the php, css, javascript and etc sheets, and now we have the Ruby On Rails cheat sheet. This is going to be very useful for people like me, which tend to forget those little details like the available predefined variables when you have to deal with more than one single language or project at the same time :)

It is very similar to the notes I usually made when I was studying: everything very synthetized, all in a single page if possible. So that's why I found these sheets very natural to me.

Thanks, Dave!

Doing a project with more people in php can be really complicated when it comes to naming constants. For some reason each people has his own way of naming things. Some people will like to start constants with an underscore, like _MYCONSTANT and some others will not, like MYCONSTANT.

The problems get stronger when things begin to appear repeatedly (specially if there's more than one programmer adding constants at the same time).

So what I did is try to find a way of naming which was meaningful and more or less consistent. I'll explain you so we can all benefit from the other's experiences…

There are several types of constants, depending on the purpose:

• labels: something which appears with form controls, like "Enter the text here". These constants are prepended with LBL_
• texts: text which appears on any place, but is not a label. These have a TXT_ prepended.
• titles: which are used on page headers and section names: we prepend a TITLE_

This way if you split your code in modules, you can have constants like:

MODULE1_TITLE_INSTRUCTIONS
MODULE1_TXT_INSTRUCTIONS

and you won't have collisions like MODULE1_INSTRUCTIONS being used both for the title and for the text of the instructions by different programmers.

Also, constants are alphabetically ordered in the files. Not appended at the end with any order…

It could also be applied to more languages. In fact I somehow took some ideas from the way constants worked on MFC or visual basic (taking into account that I don't remember too much from those days so maybe it is not exactly as I thought…).

What do you think of this method? Do you have some suggestion that could make it better?

I posted these thoughts on the forum of a well known open source cms, but nobody has come with a real answer. Maybe the developers are quite busy, or maybe they are not reading that subforum.

Anyway, what I suggested was a different approach when coding php. We all know that php can be used in a very dirty manner, mixing php with html and so on, but what I want to suggest does not go in that direction.

What I propose is to do meaningful and robust code. To anticipate to the possible errors which can appear when more people participates in an open source program and do not take care of being as careful as you. This usually leads to problems when classes are redefined, variables are overwritten and code gots broken because nobody knows what do the include files have inside.

So, main points I would recommend:

• Use the include_once and require_once with the real purpose they were used.If a file needs to be included just once, why do you use a simple include? Use include_once. And if a file is a MUST for executing more code, why do you put an include? Put require. Obviously if a file must be included once, use require_once.

  I have seen several pieces of lazy written code which break easily when you mix them with code which includes the same files. Why? Because they just put include. This does not mean you can't use include, but use it where it can't harm. That is, do not use it for including functions or classes, but instead, pieces of text that change rather rarely, etc (although for this case I would recommend using templates, for example smarty).

• Never, ever, unless you really know why you are doing it, use $_GLOBALS. Function parameters were created for some reason.
• In the same line, never, ever work with register_ globals =on. This is insecure, obsolete, dirty, leads to errors and definitely is ugly.
• Prepend your own prefix to the classes you create and release to the public.For example, each time I do something for xplsv, I prepend those objects with xplsv_. This way is more complicated to have name collisions when mixing source codes from different projects. And it's specially useful for typical classes names as Utils, Text, Common, etc. All of us have created that kind of classes and do not want them to got broken because somebody else had the same idea, don't you?
• Use classes and objects.
  
  Using classes you don't dirty the namespace so much as if you use functions. You can simply add more functionality to a project using a class which encapsulates all of those functionalities, and does not include lots of functions which you will have to rename if you decide to change your mind.It's easier to explain with an example: Imagine I want to have some functions which are useful for manipulating texts. So I have these functions: text_tolowercase(), text_removeampersands(), etc… Then you think that text is too generic, and you have to replace it for textutils.

  There you go: text_tolowercase() becomes textutils_tolowercase(), and text_removeampersands() becomes textutils_removeampersands(). Of course, you have realized that after creating a big project with those functions, so you have to replace it on every single line of code which uses those functions. And test it. Stupid waste of time, yes.

  After that, here comes Pepe Perez. He's a brilliant coder and has made more functions like yours, but unfortunately some of them collide with your functions. He put the same names, so if you want to use his code, you'll have to decide between your code or his code, or work on integrating both, or… you know.

  If you had put everything inside a class… Let's say we call it xplsv_textutils… you wouldn't have had to rename each function and fix each line of code where the functions were used, as you would have been doing something like this:

  require_once('xplsv_textutils.class.php');
  $xtu = new XplsvTextUtils();
  $xtu->tolowercase($blah);

  And if Pepe Perez used classes, adding his class PepePerez_textutils would have been superquick.

• Finally, if you do not trust the other coders in your project (i would suggest never trust even yourself), be careful when including files which should define a class. This would be something similar to the C++ style of including files.In the whatever.h (the header file for a class), you do something like:

  #ifndef _WHATEVER_
  #define _WHATEVER_
  (here you define whatever)
  #endif

  So each time a file includes whatever.h, a check is made to verify that whatever has not been defined before. This could be somehow imitated in php by checking if a class exists before including its definition:

  if(!class_exists("whatever_class" )) {
  require_once("whatever.class.php" ) ;
  }

You probably know there's a quick way of dumping your whole database to a file, with mysqldump. This generates a .sql file containing all the data you would need to restore your database when moving to another server, or when doing a backup.

Anyway, if you have ever tried to restore a database which contained foreign keys it's very probable that you had problems with it, as the dump just outputs all the tables in alphabetical order, not taking into account whether one depends on another and so on. So you are likely to get an error like this: "Cannot delete or update a parent row: a foreign key constraint fails".

Scaring, isn't it?

First solution could be reordering manually the dump, putting the tables in a reasonable order in a way that they can be created without breaking any constraint. But this is a pain-you-know-where!!

There's a better way of doing this. In your sql dump, add this statement at the beginning:

SET FOREIGN_KEY_CHECKS=0;

and this other at the end:

SET FOREIGN_KEY_CHECKS=1;

and voila! run that dump with your favourite method - may it be phpmyadmin or mysql command line client itself (this is the fastest one and the recommended method if you have a very big database, otherwise phpmyadmin can time out and you'll end with an incomplete database).

Now this method is not only avoiding problems with foreign keys, but is also faster, as it does not check things that should be ok - as they come from a supposedly ok database.

Isn't it cool? Enjoy it! Now you don't have excuse for not doing backups of your database!

He visto que varias personas estan buscando acerca de este tema. Como directamente no he hablado de eso aun, y parece que interese, a pesar de ser la pregunta mas chorra del mundo, ahi va la respuesta:

Para anidar plantillas en smarty solo teneis que usar include. Asi, si teneis una plantilla maestra.tpl y quereis incluir una plantilla titulo.tpl, en maestra.tpl simplemente escribis {include file="titulo.tpl"} y chimpon.

Que os sea util…