Will Fris's WordPress Weblog











{20101119}   de uri

Weer een tijdelijke `blob`, die ik hopelijk op een later tijdstip nog weer wat verder kan uitwerken. Ditmaal over de uri.

de URI

De uniform resource identifier wil nog wel eens een onderschoven kindje worden in web-applicatie’s. Ik heb zelf echter een sterke voorkeur voor goed te onthouden uri’s. Maar dat zal wel komen omdat ik Tim Berner Lee’s artikel, “cool uri’s don’t change” heb gelezen…

apache

Er zijn een aantal mogelijkheden om apache zo te configureren dat deze op een slimme manier het door de client gewenste bestand opvraagt van de server.

apache’s Options +MultiViews

Door aan binnen de apache-configuratie de MultiViews optie “aan” te zetten, word het mogelijk om de extensie van bijvoorbeeld het php-script weg te laten. e.g. //host/index.php kan door de client worden ingetypt als //host/index. Wellicht wordt het wat interessanter met het gebruik van path_info in je php-script. e.g.: de client typt: //host/admin/bericht/toevoegen , de server probeert achtereenvolgens te vinden( bij benadering): bestand toevoegen(.*) in map bericht in map admin, bestand bericht(.*) in map admin, bestand admin(.*) in hoofdmap.

Deze mogelijkheden leggen wat mij betreft wel enig gewicht in de schaal bij de keuze voor pull- of push- gebaseerde aanpak van dat wat je aan het schrijven bent.

apache’s mod_negotiation

Met apache’s mod_negotiation is het mogelijk om met de client te `onderhandelen` over het gewenste bestandstype en/of over de gewenste taal.

Meta

uri vs. url

Wat is nou eigenlijk het verschil tussen een uri en een url?

Het ene is een identifier, identificatie en het andere een location, locatie, zover was ik al wél :p .

Wanneer ik vanuit die constatering verder redeneer, kom ik op de gedachte dat de identificatie een beschrijving is van hoe het eruitziet en de locatie de plek is waar het gevonden kan worden.

Mocht jij het verschil goed weten, kun je het dan misschien op een manier aan mij uitleggen zonder ingewikkelde technische woorden 😀 ?



{20101110}   Delegation Pattern

Delegation Pattern

Intro

The delegation came to my interest because i wanted to create an more abstract way of composing form-elements used for database-input.
At first i thought about scaffolding, but this is not really the type of abstraction i’m looking for.
Scaffolding at this moment seems to be to me an abstraction of solving-the-problem, instead of an abstraction of the problem itself.

At the moment this is more of a note then anything else.
The examples i give about the delegation pattern on this page are in my opinion quite useless…
I’ve already put them down here though, for fun’s sake( not blaming pete here).

Some Wikipedia-quotes

I’ve quickly collected what seemed to be the most useful sentences in a few wikipedia-articles.
It is my plan to sometime ellaborate on these quotes.

Design patterns were originally grouped into the categories: creational patterns, structural patterns, and behavioral patterns, and described using the concepts of delegation, aggregation, and consultation.

In its original usage, delegation refers to one object relying upon another to provide a specified set of functionalities. In research, this is often referred to as consultation or as aggregation in modeling.

In software engineering, the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object. It passes the buck, so to speak (technically, an Inversion of Responsibility). The helper object is called the delegate. The delegation pattern is one of the fundamental abstraction patterns that underlie other software patterns such as composition (also referred to as aggregation), mixins and aspects.

The short definition is that delegation defines method dispatching the way it is defined for virtual methods in inheritance: It is always the most specific method which is chosen during method-lookup. Hence it is the original receiver entity which is the start of method lookup even though it has passed on control to some other object (through a delegation link, not an object reference). Delegation has the advantage that it can take place at run-time and affect only a subset of entities of some type and can even be removed at run-time. Inheritance on the other hand typically targets the type rather than the instances and is restricted to compile time. On the other hand, inheritance can be statically type-checked while delegation generally cannot without generics (G. Kniesel has shown that a restricted version of delegation can be statically typesafe). Delegation can be termed “run-time inheritance for specific objects”.

Examples

Shamelessly taken from wikipedia’s “Simple Java example” :


class RealPrinter { // the "delegate"
public function print () {
print( "something" );
}
}
class Printer { // the "delegator"
private $p;//@var $p RealPrinter
public function __construct () {
$this->p = new RealPrinter(); // create the delegate
}
public function print() {
$this->p->print();// delegation
}
}
class Main {
// to the outside world it looks like Printer actually prints.
public function __construct () {
$printer = new Printer();
$printer->print();
}
}
new Main();

Shamelessly taken from wikipedia’s “Complex Java example” :


interface I {
public function f();
public function g();
}
class A implements I {
public function f() {
print( "A: doing f()" );
}
public function g() {
print( "A: doing g()" );
}
}
class B implements I {
public function f() {
print( "B: doing f()" );
}
public function g() {
print( "B: doing g()" );
}
}
class C implements I {
// delegation
private $i;// implements interface I->
public function __construct () {
$this->i = new A();
}
public function f() {
$this->i->f();
}
public void g() {
$this->i->g();
}

// normal attributes
public function toA () {
$this->i = new A();
}
public function toB () {
$this->i = new B();
}
}
class Main {
public function __construct () {
$c = new C();
$c->f();// output: A: doing f()
$c->g();// output: A: doing g()
$c->toB();
$c->f();// output: B: doing f()
$c->g();// output: B: doing g()
}
}

Also see



{20101109}   XDebug configuration

In this entry i will try to publicly memorize my XDebug-configuration changes.

For now, showing more depth is the main one, in my config i have typed:

xdebug.var_display_max_depth=12

The default value is 3, which just doesn’t cover most of my multidimensional combined-key arrays.



et cetera