OOP considerations in message abstraction.

[Aeglos]

Hello peeps, I am seeking advice and enlightment with a "philosophical" issue I'm having.
I'm beginning to code a small MVC framework as a learning project and future site building tool (Being tired of recoding and redesigning everything all the time); the basic crunchy bits are done (registry, controllers, URIs, etc)... but I arrived at a point where It seemed that I would benefit having some sort of BOS (as in "Basic Output System") or as it might be more commonly known, a message abstraction layer, which I'd like to:

[b]A)[/b] Output basic messages, such as "Controller not found", "Failed to load class", "Form subtmited", etc.
[b]B)[/b] Generate and log similar messages, at a more crude description level for debugging purposes, such as "file ../include.php not found", "Class_Form class loaded", "Object registered", etc.

Now, searching around Dr. Google I found this: [url=http://www.phpfreaks.com/tutorials/109/0.php]http://www.phpfreaks.com/tutorials/109/0.php[/url]. Which helped me with implementation, language separation and what not. Yet I thought "Well, i'll just do it OOP-style and make a message class".
There I got to a redundancy problem... For the messager class to be readily available for status output by the various OTHER classes (including the registry!), it has to be set in the registry objects array. Now, the set() method on the registry is supposed to log the "Object set correctly/failed" message(s), thus making the message class sort of mandatory, which I don't feel like doing since I feel it would break encapsulation (registry and message layer too interdependant). But on the other hand, if the message class is NOT mandatory (to the registry at least), I have no way of loging any message, so I'm really lost  ???
(And I quickly scrapped the idea of making every other class constructor's use the message layer instead of the reg's set() method, for the same reasons, and many other obvious problems with that approach).

I've looked at what codeigniter does, and as in the above tutorial, it makes use of 2 "common" global functions, "show_message()" and "log_message()". Now here is where I'm torn... since i'm going OOP all the way, feels kinda akward to use global functions residing outside all my clases as sorts of "superglobal methods"  :-\ but so far it's the most simple and practical approach I've found.

Any suggestions on how to tackle this? Another thing I've thought is to include my message/log methods in the base controller, since they should be "common functionality" throughout the whole application, but then again I'm not sure if such methods belong in a controler in the first place since they feel more like model or even view. (and yet none of them at the same time  :-\ )

I know I'm probably drowning in a glass of water here because of excessive OOP zealotry, but i really want to find some "elegant" solution to this, without having to scrap the whole message abstraction layer idea which I feel to be usefull (and of my personal liking). So the whole thing might be summed down to:
Is using global functions outside class scope, which may be accesible to all (or none) classes against the OOP principles and practices?

Thanks to all in advance, and cheers for a great community. (And sorry for the long post  ;D)

[Jenk]

Design your messaging system to have a failsafe (i.e. an 'echo') incase the messaging class file cannot be loaded.

Or just let the screen remain blank (when in production) and rely on server logs to identify the problem.

[Nameless12]

If i understand correctly you really just want a way to debug your framework that is effective???

Registry()->debug()
Config()->debug()
Db()->debug()
Error()->debug()
Dir()->debug()

An error object that is stored in a registry also makes life easier

Edit::
this is probably not what you are looking for as its more simpler than what you originally stated but I think what you originally stated is overkill. The above is the kind of approach I used in my framework

[Aeglos]

But what if (thinking ins scalability here) I have to change the language of the basic system messages, so for example instead of saying "Form submited" it says "Formulario enviado" or whatever.
Having to re-code ALL the debug() methods would be impractical, as also would be having ALL the classes read the same language file thus duplicating the amount of disk reads and increasing the variable overhead. Spliting all the messages in different class specific files would leave me with a host of micro files which carry the same -or worse- issues.

Centralizing all the system messages which are template independant is what I'm trying to achieve, thus the doubt between the message object or the super global functions.

[Nameless12]

I know there is a proper way to make scripts work on multiple languages, have not read up on it though. If i were going to code it I would probably use error numbers are the numbers are not related to the specific language, then you can pass the number through an object and depending upon what language the user is using it will select a different string from the object.

If you were just using errors for things like page not found you could do something like

SetError(404);
GetError(404);
getErrors();

in this case, SetError adds the error messages into some type of registry, get error converts the number into a string and get Errors returns an array of whatever is in the registry.

I dont like the idea of creating webpages in different languages it just seems so much trouble it is like making the webpage multiple times each time for the different language.

another way you could do it is something like

Templates/English/index.tpl
Templates/OtherLanguage/index.tpl

then use a config file to switch the selected language. There is no point in having the error messages and logging in a different language unless the WHOLE webpage will be in that same language.

class Errors
{
public function __construct()
{
    $selected = 'english';

    $selected .= '_errors';
    $this->error_obj = new $selected 
}

public function E_404()
{
    return $this->error_obj->E_404();
  }
}


Class English_Errors
{
public function E_404
{
    return 'file not found';
}
}

class OtherLanguage
{
  public function E_404()
  {
      return 'otherErrorMessage';
  }
}

I heard smarty has a way of handling multiple languages ages ago it might be worth a read, the above is just something i whipped up, there may be a better way but hopefully that should give you some ideas.

[utexas_pjm]

I have worked on a few PHP projects where language was an issue.  We stored the messages in language files i.e., 

english.php:

[code]
<?php
//...
define('LG_SUCCESS', 'The process was handled successfully.');
define('LG_FAILURE', 'There was an error during this process.');
//...
?>
[/code]

Then your messages look like this:

[code]
<?php
//...
$msg->disptachMessage(LG_SUCCESS);
//...
?>
[/code]

To switch languages you can just translate the constants file.

Best,

Patrick

[Jenk]

Use a settings object for maximum compatibility, and ease of transition between languages.

Also, as far as the problem of "What to do if the language handling class file itself cannot be included?" well that's just going to have to be an accepted risk. You can include this file as part of the core application files list. I.e. the list that says "if these are not present, or cannot be access by the PHP engine, the application will not work."

[448191]

[quote author=Jenk link=topic=124676.msg517645#msg517645 date=1170209954]
Use a settings object for maximum compatibility, and ease of transition between languages.
[/quote]

I will agree with that. In addition I would argue that php variables and constants are not intended as a storage method. RDBMS, XML, INI; those are.

Your settings (or configuration) object will hold a language value, and your error message class will know what data to fetch.