Cphalcon: [4.0.x] Rename Phalcon\Cli\Console

[ekmst]

I propose to rename Phalcon\Cli\Console to Phalcon\Cli\Application.
Similarly with Phalcon\Mvc\Application

[stamster]

Well, it's still console (CLI) usage, not an application (web)? Depends how you look at it - IMO this is not necessity.

[niden]

I have no problem doing this, so long as the community decides whether it is best or not.

I will post this in discord to get feedback.

[npfedwards]

In my opinion this creates unnecessary confusion. Just thinking from a developer efficiency standpoint, it'd be far to easy import the wrong class using your IDE. I can understand the viewpoint behind changing it but also, if it ain't broke...

[jturbide]

I like it separated in order to avoid confusion, in my case, I'm doing this from my bootstrap:

use Phalcon\Mvc\Application;
use Phalcon\Cli\Console;
...
$this->mode === 'console' ? Console::class : Application::class,

changing it would result extra noise as:

use Phalcon\Mvc\Application as MvcApplication;
use Phalcon\Cli\Application as CliApplication;
...
$this->mode === 'console' ? CliApplication::class : MvcApplication::class,

[dschissler]

I think that Mvc is already quite overused and I've changed it to Web in my framework. I plan to introduce a swoole async mode application for first class server-sent instead of overlaying it onto a "cli" setup. I dislike how much web first stuff there is in Phalcon and it shows that the cli stuff was added on mid-stride and then never refactored.

[ekmst]

@niden

I suggest the following options:

Phalcon\Mvc\Application to Phalcon\Application\Mvc,
Phalcon\Mvc\Micro to Phalcon\Application\Micro,
Phalcon\Cli\Console to Phalcon\Application\Cli or Phalcon\Application\Console.

And we take out the entry points to applications in a separate namespace.

[jturbide]

@ekmst +1

[virgofx]

Yeah I like it component based. Makes the most sense for organizing by feature. +1 @ekmst

[dschissler]

How about Phalcon\Application\Mvc becomes Phalcon\Application\Web? If its not in the Phalcon\Mvc namespace then it can be renamed.

So:

use Phalcon\Application\Cli;
use Phalcon\Application\Micro;
use Phalcon\Application\Web;

or

use Phalcon\Application\Cli as CliApp;
use Phalcon\Application\Micro as MicroApp;
use Phalcon\Application\Web as WebApp;

End the MVC madness in 2019.

[ekmst]

How about Phalcon\Application\Mvc becomes Phalcon\Application\Web? If its not in the Phalcon\Mvc namespace then it can be renamed.

So:

use Phalcon\Application\Cli;
use Phalcon\Application\Micro;
use Phalcon\Application\Web;

or

use Phalcon\Application\Cli as CliApp;
use Phalcon\Application\Micro as MicroApp;
use Phalcon\Application\Web as WebApp;

End the MVC madness in 2019.

I think Web is a general case. Since the framework itself implies the creation of web applications, it will be more appropriate to use the types of these applications as the name(mvc and micro).

And Cli is a special case.

[dschissler]

I think Web is a general case.

Ok maybe

Since the framework itself implies the creation of web applications

No

And Cli is a special case.

No

[jturbide]

@dschissler not all web app are using mvc, I think it's important to keep the pattern in order to differentiate different architectures

use Phalcon\Application\Cli;
use Phalcon\Application\Micro;
use Phalcon\Application\Mvc;
use Phalcon\Application\Hmvc;
use Phalcon\Application\Pac;
use Phalcon\Application\Mvvm;
use Phalcon\Application\Mvt;
...

[ekmst]

@dschissler not all web app are using mvc, I think it's important to keep the pattern in order to differentiate different architectures

use Phalcon\Application\Cli;
use Phalcon\Application\Micro;
use Phalcon\Application\Mvc;
use Phalcon\Application\Hmvc;
use Phalcon\Application\Pac;
use Phalcon\Application\Mvvm;
use Phalcon\Application\Mvt;
...

I agree

[ViltusVilks]

Yep, +1 for Phalcon\Application\xyz as component
but arch-specific stuff under required architecture namespace

so then it make sense to separate Web (pool by httpserver) and Cli (direct exec) ... but... also running from cli is possible with Swoole (like self-hosted app in NET for example),

use Phalcon\Application\Cli;
use Phalcon\Application\Web\Micro;
use Phalcon\Application\Web\Rest;
use Phalcon\Application\Web\Rest\Swoole;  // just an example
use Phalcon\Application\Web\Mvc;

[dschissler]

@ViltusVilks I agree in principle but it seems that the namespace is getting real deep.

I think that Swoole will be a thing with Phalcon at some point. I definitely plan to release a Swoole mode in my framework at some point. Right now I have a full cli with GNU style parsing and command help and a MVC. I guess that I was rebelling against "MVC" because there is too much shit in Phalcon\Mvc right now. The Phalcon\Application\xyz design feels best. Then move some other stuff like the other issue about the URL being moved out of Phalcon\Mvc as well. Then MVC might actually just have MVC stuff.

One thing that still bugs me though is that pretty much any type of Phalcon app is going to want models and most will want views (or at least simple views). So controllers are in there as well but that is specific to the MVC style application and is not relevant to others. Its a pretty small ideological issue though and I could live with it for perhaps until revisiting the issue in Phalcon 5.

[dschissler]

What about the following?

use Phalcon\Application\Type\Cli;
use Phalcon\Application\Type\Micro;
use Phalcon\Application\Type\Mvc;
use Phalcon\Application\Type\Hmvc;
use Phalcon\Application\Type\Pac;
use Phalcon\Application\Type\Mvvm;
use Phalcon\Application\Type\Mvt;

There is already Phalcon\Application\Exception. Additionally my Perch project has a lot of stuff in Perch\Application namespace because it is opinionated. For example there is an app config class which reads the root application.yml. I'd like to be able to use the same naming scheme as Phalcon. I think that claiming the entire Ph\App namespace could get us into trouble (it already does with the Exception, although I don't know if the application needs its own exception).

If you guys can get behind this in the next 1-2 days then I can make it happen (soon).

[dschissler]

@ViltusVilks I like your idea. I don't believe that we can use the root of Phalcon\Application namespace due to other stuff needing to go in there like Exception. So what about this, its basically the similar to using Type but separating by if its initiated from the cli or through a web server.

use Phalcon\Application\Cli\Console;
use Phalcon\Application\Cli\Pm;
use Phalcon\Application\Cli\Swoole;
use Phalcon\Application\Web\Micro;
use Phalcon\Application\Web\Mvc;

Guys we need to get moving on this since its unlikely to happen if we approaching a beta.

[jturbide]

I am still voting for my previous proposition without the cli/web context. I don't see any problem of sharing a namespace with other classes like Exception. In fact, I do this all the time in different other contexts.

Contradictory, within my application I currently use AppCli\Console as well as AppMvc\Application in order to match Phalcon's logic but in the end I wouldn't really mind altering that namespace for another explicit approach.

[dschissler]

I have four other files in my Perch\Application directory. It will be five with Exception.

[edit] I could bump them down I guess.

[dschissler]

Please vote in #13868 for the way to rename the application classes.

[dschissler]

I refactored my project to Choice 3 of the vote since its close enough to Choice 4 that I can update it easily depending on how the vote goes (even though I chose 4). I'm seeing that Choice 3 is really quite fine if I just ignore that some of the classes in the root Application namespace aren't application classes. If there ended up being many types of applications and other application support classes then it would be a bit of a muddle. Nothing huge but more difficult for a newbie to see what is what.

@erisrayanesh might be presenting some research on refactoring the parts of the application class sometime soon. I'm imagining how the different modes of an application break down and how much commonality there is between all types of applications and the two specific "runmodes" of Cli and Web. For web there is micro and mvc and for cli there is "tasks" and in the future other looping/async types of apps like Swoole. How much is it worth considering since we don't know exactly what that will look like? I'm not sure if a CLI Swoole and Task app will look anything alike. So I'm wondering if there is any value in the Choice 4 (App\Web and App\Cli) since its a separation that organizes app classes which may not inherit the same things.

[jturbide]

@dschissler I agree, will do the same from my end too.

[dschissler]

@jturbide Please vote in 13868. I created the other issue to vote (without too much discussion) based on the feedback from here. So far the vote seems to be successful in that there haven't been any new proposed structures. To be clear it kind of needs a straight up vote. Its non-binding but don't see why it wouldn't be respected by everyone (including the Team) in the end.

[stale[bot]]

Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues