spunQ.class.php File Reference

Go to the source code of this file.

Classes
class	spunQ
	Global initialization/configuration of the framework. More...
Functions
	__autoload ($className)
	Class autoloader.

---

Detailed Description

Developer log entry:

Necdet Can Atesman (2009-01-21): Broke down the initialization of the framework into two phases. First, all existing files are sourced and types are generated. After that, all objects are updated and their _type members are set to the right value. This was done since it was not possible to create a DataObject object without creating a type object, which in turn is a DataObject.

Developer log entry:

Necdet Can Atesman (2009-05-12): I guess we need a globally accessible environment variable containing a context for the current operations. This would include the currently active user (if that is going to be a part of the core), the chosen language, the chosen theme for templates, etc. Introducing such a global variable bares the risk of abusing it for storing arbitrary global values only relevant to the application, not to the whole framework. Examples of what not to put there:

• User's registration step: This should be part of the user itself
• State of a money transaction: This must be accessible through other means, like currentUser()->getLastTransaction() or similar - which evaluates to the same as the first point
• Visited pages, breadcrumbs and the like: Such information is most probably only relevant to one specific presentation of a specific use case. If the application logic depends on these values, they should be stored along with other properties of the user.

One way of eliminating this abuse would be to hard-code the contents of the environment:

• Current user: If great parts of the application take the current user into account, he should be promoted to a core functionality. After that, the value can be stored in the evnironment.
• Errors and warnings encountered during the processing: Although the logger could take care of local warnings, anomalies occuring in remote peers could be accumulated at this point.
• i18n: Objects with multiple translations would cause two distinct database queries (one for retrieving the translation key, one for the translation itself) if the translation to be used was not available during the retrieval of its members. Other handy values are date formats, float formats, etc. This could be a simple reference to a global resource, too. The ID could be an rfc4646 language string.

Developer log entry:

Necdet Can Atesman (2009-05-12): As discussed in the previous devlog, adding user management to the core functions could be required, this devlog entry will try to elaborate on that idea.
First of all the single important reason against user management in the core module: Loss of flexibility. The number of interdependencies within the module grows as more features are added to it, so we will see, if a user management is really required as a core function - maybe it can be implemented as an independent module.
On to the reasons we might need it as an inherent part of spunQ:

• Enhanced security: Services can check a user's priviliges on critical operations. The database for example could map the spunQ user's group to database credentials to use for queries. Restricting usage of certain members to distinct user groups could be possible. Mapping spunQ groups to system users could resolve security issues.
• Logging (who created/deleted/updated this entry?)

That's it, but I think that it is enough to require user management at the lowest possible level.

Developer log entry:

Necdet Can Atesman (2009-05-12): Another candidate for core types is the translatable string. Now that we can define a locale in the environment, we should consider implementing localized strings at the lowest possible level. Since localization is part of the specification, it has to be implemented somewhere, and implementing it somewhere else would require us to retrieve the translation key first and perform the lookup afterwards, which again would mean that such an operation would require two database queries. Let's continue this discussion in spunQ_Language.

Developer log entry:

Necdet Can Atesman (2009-05-14): More core type considerations:

• Remote objects (We need them explicitly)
• Multilocale strings

Definition in file spunQ.class.php.

---

Function Documentation

__autoload

(

$

className

)

Class autoloader.

This function will be called whenever a class is referenced, that was not declared.

See also:

spunQ::includeClass()

Parameters:

$className

Name of a referenced class.

Returns:

void

Definition at line 703 of file spunQ.class.php.