Recommend this page to a friend! |
Rounded DIV Corners | > | All threads | > | You should provide a way of... | > | (Un) Subscribe thread alerts |
|
andrea rated this package as follows:
Utility: | Good |
---|---|
Consistency: | Good |
Examples: | Sufficient |
andrea - 2008-01-12 18:28:25
You should provide a way of accessing library parameters such antialiasing and radius with an associative array instead of passing a string to the roundedDiv constructor.
e.g. $obj= new RoundedDiv('bla', array('radius' => 10, 'antialising' => true), other parameters); You shall encapsulate the $OBH (instance of Output Buffer Handler I presume) into the roundedDiv instance and avoiding to pass it as parameter, this will enhache usability. The rest is ok.
Jon Gjengset - 2008-01-14 15:37:44 - In reply to message 1 from andrea
Hmm.. I see you point with the passing of parameters, will be added in the next release (which will be this evening =P)
Didn't quite understand what you meant with this though: You shall encapsulate the $OBH (instance of Output Buffer Handler I presume) into the roundedDiv instance and avoiding to pass it as parameter, this will enhache usability. How do I encapsulate the OBH class into the RoundedDIVs class?
andrea - 2008-01-16 19:20:19 - In reply to message 2 from Jon Gjengset
You should hide the $OBH instance inside the class.
For any configuration to the object use set methods. However for encapsulating give a look here: http://en.wikipedia.org/wiki/Information_hiding I mean you should avoid to make the user manipulate objects that shouldn't even be seen by the user. $OBH (intendeed as the instance of a class that occurs in some algorithm) should be encapsulated into roundedDiv class. Regards
Jon Gjengset - 2008-01-20 13:49:53 - In reply to message 3 from andrea
Ah! I see what you mean =)
The thing is that I don't want to do it that way since it would prevent users from adding their own handlers to the output buffering (or they would have to add handlers through the RoundedDIV class which is not something it was designed to do)...
andrea - 2008-01-25 21:32:46 - In reply to message 4 from Jon Gjengset
Users would be still able to implements their own or third party out buffer handler.
That's just a "limitation" of your point of view, in other words: class RourdedDiv { private $_outputHandler; public function __construct($name, $params, OutpuBuffer_Handler $handler = null) { if (null !== $handler) { $this->_outputHandler = $handler; } else { $this->_outputHandler = MY_Default_OBH(); } [...] } public function setOutputHandler(OutputBuffer_Handler $handler) { $this->_outputHandler = $handler; return $this; } [...] } the type hinting (OutputBuffer_Handler $handle) prevents the user from passing random values, in fact, the only valid parameter would be and instance of OutputBuffer_Handler or one of it's subclasses (because of inheritance). So the user could leave to null the value passed to the constructor, this will force the class to use a default OBH. If set, the parameter is an instance of any custom OBH choosen by the user, so he can pass it as parameter to the constructor (or using the proper setter) and the instance will be stored and used within your class. Obviously the OBH shall have consinstence, so they would probably implements an interface, which defines all the public methods, so all classes that will implements that interface can be used without specializing RoundedDiv to worki with it. Regards
andrea - 2008-01-25 21:51:09 - In reply to message 5 from andrea
Sorry for the bad grammar in the last paragraph (I wish it was the only :D )
I'm saying that all OB handlers that will be used within your class shall have a guideline (the interface) that would set some constraints to the development of OB classes. Eg. interface OBH { public function doSomething($parameter1, $parameter2); public function doFoo($paramete1); public function doBar($parameter1); } Any class that will implement this interface MUST implement also doSomething, doFoo and doBar methods and they must have the same signature as the interface. This allows you to have a code that works with any OB handlers in the shape of your interface; this means that the OB handler should be created ad-hoc for your class intead of the opposite :D. Everyone who knows the the "guidelines" of your OB handler can implements his own, instantiating it and passing it to the constructur of RoudedDiv and your class will work without problems because the "interface" of a OBH is well known from your code, no matter who wrote it. I tried to be as clear as possible, I apologize for my bad english. Best Regards!
Jon Gjengset - 2008-01-29 18:33:51 - In reply to message 6 from andrea
No problem, your English is perfectly readable =)
I am having a problem implementing the interface idea of yours for two reasons: 1) The interface will have to be defined in the OBH class file, and then the OBH class will have to implement the interface (Am I right? I haven't played much with interfaces =P). My problem is that I don't know how to check if the object passed actually implements the given interface.. 2) The OB handler will have to be passed by reference, so that the global object itself is modified, not a copy in the class, as this would make each new object overwrite the previous ob_function.. (ob_start will be run multiple times...) Regards //J
andrea - 2008-01-31 16:18:27 - In reply to message 7 from Jon Gjengset
Interfaces can be defined anywhere in the filesystem, just remember to include them before using.
For type check on interfaces use php5 type hinting, for more information see http://ch2.php.net/language.oop5.typehinting Here's some code that could give an idea : interface OutputBuffer_Interface { //only public methods in interfaces!!! public function foo($parameter); public function bar(); public function baz(); public function getInstace(); } class OutputBuffer_Personal implements OutputBuffer_Interface { //if a method is declared into the interface, it must be //implemented into the class. public function foo($parameter){} public function bar(){} public function baz(){} } class RoundedDiv { protected $_obh; //$name : div name //$parameters : rounding parameters //$obj : is the OBH, can be left blank public function __construct($name, $parameters = array(), OutputBuffer_Interface $obj = null) { if (!null == $obj) { $this->_obh = $obj; } } } Now let's talk about the problem of having multiple instances of OBHs. This can be avoided by transforming OBH class into a singleton class. Singleton class cannot have more than 1 instance in memory (webservers allocate a part memory for each user) this is done by declaring the __construct and __clone methods to private and using a getter to get the instance: class OutputBuffer_Personal implements OutputBuffer_Interface { static private $_instance; private function __construct(){} private function __clone(){} static public function getInstance() { if (self::$_instance === null) { $class = __CLASS__; self::$_instance = new $class; } return self::$_instance; } } now you can use the class by refering to a variable which contains it's instance: <?php //start of the file, create the only instance of OBH we will use $obh = OutputBuffer_Personal::getInstance(); ?> [some html code] <?php RoundedDiv('bla', $parameters, $obh) ?> now EVERY instance of RoundedDiv will use the SINGLE instance of OBH. Problem solved :)
andrea - 2008-01-31 16:20:36 - In reply to message 8 from andrea
I forgot to say, if you wish to know the type of an object use the instanceof operator.
|
info at phpclasses dot org
.