New reorganization?

[Eber Freitas Dias]

Hey guys!

I know we just suffered a major directory structure modification, but as I go deeper with Alloy, I wish somethings where different.

The way it is right now is great and I could live with that structure easily, but maybe we could make it better? I don't wanna sound pretentious but I have some suggestions regarding Alloy's architecture and I'll try to express them here (sorry if I write something wrong, English is not my first language).

Namespaces
Right now we have 4 namespaces: Alloy, App, Module, Plugin. Sometimes I wish we had only two: Alloy and App. The Alloy namespace refers to the core library and the App namespace now refers to an App folder inside the main app folder. Basically, it holds just the ControllerAbstract, which in my opinion could comfortably sit under app/Module. I think that the App namespace should be reserved for the app itself, and I know this is tricky, as the app folder might have a different name, but I would consider changing the loader to contemplate that instead o having multiple namespaces. For instance, once we have Modules, Plugins, Helpers... The way it is, each one of these might have a namespace itself. It would be easier if all of those could be children of App, hence two namespaces: Alloy and App.

Regarding plugins, we could drop the second parameter of the Kernel::plugin method as a boolean and add an options array? That way we could pass, for instance, the exactly namespace path to the loader and place it anywhere. Whithout any namespace definition, it would default to the App namespace. The same could work for any future "plugins" like helpers. This leads me to the next topic.

Portability

The way the current folder structur is is better than before, but as I said when we were still discussing the matter, I wold prefer to have a generic folder for libs on which we could drop any other library we want: Doctrine, SwiftMailer, anything, and Alloy itself. The Alloy folder inside of the lib folder would be totally self contained. We could move folders like the "config" and "Plugins" to a new folder (and namespace) called "App", so we would have "Alloy/App/Plugins" for instance. Alloy is a registered namespace, so if we make the changes to the plugin loader, for instance, core plugins just need a declared class name (with namespace). We could also put tests inside the core folder, but I'm not sure about that...

Configurable parts

It's awesome that Alloy just works! It does and I've tested it on many different ways. The thing is that we have configuration bits spread on different places, well, basically three files: /init.php /www/index.php and /config/app.php. I guess that we could expose to the user (programmer) the basic stuff, and define most of the default configs elsewhere. I don't really know, but the way I see it, things can be confusing at first. This is not really required, but we could think harder and come up with a "prettier" interface for the end-user with the benefit of being able to re-define all configurations or something...

Folder name convention and code convention

This could be just an aesthetic issue but the first time I bumped on Alloy I couldn't understand why there were some folders starting with a capital letter and other that didn't. Now I understand better as I can see that the Capital letter refers to a namespace bit. But I can see the benefit of a convetion there (makes people less confused) so maybe we could just use all of them with Capital letters? I don't know if this kind of change would have side effects so I don't know... The other thing is that we could make some guidelines for code production. I'm starting to help on the code base and I don't really know which way I should produce the code. For instance:

- Spaces or tabs?
- Curly brackets after or under function definition
- White lines with or without indentation
- ...

Or maybe we could adopt a convention and go with it. Or not...

Well, I guess this is it. I would like to know your opinions about my opinions :) I have these ideas all the time and I needed to share with you guys, and I'm available to re-work the framework if we decide to change anything. Again, I'm not imposing anything and I won't stop using Alloy if we don't make any changes. Alloy is just awesome the way it is. I just hope that my humble ideas can make it better, and if they don't, please, tell me so :)

Sorry about the length :P Bye guys!

[Vance Lucas]

Eber - thanks for writing in with the suggestions. Any constructive criticism of Alloy or input on how we can make Alloy better will be considered and reviewed, no matter who it is from. This is especially true while Alloy is in a beta pre-1.0 state.

Namespaces

Alloy projects do indeed have four different top-level namespaces - Alloy, App, Module, and Plugin. This is primarily because the initial application of Alloy was StackboxCMS ( http://stackboxcms.com ), and Modules and Plugins can exist in multiple autoload locations in cascading fashion - core modules required for the CMS to operate, global modules that ship with the CMS, and user-level modules that they have developed or added. Having a top-level namespace for them seemed more appropriate than having multiple "App" folders for autoloading that would affect all library files. There are some issues with this approach though -- namely, that modules cannot be extended from and overridden with custom functionality that have the same name, because they also have the same exact namespace. I am open to suggestions, but I'm not sure I see a better solution to this one.

I would like to see an example folder structure to visualize what you have in mind.

Portability

I too have wished for a generic autoload folder fallback that would be a sort of "catch-all" so that people could just drop files in and not have to configure an autoload location for them. I think we need to make this happen by modifying the loader by adding new methods like 'registerNamespaceFolderDefault' and 'registerPrefixFolderDefault' that we can set to the generic 'lib' folder so that libraries that follow the Zend/PEAR naming conventions will get automatically loaded from there.

Configurable Parts

I agree on the configuration fragmentation, and this does need to be addressed in multiple areas, especially regarding alloy/config/app.php and app/config/app.php and how the two depend on each other. Add to the mix hostname config overrides, and it gets even more tricky. I don't have any terribly good ideas on how to address this at the moment, but I will continue to think about it. And as always, I am open to suggestions.

Folder name convention and code convention

I completely understand the confusion with the folders that begin with capital letters vs the ones that do not. The only solution besides moving them in some lib folder or subfolder is to use lowercase namespaces so the folders are also lowercase. I have mixed feeling on this approach from both sides of it.

Regarding coding standards, I tend to follow Zend's coding guidelines, and I think we should standardize on those. The PEAR guidelines are a bit outdated and are not as precise as Zend's in some places. I thought I put it in the Philosophy page, but I guess maybe not? Maybe it needs it's own page?

--
Vance Lucas
http://vancelucas.com

[Éber Freitas Dias]

Hey Vance!

Thanks for your answer :) I'm trying to put some of these ideas into practice and hopefully, it will be ready soon!

One thing that I'm starting to realize is that building the objects and making them work properly is not the challenge. Alloy could be distributed as just the core, and anyone could work with it without a problem.

Building the "glue code" is challenging and deciding where is the right place to put it is hard! There are a variety of use cases and the "glue code" needs to be flexible enough to contemplate that... But that is the kind of problem a framework should solve I guess, so maybe, if we try hard enough, we can come up with some good ideas :)

I'll try to finish some code and pull it to a branch on my own fork! :) Thanks for your insights!

[]'s

--
Éber

---

Vance Lucas segunda-feira, 18 de abril de 2011 16:54

Eber - thanks for writing in with the suggestions. Any constructive criticism of Alloy or input on how we can make Alloy better will be considered and reviewed, no matter who it is from. This is especially true while Alloy is in a beta pre-1.0 state.

Namespaces

Alloy projects do indeed have four different top-level namespaces - Alloy, App, Module, and Plugin. This is primarily because the initial application of Alloy was StackboxCMS ( http://stackboxcms.com ), and Modules and Plugins can exist in multiple autoload locations in cascading fashion - core modules required for the CMS to operate, global modules that ship with the CMS, and user-level modules that they have developed or added. Having a top-level namespace for them seemed more appropriate than having multiple "App" folders for autoloading that would affect all library files. There are some issues with this approach though -- namely, that modules cannot be extended from and overridden with custom functionality that have the same name, because they also have the same exact namespace. I am open to suggestions, but I'm not sure I see a better solution to this one.

I would like to see an example folder structure to visualize what you have in mind.

Portability

I too have wished for a generic autoload folder fallback that would be a sort of "catch-all" so that people could just drop files in and not have to configure an autoload location for them. I think we need to make this happen by modifying the loader by adding new methods like 'registerNamespaceFolderDefault' and 'registerPrefixFolderDefault' that we can set to the generic 'lib' folder so that libraries that follow the Zend/PEAR naming conventions will get automatically loaded from there.

Configurable Parts

I agree on the configuration fragmentation, and this does need to be addressed in multiple areas, especially regarding alloy/config/app.php and app/config/app.php and how the two depend on each other. Add to the mix hostname config overrides, and it gets even more tricky. I don't have any terribly good ideas on how to address this at the moment, but I will continue to think about it. And as always, I am open to suggestions.

Folder name convention and code convention

I completely understand the confusion with the folders that begin with capital letters vs the ones that do not. The only solution besides moving them in some lib folder or subfolder is to use lowercase namespaces so the folders are also lowercase. I have mixed feeling on this approach from both sides of it.

Regarding coding standards, I tend to follow Zend's coding guidelines, and I think we should standardize on those. The PEAR guidelines are a bit outdated and are not as precise as Zend's in some places. I thought I put it in the Philosophy page, but I guess maybe not? Maybe it needs it's own page?

--
Vance Lucas
http://vancelucas.com

---

Eber Freitas Dias sexta-feira, 15 de abril de 2011 14:47