fixes #159 phile shouldn't be opinionated about trailing/non-trailing slash

[james2doyle]

Thanks and a big +1

[Schlaefer]

In regard of testing: I have two propositions.

The first one just adds a non static \Phile\Core::redirect. Few lines of code, simple but I'm not really happy about areas of responsibility.

The second introduces a simple Response class which handles output and redirects. More lines of code, a bit more complexity but imho a better architecture if enhancements should be necessary in the future. Also the core does not generate any output/headers until the very end. This may be beneficial to plugins which completely intercept and bypass the build-in page routing and rendering.

Any opinions?

[NeoBlack]

I like the second solution, we should introduce a Response and a Request object. Currently I am not sure, what we need to change in the core, but this could be a little project for 1.4 which will contain some bigger changes.

[james2doyle]

I like the additional classes as well. Might be nice to have a "native" way to return JSON responses in plugins and such. Right now, it's a lot of header overwriting.

[Schlaefer]

@NeoBlack Your decision. Merge/postpone/reject/bring it up later as you see fit. ;)

PS: As for larger changes in future versions (1.4+) some notions that came into my mind in the last days:

• the data source (Repository\Page, Model\Page & Co.) could be a plugin too, allowing you to swap it out for an SQL backend source, JSON (API) source etc. Even if you don't do, that abstraction could be beneficial for a clean implementation
• if the Core get's more complicated to setup, an Dependency Injection Container is maybe a better solution than an Service Locator; but that's an question mark; because:
• simplicity is important, every PHP developer can slap together some kind of rudimentary markdown renderer with composer, imho that's not what Phile should be about. It should be accessible and extendable with limited PHP knowledge. For example even if there's a Response::header to set the header let Phile handle it gracefully if a self written plugin uses header(<foo>); die(); without using the provided methods/API.

[NeoBlack]

@Schlaefer thank you for your thoughts. It is interesting to read the ideas of other people, and I love the discussion which results on opensource projects like this one.

To abstract the repository and model is a very nice idea, to store the markdown in database instead of files is a nice idea, but the main feature of Phile is to copy phile on your server and it runs, without any database. but it is also nice to decide where I want to store my content. :+1:

I have long thought about whether I use DI or ServiceLocator. In the end I opted for the ServiceLocator because I found it easier for new developers to start develop plugins. DI is very great concept, I love the implementation of TYPO3 which works well with and @inject annotation in docComments.

The last point I do not quite understand, markdown is part of the concept of Phile. I think a default parser should be present.

[Schlaefer]

To abstract the repository and model is a very nice idea, to store the markdown in database instead of files is a nice idea, but the main feature of Phile is to copy phile on your server and it runs, without any database. but it is also nice to decide where I want to store my content. :+1:

I was thinking e.g. about this plugin: https://github.com/herbdool/phileDraft or maybe a service like Dropbox serving as a data backend. I don't use it but the idea is intriguing.

The last point I do not quite understand

My point was solely about plugin developers. PHP is (still) a fine goto language for intermediate web-development which offers fast gratification, and being able to use native functions explained on php.net without diving deep into framework API documentation – in this case Phile – is favorable.

[Schlaefer]

Addressed by #170