On HTTP, Middleware, and PSR-7

[Hari KT]

Hi all, 

I would like to take your attention to a post "On HTTP, Middleware, and PSR-7" : https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html .

I believe that is a wonderful concept, so we could make use of other modules in the PHP ecosystem. I wish if anyone like the concept we could bring those into the 3.0 release ?

Also there are bunch of other nice things like

• PSR-3 Logger Interface :  http://www.php-fig.org/psr/psr-3/
• PSR-2 ( if we love to standardize the coding standard )

I also wish if someone could have a closer look on the things over fig, so things like this can be adopted.

Your thoughts ?

Thank you.

[qtguru]

Am a bit familiar with the concept of MiddleWare in Node, so I don't have much to say in the context of PHP, however I do find it interesting as we can easily connect components to modify the response and request and simply trigger the next Middle-ware. But I will read more on that however it's the Logger interface am interested in, and would be really fun to use this in Processwire, where we can log and create Adapters e.g FirebugLog,SQLog,EMailLog something like Yii. However this means we will have to wait from 3.0 when processwire finally adopts Name-spacing and the PSR Autoloading.  

Hi all, 

I would like to take your attention to a post "On HTTP, Middleware, and PSR-7" : https://mwop.net/blog/2015-01-08-on-http-middleware-and-psr-7.html .

I believe that is a wonderful concept, so we could make use of other modules in the PHP ecosystem. I wish if anyone like the concept we could bring those into the 3.0 release ?

Also there are bunch of other nice things like

• PSR-3 Logger Interface :  http://www.php-fig.org/psr/psr-3/
• PSR-2 ( if we love to standardize the coding standard )

I also wish if someone could have a closer look on the things over fig, so things like this can be adopted.

Your thoughts ?

Thank you.

[teppo]

... however it's the Logger interface am interested in, and would be really fun to use this in Processwire, where we can log and create Adapters e.g FirebugLog,SQLog,EMailLog something like Yii. However this means we will have to wait from 3.0 when processwire finally adopts Name-spacing and the PSR Autoloading.  

If it's log messages you want to catch, as long as they go consistently through the API (instead of creating separate FileLog objects, as we used to do it), there's no need to wait for anything; WireLog ___save method ($log->save()) is already hookable. Messages and errors are a different thing in ProcessWire, and catching those would probably happen using $notices.

There are few things that aren't doable in ProcessWire as it is, and we've been adding new possibilities all the time. The value of aforementioned concepts and standards, as I see it, is framework interoperability (d'uh) much more than enabling something new in ProcessWire specifically

Anyway, my first impression was that both PSR-3 and PSR-7 seem pretty solid, but we already have similar solutions in place, and whether those should be dumped in favour of PSR -- or altered to be more similar -- is a bigger question and depends on Ryan. PSR-2, on the other hand, has been discussed here a few times already, and currently it seems unlikely that we'd be adopting that for PW.

The way Matthew's post explains middleware makes it sound like an interesting concept too, and certainly being able to switch components and even share them with different frameworks etc. is a neat idea, but other than that I can't really comment on this yet.

[pwired]

Although you mention a nice concept there I hope it will never enter inside processwire

simply because those http abstractions go beyond the scope of processwire.

Processwire, for the purpose it was made, already has it's own unique concept

where you can make sites, applications, interfaces like never seen before.

[Hari KT]

@teppo My experience working with different open-source projects I have a feeling it would be nice to standardize things .

is framework interoperability (d'uh) much more than enabling something new in ProcessWire specifically

Though it says is framework interoperability group, there are a few players like Drupal, EzPublizh and various other CMS / Frameworks there. Also do have a look at the cache PSR , the PSR-5 on docblocks are always nice.

[Hari KT]

Modx going to make use of PSR standard and composer. Have anyone had a read ?

https://medium.com/@drumshaman/keeping-modx-relevant-part-one-42dc6632f86b

https://medium.com/@drumshaman/keeping-modx-relevant-part-two-15a37eab5b48

I do believe 3.0 should have bought some of these into lights.

[qtguru]

I know alot of people won't be pleased to hear this but Hari is right, Standardization is very important, that way framework interoperability can be a reality, its not fun for a dev to switch different programming practice, a good example is the Symfony Components which is easily used in other Projects, an example of such project is the MonoLogger. That way we can leverage on exisiting libraries and boost Processwire rather than building everything from scratch. however these are my personal opinions. 

[teppo]

I know alot of people won't be pleased to hear this but Hari is right, Standardization is very important, that way framework interoperability can be a reality, its not fun for a dev to switch different programming practice, a good example is the Symfony Components which is easily used in other Projects, an example of such project is the MonoLogger. That way we can leverage on exisiting libraries and boost Processwire rather than building everything from scratch. however these are my personal opinions. 

While MODX and Symfony are probably great systems, their goals are not necessarily the same as ours. I don't think that anyone here (or anyone in their right mind, for that matter) would ever deny that standardisation is a good thing, but I do believe that Ryan is doing the right thing by always putting things in the right context -- which, in this case, would be ProcessWire, it's target audience, and their needs.

Also: all good things take time. Even if we don't act instantly, it doesn't mean we won't act when the time is right. This really isn't something that is going to happen overnight, and sometimes we just need to be patient

By the way, I'm absolutely not trying to discourage discussion. I just hope that we're all on the same page here: no-one is opposed to these ideas, and I'm sure we'd all like to see them discussed even further, but especially bigger and more fundamental changes need to be properly evaluated first. "X does it like this" doesn't necessarily mean that it's the best thing for us to do, and so on.

[qtguru]

@teppo i get what you mean, am more thinking for in the long run things we should look at against 3.0 not immediate changes, also is there a forum where 3.0 discussion takes place i'd be interested in keeping up with updates and see if there's any code contribution needed. 

[WinnieB]

I've been learning Python alongside PHP, and it's good that PHP is catching up in the realm of middleware/interoperability. Coding standards are baked into the Python language, and the entire Python ecosystem (including web framework middleware) is very modular/DRY (Don't Repeat Yourself).

It will be great to see how ProcessWire addresses these issues while keeping its guiding principles - fun, simplicity, brilliant/powerful API and designer-friendliness - intact. It's worth checking out Symfony2's CMF documentation to see their approach.

Modx going to make use of PSR standard and composer. Have anyone had a read ?

https://medium.com/@drumshaman/keeping-modx-relevant-part-one-42dc6632f86b

https://medium.com/@drumshaman/keeping-modx-relevant-part-two-15a37eab5b48

I do believe 3.0 should have bought some of these into lights.

These posts are interesting as much for what they don't say as what they do. MODX may indeed be facing "irrelevance" partly because it hasn't been based on a decoupled framework...

But there's also:

• the whole Evolution/Revolution fork
• the decision to use EXTJS in the bloated/slow Revolution back end
• an LLC whose business practices and project priorities seem out of sync with the wants/needs of the typical MODX user

Also it's interesting how much the author disparages in-house innovation (developing new tools that may duplicate existing functionality) as an expression of "Not Invented Here." I like opinionated projects that take new approaches to solving problems. Maybe it's because I'm a musician, and love to see people offer their creative take on existing forms.

[Hari KT]

Hi all,

Have you guys came across http://github.com/puli/ ? I am not sure how processwire is going to make use of composer in 3.0 apart from namespace ( I didn't noticed in the newsletter or probably missed in the blog posts ) . But I believe the concept of  http://docs.puli.io/ combined with PSR-7 and composer will be a revolution in the PHP ( yet to see though ) .

I wished if processwire in 3.0 would take some of the good concepts to make things smooth and easy.