Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Orm in legacy mode?
  • Hello, I'm Julian from the Novius OS team, a new CMS based on FuelPHP. We understand the ORM is now in a legacy mode and no further developments are made to improve it, only bug fixes. We've been asking ourselves how it will be promoted in the future. Will it be recommended not to use it in favour of another ORM (like Doctrine or Propel)? We'd like to be able to do more with the ORM and we wonder whether to develop new functionalities on top of the existing ORM in FuelPHP, or to switch over a new one that will probably ease the process (because it's possible to make extension). As examples, here is what we'd like to have:
    Custom filters
    Some people already asked for this I think. The idea is to add some sort of before_find() or before_where(), which are not observers because they don't work with an instance but rather on a global level within static calls. For example a publication system could create a special 'is_published' filter which will act on 2 columns date_publication_start and date_publication_end to fulfil the custom condition. This filter / condition would be usable in the find() method, or from the $query->where() method, or applied from a related model. Behaviours
    This is the word used by other ORMs. Some examples include: * NestedSet would add some fields and some methods on the objects (set_parent(), get_parent(), get_children(), etc.). * Publishable would add methods like is_published() (which use the custom filters from above), publish(), unpublish(), schedule_publication() Available options
    ============== We could implement those functionalities to improve the ORM (and break the "legacy mode" ). in that case, we'll need your support and expertise to make a good implementation, to follow the guidelines and the Fuel's philosophy and to have a nice API for all that.
    As we've already been working on it, we don't really aim at a big effort / investment on your side. We'll happily do the dirty work, but we need your help to make it into the Core properly.
    What do you think about it? We're looking forward hearing from you. Many thanks, Julian and the Novius OS team.
  • Custom filters
    Some people already asked for this I think. The idea is to add some sort of before_find() or before_where(), which are not observers because they don't work with an instance but rather on a global level within static calls. For example a publication system could create a special 'is_published' filter which will act on 2 columns date_publication_start and date_publication_end to fulfil the custom condition. This filter / condition would be usable in the find() method, or from the $query->where() method, or applied from a related model.
    I never saw the need for this as it is pretty easy to implement this. Either with specific find() method extensions per model or with a more generic extension in your own base model extending Orm\Model. Something like:
    public static function find()
    {
        $args = func_get_args();
        method_exists($this, 'before_find') and $args = call_user_func_array(array($this, 'before_find'), $args);
        $result = call_user_func_array('parent::find', $args);
        method_exists($this, 'after_find') and $result = call_user_func(array($this, 'after_find'), $result);
        return $result;
    }
    
    But it's up to you on how to do this exactly. Behaviours
    I never thought about this and have no suggestions for implementing it at this moment. Available options
    We could implement those functionalities to improve the ORM (and break the "legacy mode" ). in that case, we'll need your support and expertise to make a good implementation, to follow the guidelines and the Fuel's philosophy and to have a nice API for all that.
    As we've already been working on it, we don't really aim at a big effort / investment on your side. We'll happily do the dirty work, but we need your help to make it into the Core properly.
    Best thing would be to fork it and maintain it. Being in legacy mode we won't add functionality and won't accept any new functionality as we'd be responsable for maintaining and supporting those as well. If you fork it you can take the responsibility for those and if your fork proves successfull and sustained in maintainance we'll link our old repo to yours. Which would probably be the best outcome for a life after 1.0 for the ORM.
  • Thanks for you quick answer about this. This is what we're gonna do. The method is not fully integrated because it will only works from within the custom find() method. We won't be able to filter a query afterwards using the $query->where() method, or on a related model.
    But I think it's sufficient, at least for now. Our team will look into the best solution for our needs. We'll come back to you if we end up forking to make a full integration.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion