Not really my place, could this not be added to the 3.8-dev branch? With support for 3.x being about 2 years, it means that 3PD's wouldn't need 2 separate component for different versions of Joomla.

Stuff like this needs to be made against 4. We will backport them then later.

OK I'm don't exactly see the point of this. This would make sense if we had some files that would be above and below web root. But we don't.

However if people feel this way I'm not strongly strongly against it. However I think the fields forms and the helpers do need to go in the /src/ directory because they should be autoloaded like everything else

I don't see yet the issue you try to solve here.

The problem you have here now is that the dispatcher now needs to be namespaced. Then a module needs to be namespace aware. I did deliberately not have the dispatcher namespaced for that reason

Actually this pr works, the dispatcher is not namespaced, that's why it is in the root of the src folder with a lowercase name.

I find it quite unintuitive.
I get that you want to move the config files into an own folder, but why name that one etc and not for example config? I mean etc (et cetera) means basically "any extra stuff that fits nowehere else". Sounds like a bad choice to me even when Linux uses it.

I don't get why we want to move all other code to a "src" folder. That one comes probably from composer or other applications where "src" contains code which is located outside of webroot. But with Joomla it's not realistically to do that and we would have a "src" folder in each extension. So it's a bit pointless to me. Also we move the view class into eg /src/view/article/html.php and the viewlayout in /views/article/tmpl/default.php, meaning we basically duplicate folder structures and split what basically belongs together.
I have to confess that I haven't much clue about namespacing stuff yet. I just know the basics. But so far it doesn't make much sense to me.

On a sidenote, do we really need to uppercase folder and filenames? I have a feeling that gets us into troubles with our mixed enviroment where each OS (Windows, Linux, Mac, ...) handles them different. Personally I'd stick to all lowercase to avoid any issues.

On a sidenote, do we really need to uppercase folder and filenames? I have a feeling that gets us into troubles with our mixed enviroment where each OS (Windows, Linux, Mac, ...) handles them different. Personally I'd stick to all lowercase to avoid any issues.

Yes we do. Best practice with composer is to have Uppercase first names (see the examples in the PSR-4 specification http://www.php-fig.org/psr/psr-4/)

The problem I have is that we mix config files and others with the PHP class hierarchy which is imo bad. Moving the classes to the src folder has nothing todo with web root at all, it is a common set up for PHP based projects. The target is to separate things.

If we move the layout files to a separate views folder like this, do we still need to have tmpl folder inside it?

True, moved the views out of the tmpl folder.

Best practice with composer is to have Uppercase first names (see the examples in the PSR-4 specification http://www.php-fig.org/psr/psr-4/)

Unfortunately, my english skills fail me to understand what they write there.
I just fear we face issues with that as we had in the past. Eg you can't just rename a file from lowercase to uppercase as it results in a copy in some enviroments and a rename in others. If we only rename the file when we move it at the same time, then it works usually to my knowledge.

The problem I have is that we mix config files and others with the PHP class hierarchy which is imo bad. Moving the classes to the src folder has nothing todo with web root at all, it is a common set up for PHP based projects. The target is to separate things.

Imho, it is fine for projects that you "own" and where you end up with one single src folder. But when you have src folders all over the place like in our case, it becomes pretty much useless.
As said I get to move the config files to an own folder (with a sensible name like "config", not "etc"), but I don't get the moving of all other files into a src folder. We don't separate anything here, we just move everything... Technically, the layout and tmpl files are all PHP files as well.
Thinking that further, you would have to move the form XML files to the "etc" (or "config") folder as well since those are config files as well. So you end up with just a src, etc and views folder in your proposal. To me that doesn't make much sense for an extension (it makes sense in an application). It's just changing stuff to change stuff and in the end forcing devs to rewrite their code for no added value. We had that in the past (1.5/1.6 anyone?) and it didn't really go well.

src folders all over the place like in our case, it becomes pretty much useless.

Why should that be useless.

"config", not "etc"

I don't mind changing that, but it is something every developer will recognise.

Technically, the layout and tmpl files are all PHP files as well.

These are template files which do not belong into a classpath structure. They are more like twig templates, we just put too much logic in them.

form XML files to the "etc"

I see them more as entity definitions than configuration.

end forcing devs to rewrite their code

This is absolutely not the case, it is really just moving files around. There are no code changes in the files itself. Yes some library files do need adoption because of the new paths.

It's just changing stuff to change stuff

This is absolutely not the case. It adapts an extension to well known structures in the PHP community. We really need to see over the boarder of the Joomla land and try to adapt good practices. It is not only for small components like com_content. I'm thinking about bigger extensions which do have more none PHP files in their packages. Now the structure is prepared for them as well as it is extendable. I just don't like the idea to mix things which shouldn't.

I'm aware that it is a big change, but it is worth the effort as it is 100% bc and will make things clearer for newcomers or experienced PHP devs.

As said, a "src" folder makes sense for applications where you have your stuff in a central place. Mainly to keep it away from polluting the root folder and to be able to easily move it outside of root.
That's not the case for extensions. And there is also no need to separate PHP files from other files (media files are in another place already anyway).
As for best practice, interesting enough none of our third party library code uses a "src" folder (except the Joomla ones). They have sensible names for their classes directly in their root folders like we do in our extensions.

What I would propose:

• Leave the controller, model, table and view folder alone. We need to figure out a way that upgrades work when those folders already exist (due to "New MVC") but not capitalised yet. Depending on OS this will create issues but that's another topic.
• It may make sense to create a config folder for the XMLs allthough not really needed for those two files which are not autoloaded anyway. Maybe more useful if there are more files.
• I can see the use for a "form" folder which contains the form XMLs and also a subfolder "field" for the extension specific formfields because technically they don't belong to the model where they live today.
• And I could see moving the view layout files into a "layout/view" or "layout/tmpl" folder so they are closer to the JLayout files. Certainly don't leave them in "views" and at the same time have a "View" folder with the view classes.

As for best practice, interesting enough none of our third party library code uses a "src" folder (except the Joomla ones).

You need to include some extra context here as well. Symfony and Laravel, if you pull those frameworks in as full-stack dependencies, will have a src/ directory, but won't if you pull individual components because of how git subsplit works (for example the https://github.com/symfony/yaml repo for Symfony's YAML component is a split from https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Yaml). PHPMailer 5.2 doesn't support namespaces or autoloading by default and uses its own structure; PHPMailer 6.0 has a src/ directory. Just staring at the vendor directory of one of my projects right now, I have Doctrine which uses a lib/ directory for its code (as does Twig), Guzzle using a src/ directory, and PHPUnit 6 which uses a src/ directory.

And just to complete the circle, while there's a general recommended best practice for libraries (generally a lib/ or src/ directory for production code and a tests/ directory for the tests, other common practices include a etc/ directory for config stuff and bin/ for executables), there isn't a one-size-fits-all solution. Most Symfony bundles start right at the repository root (though some use a src/ directory).

So it's really neither wrong or right to say a src/ directory is bad or only for code outside the web root. It's all about opinions, and we all know what they say about opinions.

and we all know what they say about opinions

Mine is the one true opinion?

In combination with the pr #15226 we can really do powerful things like moving the sources to a completely different location, outside of the root for example.

For me, most components will have the following structure when we follow this pattern:

com_foo
- etc (or config)
- forms
- layouts
- scss
- src
- tests
- vendor
- views

So it absolutely makes sense to move the PHP classes to src. But the biggest benefit I see is that we don't have to care about the upper/lowercase name issue like we had to with te move to namespaces. So we can revert stuff like b98e7b9.

You can't move the extension PHP files outside (or even a different place within) of webroot in Joomla. That would break several thinks (like installer). The autoloader is your least concern here.

Let's not make that a discussion right now, it was just an example.

So I had a look at this. Regardless of the src/ discussion, I see why it is there. What I do find confusing is the layouts and views folder. What I would alos like to see is how we can merge the front-end and back-end files into one.

If we go this way, we should have a way I guess to make sure J3 style extensions keep working.

etcis standing for 'editable text configurations, with edible == user edible, text == ASCII. It usually contains default versions of configurations, that we currently ship as *.dist.
srccontains everything controlled bay the application / extension, i.e., also the views.
It exists mainly to separate the application code from vendor, tests, and documents, which not are needed in a production environment (for an extension, the local vendor will be replaced with the main vendor directory, configurations use to be copied to a central place, too. The root directory just keeps the information needed f.x. by composer for installation.

@roland-d:

• We were internally discussing how we should name the views folder, but didn't came to a conclusion. layouts is already taken by JLayouts. Templates by the templates itself. Actually my favorite is tmpl.
• Moving the front end classes with the back end, can be done with the pr #15221, but not with this one.
• The whole thing is fully BC. When you check out that branch, you will see that the old components like banners or fields do work as before. No changes needed.

etc is standing for 'editable text configurations

Thanks for that information, I couldn't figure that out.
So in our context, etc indeed would be wrong.

edible == user edible

Hopefully not! (edible = "essbar" g)

src contains everything controlled bay the application / extension

So basically "src" is usefull for the repo of the extension where you also have the unit tests and documentation. When packaged, the zip will only contain files from that src folder. Also in a Joomla extension, all files within the extension folder are supposed to be controlled by the extension and NOT editable by the user (they would be overwritten by the next update). Which means all files of the installed extension would belong into that src folder which makes the use of that folder superfluous.

I had never heard of etc meaning editable text configuration - so if that is what it means in this context

1. it is wrong for us to use that as thats not what is going in the folder and any developer expecting it to be editable text configuration files will consider it a bug/fail/error
2. I am never in favour of using ambiguous terminology. As "etc" usually has a different meaning I wouldnt use it here

It doesn't in linux land. According to the research I did. /etc/ used to be for et cetera because it used to hold all the stuff that didn't fit elsewhere. Then when linux moved out the home directory and mount directories and various others, it's now become the home for configuration files

Source: Various places where this principle has been mentioned https://ask.slashdot.org/comments.pl?sid=224934&cid=18218900

if it means et cetera then it is fine but if people think it means editable text configuration then it is not - my 2c

In the meantime, I'v renamed etc to config. Guess it confuses people more than it helps.

@Bakual only PHP classes do come into the src folder no XML, config or template files. Don't understand why you want to put all the files into src.

Don't understand why you want to put all the files into src.

That was my conclusion based on the answer from @nibra which said "src contains everything controlled by the application / extension, i.e., also the views." but it is certainly NOT what I want.
I don't want to move any files at all if there is no technical reason to it. Just moving stuff because someone has an opinion that all PHP files should be in a "src" folder isn't an argument to me.

The biggest issue which leads to the proposed set up is that we have problems with upper and lower case folder name collisions on systems like windows.

Beside that, I do not propose a new folder structure because I don't have better things to do in my life. We really need to evolve and should adapt to some standards. The world is changing and Joomla should go with it. I mean we have that structure since the times where spaghetti code was a standard and nobody was talking about namespaces. But stuff has changed and so should we.

I mean, every extension developer can still use the all in one layout which exists since Joomla 1.5. We are not forcing anybody to do the move, this PR is 100 BC to the old layouts. But in core we should move forward.

The biggest issue which leads to the proposed set up is that we have problems with upper and lower case folder name collisions on systems like windows.

Actually, Windows (and Mac) isn't an issue here. It's Linux which will create both files, one capitalised and one lowercased. In Windows it will just rename the file and it doesn't care about capitals anyway.
It will also only be an issue when we just rename the file itself. In most cases we will rename the folder as well (eg from models to Model) where it will be no issue at all. So it may only become an issue for components which are using the new MVC currently because the folder names match the namespaced ones. For those cases (eg com_config) we will face that issue. However there are surely other solutions which could be done and there is no need to change the structure of all extensions.

I mean we have that structure since the times where spaghetti code was a standard and nobody was talking about namespaces. But stuff has changed and so should we.

The current structure was introduced I think with 1.5 where the basic MVC got introduced. 1.0 was spaghetti. With namespace we already rename the folders and all classes. So it's not like there ar eno changes to adapt new standards. And that's fine.

We really need to evolve and should adapt to some standards.

Yes, and we do. But there is no such standard which says we need to put all PHP classes into an own folder and separate it from XML, sql, ini and layout files. And even if there would be, in our context it has no advantage at all. It just adds a new level to the directory tree. It's not like there are a gazillion folders and files in a component folder. It's actually quite an ordered structure already with typically around 8-10 folders and a few files in root.

One of the reasons for a (well-defined) directory structure is that one day, we want extensions to be installed in a composer-like way (with dependency management). A separation of src/tests/docs/vendor would be a step towards that goal.
Thomas Hunziker notifications@github.com hat am 13. April 2017 um 22:06 geschrieben:
The biggest issue which leads to the proposed set up is that we have problems with upper and lower case folder name collisions on systems like windows.

Actually, Windows (and Mac) isn't an issue here. It's Linux which will create both files, one capitalised and one lowercased. In Windows it will just rename the file and it doesn't care about capitals anyway.
It will also only be an issue when we just rename the file itself. In most cases we will rename the folder as well (eg from models to Model) where it will be no issue at all. So it may only become an issue for components which are using the new MVC currently because the folder names match the namespaced ones. For those cases (eg com_config) we will face that issue. However there are surely other solutions which could be done and there is no need to change the structure of all extensions.

I mean we have that structure since the times where spaghetti code was a standard and nobody was talking about namespaces. But stuff has changed and so should we.

The current structure was introduced I think with 1.5 where the basic MVC got introduced. 1.0 was spaghetti. With namespace we already rename the folders and all classes. So it's not like there ar eno changes to adapt new standards. And that's fine.

We really need to evolve and should adapt to some standards.

Yes, and we do. But there is no such standard which says we need to put all PHP classes into an own folder and separate it from XML, sql, ini and layout files. And even if there would be, in our context it has no advantage at all. It just adds a new level to the directory tree. It's not like there are a gazillion folders and files in a component folder. It's actually quite an ordered structure already with typically around 8-10 folders and a few files in root.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

We don't need to separate test and docs because those aren't in the install package to begin with, or you have built the package wrong. The vendor stuff would have to go into an global vendor folder or the dependency management becomes useless.
So you only have the files within the src folder within the extension directory. That is what I mean, there is nothing to separate it from in that scenario.

Actually, Windows (and Mac) isn't an issue here.

It was a windows issue. This was not just something I have invented. It was a problem on Windows as I have namespaced com_content. Ask @joomdonation for more details.

The vendor stuff would have to go into an global vendor folder

Definitely not. If an extension does have it's own composer managed libraries, they need to stay in the component folder. This will lead to a situation where JLoader is managing the component folder and has also the vendor folder in it's own classpath.Additionally Composer is managing the vendor folder. So we have the odd situation that the vendor folder is in the classpath of two different classloaders which is very bad.

It's actually quite an ordered structure already with typically around 8-10 folders and a few files in root.

In core, but there are bigger extensions which do have more folders. And for me the core should lead as good example.

But I guess @Bakual, we all heard your opinion. I would also like to get more feedback from others.

Can I clarify something​

This proposal would change the folder structure of core components AND extensions can use this new structure​ OR keep with their existing structure?

Yes, this is 100% BC. We are not forcing any extension to change as we are not forcing them to change to namespaces during Joomla 4 lifecycle. This set up just makes sense when a component is namespaced, even then it is not a requirement.

Thanks for clarifying that.

Next question. Will it require a change in the code in com_templates for discovering the views available to be overridden.

(I see several extensions already use a similar structure eg sobi or a different structure altogether such as jevents)

Yes it would, but from a quick glance, the change would be minimal.

It would require change to com_menus to find the views to create menu item based on new location. But yes, it doesn't require much change and not hard

We are not forcing any extension to change as we are not forcing them to change to namespaces during Joomla 4 lifecycle

It would eventually be a requirement for sure. Not in J4 but maybe in J5 when we drop the newly become "legacy" structure. So it's just a question if extension need to change now or later.

@laoneo why scss files not required to go to media folder as the rest of the static files?

@dgt41 scss it is actually the source not just static file ?
~~and I guess it should not be in the production version of the extension, because it useless ~~

It depends on the set up of the component. Guess there is no real rule for extensions where to put the scss files.

Quick first feedback to this RFC:

• Such a change in components structure (which a timed B/C problem in J5) should have a major and immediately visible benefit compared to current structure. After reading for 5 minutes, I didn't see a major benefit, except that the src folder of each extension individually could be moved outside web root.
• Also, any change in structure should not make it more complicated or confusing to write Joomla extensions, but make it easier. I didn't see this here.
• Following the usual structure of independent php apps might be appealing and reinsuring, but if we don't see a clear benefit, we should maybe just add the missing folders that can make sense (like tests, vendor) and keep the rest as is and long-term compatible.
  But that's just a first impression and I may be mistaken.

Quick feedback as a Joomla extensions developer:

• IMHO every extensions developer should be always be free to choose his own component structure that best suits his way of programming. It always has been since Joomla 1.5 to nowadays and i really hope it will always be

• I really hope that neither in J4 or J5 there will be a major change that would force extensions to be fully rewritten to adhere to a new structure, namespaces, new MVC, etc. IMHO that would cause a lot of people to give up with Joomla, i would be one of them

• I agree that Joomla should moves on as PHP moves on. Do that in the core, do that in core extensions but don't force developers to rewrite their extensions redoing the work that has taken years

@beat:

I didn't see a major benefit

Upgrades will become very hard because of uppercase and lowercase folder names. Every extension dev will need to have some upgrade logic when its extension should be namespaced.
As most extensions do use composer and have a vendor dir in their extensions, it would lead to a situation where two folders are managed by two class loaders. It's more technical stuff which we try to solve here. Additionally, every bigger extension has more than only the four standard folders with classes. This would mean that the root folder is cluttered with just too many folders.

but make it easier. I didn't see this here.

For sure it is easier as it is absolutely clear what the purpose is of every root folder in an extension.

@joeforjoomla:

every extensions developer should be always be free to choose his own component structure

For sure, we are not forcing anybody. It is just best practices and core should state here as good example.

I really hope that neither in J4 or J5 there will be a major change that would force extensions to be fully rewritten

During lifecyle of J4 definitely not. What happens with 5 can not be decided right now. Just to give you a rough estimate what it means to namespace an extension. It took me 5 hours to migrate com_content. It is really just a move and then a bit of search and replace. As all the legacy classes are still available, nothing breaks.

Do that in the core, do that in core extensions but don't force developers to rewrite their extensions

That's the exact situation I want to avoid. That's why I'v joined the Joomla 4 team, to make sure that we extension developers (yes I'm one of that crazy group as well) will have a smooth transition migrating our stuff. It will mean that a namespaced extension should run on Joomla 3.9 and 4. At the same time a none namespaced extension will run on 3 and 4 as well. So there is enough time for an extension developer to migrate it's extension during the Joomla 4 lifecycle.

At least I tried ?

I think you should keep this PR open. Maybe the team can discuss about the structure and make final decision when you are all at the codesprint.