Viewed   95 times

I'm writing a little homebrew ORM (academic interest). I'm trying to adhere to the TDD concept as a training exercise, and as part of that exercise I'm writing documentation for the API as I develop the class.

Case in point - I'm working on a classic "getCollection" type mapper class. I want it to be able to retrieve collections of asset X (let's say blog posts) for a specific user, and also collections based on an arbitrary array of numeric values. So - you might have a method like any one of these

$User = $UserMapper->load(1);
$ArticleCollection = $ArticleMapper->getCollection(range(10,20));
$ArticleCollection = $ArticleMapper->getCollection($User);
$ArticleCollection = $ArticleMapper->getCollection($User->getId());

So, in writing the documentation for the getCollection method - I want to declare the @param variable in the Docblock. Is it better to have a unique method for each argument type, or is it acceptable to have a method that delegates to the correct internal method/class based on argument type?



It is acceptable to have a method that delegates to the correct internal method. You could document it like this:

@param Array|User|Integer $argName optional explanation

but then again, there is no one hindering you having one method each

public function getCollectionByRange(array $range)
public function getCollectionByUser(User $user)
public function getCollectionByUserId($id)

In addition, you could use the magic __call method to pretend the above methods exist and then capture method calls to them and delegate to your internal methods (ZF does that f.i. for finding dependant database rows). You would document these methods with the @method annotation in the Class DocBlock. But keep in mind that the magic methods are always slower over having and/or calling the appropriate methods directly.

Use what you think makes most sense for your application and usecase.

Saturday, August 27, 2022

This is the purpose of Visibility.

In Block 2 your property is protected. This means it can only be accessed the class itself (Database2) and by inherited classes. The error occurs when you try to echo the variable from the outside.

The same goes for the method in Block 3.

The Constuctor can be protected or even private. But you cannot call it from the outside anymore. But something like this is possible:

class Foo
    private function __construct()

    public static function create()
        return new self();

$foo = Foo::create();
Tuesday, November 1, 2022

Since this question was answered, some documentation has been created on the ORM at the magento knowledge base.

Introductory information:

Advanced ORM usage and the EAV system:

Working with the Varien collections (lazy loading, filtering, etc...):

Tuesday, December 27, 2022

The problem in your code is not triggered is because you checked variable file in the post variable and you wont find it there. the corect way to do it is

if(isset($_FILES['file'])) {
    $fileupload = new upload();

    if($fileupload -> uploadfile()) {
        echo 'Fisierul a fost uploadat';

further more your class will not work you should pass the variables to a constructor and rename upload-> startupload() to upload-> upload

Wednesday, December 28, 2022

You cannot use Method Chaining with static methods because you cannot return a class level scope (return self won't do). Change your methods to regular methods and return $this in each method you want to allow chaining from.

Notice that you should not use T_PAAMAYIM_NEKUDOTAYIM to access instance methods as it will raise an E_STRICT Notice. Use T_OBJECT_OPERATOR for calling instance methods.

Also see:

  • Chaining Static Methods in PHP?
Thursday, October 20, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :