Initial Site File Structure

[MisterPhilip]

Setup the initial structure with using Proem, Doctrine, and Twig.

This should include creating any base classes or including any other vendor libraries we see fit.

[trq]

We should probably implement this stuff via composer.

See http://getcomposer.org

I'll also start work on a Twig plugin for Proem as soon as I can. I have already made some groundwork here (https://github.com/proem/proem/tree/twig-experiment) though it's not an actual plugin at this stage.

[trq]

At this stage we should probably track the development branch of Proem as well, just because it's quicker in regards to getting the newer functionality.

[MisterPhilip]

Yup. I saw Ignace had branched site and had composer setup (at least for Proem)

[ignace]

Yup. Started experimenting with Proem. I will be adding Doctrine2 and Twig aswell. Any other components that should be included?

What license will we be using?

[MisterPhilip]

Those are the only 2 components that are on the top of my head, however @trq might have more insight on what we might need that isn't with the framework.

As far as licensing.. ugh, I'd say GPLv3 because then somebody [technically] cannot take the code, repackage it and then sell it. With that said, I'm pretty open to other licenses.

[trq]

I might be better if I develop the Twig plugin. It's just that I would like to give it a common interface that I can also use to build a PHP Rendering view layer on as well. Unless of course you'd ( @ignace ) like to have a crack at that as well (just the interface I mean).

I'll try and get this done within the next few days.

[ignace]

Go right ahead. There is enough to keep me busy.

[ignace]

Ok. So I have created the initial dir. structure, feel free to comment. I will be adding a few more changes in the next couple of hours.

I have a few comments regarding Proem though. Initially I wanted to go for module/index/controller (since all my directory names are lowercase) but there is no method that allows me to clear the default controller map:

Module\:module\Controller\:controller

Unless I subclass Proem\Dispatch\Standard and overwrite the constructor.

Also I would like to tell the Autoloader that the path for a namespace contains the vendor/parent.

$autoloader->attachNamespace('Module', __DIR__ . '/module', true);

Instead of:

$autoloader->attachNamespace('Module', __DIR__);

[trq]

@ignace There is the Proem\Dispatch\Standard::attachControllerMap() method which allows you to add a new controller map, I don't see why you would need to remove the default.

I'll take a look at implementing the other thing now and will reply here when it's in the development branch.

[ignace]

True, but I don't like the waste of having it check a non-existing path first. Would it be possible then to add something like a priority so that I can control which paths are checked first for controllers?

Also was it intentional that everything is named Standard and Template? PHPStorm auto-imports classes (adds a use-statement) but it then complains I have multiple classes named Standard/Template, so I have to alias every use-statement.

I like the convention most frameworks use to solve this problem:

Proem\Dispatch\Dispatch
Proem\Dispatch\DispatchInterface

instead of

Proem\Dispatch\Standard
Proem\Dispatch\Template

[trq]

We should probably move this conversation over to the Proem issue tracker, but anyway.

Yeah, the naming convention is not something I'm overly happy with at the moment. I originally had it more like your suggesting, but I hate having classes named the same as part of there namespace as well. It's something I could possibly change, and likely should have changed when I removed the cascading namespace stuff a while back.

A few things I could do with the controller maps. The simplest would be to make them LIFO, another would be to make them into a priority queue, but that alone is a bit of overhead.

I'm looking at your request to enable a flag to indicate that a namespace path already includes the vendor directory. Is there a particular need for this? It doesn't look like it's going to be all that simple to implement.

[ignace]

No, I have it working currently so there is no real need.

Are you sure that adding

module\:module\controller\:controller

will work if everything is lowercased, because I found:

$this->module     = $this->payload->has('module')           ? ucfirst(strtolower($this->payload->get('module')))      : '';
$this->controller = $this->payload->has('controller')       ? ucfirst(strtolower($this->payload->get('controller')))  : '';

[trq]

:) No, I'm not sure it will work. Which looks like it may indeed be a bug because it breaks psr-0.

Can you please bring up any issues within the Proem issue tracker? I'll get on to things asap, but I'd like it tracked there.

ps: I have just pushed this: https://github.com/proem/proem/commit/f3d110dea90e4059b956256e10b1363cdb846782 which allows paths to end with the vendor/parent name.

[MisterPhilip]

@ignace - it looks like we're going with sf2 now, so I guess we'll need to work on getting setup in the repo.

[gizmola]

On Tue, Sep 25, 2012 at 9:46 PM, Philip Lawrence notifications@github.comwrote:

@ignace https://github.com/ignace - it looks like we're going with sf2 now, so I guess we'll need to work on getting setup in the repo.

— Reply to this email directly or view it on GitHubhttps://github.com/PHPFreaks/site/issues/1#issuecomment-8878871.

I'll get a base project setup, with the Acme stuff pulled out and we can roll from there.

[MisterPhilip]

Sweet, thanks @gizmola