new releases?

[rakucmr]

is this project still developed or is dead?

[tomlankhorst]

Developed, but slowly On 21 Mar 2015 13:29, "Razvan" notifications@github.com wrote:

is this project still developed or is dead?

— Reply to this email directly or view it on GitHub https://github.com/kohana/kohana/issues/72.

[enov]

Speaking for myself, I was busy the last couple of months, and my schedule is still a bit messy. I am hoping for more active re-engagement soon.

[rakucmr]

Why don't add more core developers in your team or maybe is a good idea to give the project to an university like codeigniter did.

[lenton]

Speaking for myself, I was busy the last couple of months, and my schedule is still a bit messy. I am hoping for more active re-engagement soon.

Same for me, I am busy working on personal projects but when finished intend to get back to working on 3.4. I've converted all my web projects to use Kohana so that I'm continuing to learn the framework and am inclined to carry on its development.

[rakucmr]

Maybe this can help you, https://github.com/kohana54/core, Gavin Alves, has a branch of kohana 3.3.1 psr-4 ready.

[acoulton]

I've also been very busy with work projects this winter/spring but am hoping to find a bit more time towards the summer.

@raku

Why don't add more core developers in your team

Anyone who wants to contribute is welcome to, initially by submitting pull requests and if the code and process is of sufficient quality they will be invited to the community core developer team. If you want to see faster progress, get involved or find someone who will. Suggesting we magically "find some more core developers" is not helpful. That's basically been the message for the last ~5 years....

Maybe this can help you, https://github.com/kohana54/core, Gavin Alves, has a branch of kohana 3.3.1 psr-4 ready.

First, it's not "ready", he says right in the readme that it's highly unstable work-in-progress. He's obviously welcome to fork if he wants to, but IMHO it would be far better for everyone if he'd attempted to discuss his approach with us and make his changes as logically separated contributions to the core repos. There's plenty of appetite among the current team for namespaces, dropping transparent extension, composer autoloading and dependency inversion but nobody's had time to work on it. We'd have welcomed his help.

[rakucmr]

Ok, I've sent him an email, I hope he will take part on this.

[galves]

Thanks for the interest. I'm tied up right now but I'll respond with my thoughts this evening. Overall I don't have any pressing need to work on this at the moment so the work is shelved.

Like Kohana in general, my fork was for my own specific needs hence it has been worked on without much consideration for the wider community.

[galves]

If you cast your mind back to 2009, the days of Swine Flu, PEAR, Codeigniter and Zend 1, Kohana was a real gem. It was one of the first decent attempts at a lightweight OOP framework and used all the design patterns that were common in the PHP world at the time - Factory, Singleton, Inheritance ...err.. Inheritance.

However today, for everything that was once unique and compelling about Kohana, there is a more widely adopted solution:

• Modules & Cascading File System => Composer • Transparent Class => Namespaces & aliases • HMVC => Better client side frameworks (Angular/React etc) and browsers. • Performance => Faster frameworks, improved PHP Interpreter, better hardware, HHVM.

All frameworks which are developed to support a particular business follow the standard Hype Cycle and Kohana is no exception.

It is almost impossible to have anything but this cycle because any serious innovation would conflict with the developer's own needs of the framework and evolution becomes more specific to the needs of the business so changes cannot be pushed upstream. Hence we just stay in the plateau of productivity.

Having frameworks come and go is completely natural and it is a true credit to the achievement of the devs that it remained relevant for this long. However for the benefit of those who may be referred to Kohana by a well meaning friend or old blog post, we should be honest and publicly recommend on the website that it not be used for new projects.

In terms of supporting existing users who want to adopt more modern practices, composer compatibility packages (ohanzee?) make more sense to me than trying to continue development of Kohana as a web app framework. It's easier said than done though as the core Kohana/Request/Controller classes are tightly coupled. At least having standalone ORM and DB packages would be a very helpful and realistic ambition?

I can't really offer any dev resource at the moment but there is a good chance I'll get back to Kohana54 at some point in the future. Do let me know if there are any copyright infringement issues with the name.

[ursoforte]

I think "ohanzee" And the correct way forward. I like Kohana , but currently I'm using php Slim with components Zend 2 , Aura.

[headbandno2]

HMVC is a fantastic feature!

[G4MR]

Any plans for a Kohana4? I remember using this framework back in the day religiously then Laravel came out and got pretty active then I started to roll my own w/ prebuilt components.

[galves]

HMVC fits a number of anti-patterns and is only really useful in my opinion if you absolutely cannot do client side composition using javascript. Frameworks like Angular JS make this extremely easy.

I think you have the right approach G4MR where you are roll your own framework using composer. It is pretty much what Laravel has tried to do anyway, however its tendency toward best of breed (Doctrine, Symphony Components) which makes it quite heavy weight for most tasks.

For anyone waiting for Kohana 4 I have a Fuel PHP bridge project which allows you to run most old Kohana projects with little modification. Fuel PHP is basically Kohana 4 anyway.

[headbandno2]

Only downside for composing on client side, that it's way more slower. @galves do you have any examples there it is anti-pattern?

[galves]

There are two main problems with HMVC. The first is technical; it is impossible to completely isolate the requests/responses due to limitations of Kohana & PHP (over use of globals/singletons, shared database connections, etc) as well as limitations of HTTP (shared response headers, output buffer etc). This will result in all kinds of unpredictable side effects.

The second problem becomes clearer when we think of why we are doing HMVC in the first place. The answer is almost certainly that we are trying to re-use logic between controllers, and here is the crux of the problem. The purpose of the controller is only to couple requests to domain objects. If you are sharing business logic between two controllers (handling a form submit for example), you should abstract the logic into another class and inject that into both controllers, not couple the two controllers together. It is basically a variation of the fat controller anti pattern.

Composing on the client is not necessarily slower and can actually be much faster. Consider having two mvc requests where one performs a 4 second database operation and the other performs an HTTP REST call taking 2 seconds. Using HMVC it would take 6 seconds to render the output but by doing both requests in parallel on the client, it would take only 4 seconds. You can also compact/preload your page fragments to make SPA apps which feel extremely responsive. Scaling and debugging live performance bottlenecks is also much much easier when you don't have one controller doing a dozen things.

[acoulton]

@galves absolutely. HMVC felt like a good idea at the time, but these days I'd see it as a sign that either:

• there's simple logic/data you're trying to reuse - better done by improving the separation of concerns in your code.
• you genuinely need to combine data from multiple sources - better done with properly isolated microservices and asynchronous / parallel requests either client or server side.

Personally, I'd drop HMVC from a future release.

[headbandno2]

@galves

1. I agree that current implementation shares globals - but it is true that any code that depends on them will be more complex, and harder to test. We could back up all globals, don't allow to leak it any directions (up or down) - which kohana already does for setting up phpunit testcase. If request only accesses URL and request data (POST, GET), and there is no side effects only output is rendering content, then it is a pure function pattern. Composing with HVMC pure requests is more manageable than writing one huge controller, b/c sometimes you need to do that (e.g. linkedin profile page - it haves quite a few widgets, for witch I don't think they use one controller only).
2. It is trivial to create a reusable API, for APPS and website.
3. 1. It is true that current versions of PHP does not allow code to run concurrent, but with HHVM we can use async/await to span multiple requests.
   2. In most cases two fast requests from client will be more expensive than if they are executed on same server - b/c of the latency.

[galves]

What I'm saying is not that you should try to make one huge controller which does everything. Quite the opposite. Instead of HMVC, you would have a Controller interface like this:

interface ControllerWithTwoWidgets {
  public function __construct(Widget $widget1, Widget $widget2);
}

and Widget

interface Widget {
  public function __construct(Request $request);
}

Now you have decoupled your controllers and written code which is understandable, testable and re-usable. It is also more performant than processing the entire request life cycle 3 times.

To make this sort of approach practical, you really need to consider adopting dependency injection.

[headbandno2]

@galves so is this example uses hmvc with DI?

<?php

interface Fetcher
{
    function __invoke( $endpoint, $data = [] )
    {
        return 
            Request::factory( "{$endpoint}" )
            ->method( 'POST' )
            ->post( $data )
            ->execute( )
            ->body( );
    };
}

interface Controller
{
    function __construct( Fetcher $fetch )
    {
        $this->users = $fetch( '/users' );
        $this->widgetTwitter = $fetch( 'twitter.com/widget', [ 'apiKey' => '...' ] );
        $this->widgetOurs = $fetch( '/widget' );
    }
}

I could abstracted all fetch resources to thin classes and injected them as argument in constructor.

[galves]

This is an improvement because the controllers are decoupled but it still replies on HMVC.

What I'm trying to emphasise is you can benefit from forgetting totally about HMVC. Please create a new ticket and I'll make you a complete example if you like.

[k03n00b]

@galves , how would you define HMVC? Are cURL requests to external server (like REST web service) HMVC anymore?

[galves]

HMVC is composition of MVCs architectures. In the context of Kohana, this would be to aggregate the business logic and HMTL output of multiple page requests on a single page. For example if you had a web page with a contact form, and a search form, you could compose them both on a single page using HMVC.

There are certainly much better ways of doing this.

You could use cURL for HMVC (Kohana supports this), however using RESTful web services would not constitute this. The fundamental difference is that with HMVC you would be requesting the same media type as the parent request and embedding the response directly (i.e. HTML) rather than simply requesting domain objects from a REST service.