2.4 Development Questions

[FvG]

Now that 2.3 has been finished, when will you (Ryan) start developing 2.4?

According to the roadmap 2.4 will port the hole system to PHP 5.3+ which I think is great.

It says we'll get namespaces, PSR-0 and PSR-1 support. What exactly does it mean? Will it use Composer? I really think it should as it's the greatest asset for the future of PHP. We could keep the framework seperate so that others can use it (http://processwire.com/talk/topic/818-currentformer-textpattern-users-what-do-you-think-txp5-using-pw/).

I'd also like if PW used some proved libraries from (for example) Symfony (http://symfony.com/components) or Laravel (http://github.com/illuminate). Maybe because I'd love a "Processwire on Laravel (Components) with Craft-like design"

Just interested in how Ryan is going to make PW adopt 5.3, PSR + Composer will push PHP in the future and there are great libraries that are well (unit-)tested and could be used.

[Nico Knoll]

"...some proved libraries..." for what?

[FvG]

Sessions, cookies, hashing, routing, HTTP handling, cache, database, IoC, logging (PSR-3 valid) and so on .. There are so many great things you could use This would also give you the way to adopt new great concepts like IoC which allow to write ways more/ better testable code.

[WillyC]

Sessions, cookies, hashing, routing, HTTP handling, cache, database, IoC, logging (PSR-3 valid) and so on .. 

pw.aleady have proved.libraries for

all this

[diogo]

Willy, except for "and so on ..", depending of what it means

[FvG]

Just a suggestion Even if we keep the code it would be good to Unit test the core and make the framework available on composer. Though interested in what Ryan says.

[teppo]

Just a suggestion Even if we keep the code it would be good to Unit test the core and make the framework available on composer. Though interested in what Ryan says.

Suggestions are very much welcome and I'd like to hear what Ryan thinks about this too. On the other hand, like @WillyC pointed out above, PW does many - if not all - of the things you've mentioned here very well and still has a lot of potential to grow and evolve.

The way I see it, being geared towards slightly more specific needs than other popular frameworks (namely content management) allows PW to focus on what's really important there instead of trying to become everything for everyone. Don't get me wrong, though - I'm not saying that all other frameworks are somehow chaotic. I'm sure they all have their strong points and specialties, my point is that so does PW.

Anyway, there have been discussions about integrating other libraries with PW around here and some people still use things like Flourish for certain tasks. I've personally used parts of Zend Framework in the past, but these days I seem to find very few reasons for that anymore, except for certain very specific things. PW is flexible enough to let you work exactly how you prefer and if you prefer to use other tools for some tasks there's nothing stopping you (even if those aren't bundled with PW code.)

Last but not least I'd like to point out that unit tests for core code are on their way. Don't worry, we'll get there

Edit: Forgot to mention that I'm not (yet) familiar with Composer, though it does sound interesting. Will have to take a closer look. Thanks for the tip!

Edited March 21, 2013 by teppo

[ryan]

Now that 2.3 has been finished, when will you (Ryan) start developing 2.4?

Once the multi-language page names module is stable and in production use. So will probably start developing the namespaces stuff in May. 

It says we'll get namespaces, PSR-0 and PSR-1 support. What exactly does it mean? Will it use Composer? I really think it should as it's the greatest asset for the future of PHP.

Namespaces are the primary aim, with PSR-0 being a natural extension of that. I plan to shoot for PSR-1 too if it looks like it'll benefit our audience. Also as a natural extension to these updates, I am interested in supporting Composer, and will do so if possible. I agree it's a great asset for PHP, though am less certain if it's as much of a draw for ProcessWire's primary audience. Throughout all of these 2.4 updates, I feel a lot of care will have to be taken to balance these updates with other improvements to the system. After all, our audience is primarily web designers and developers, and less purely PHP coders. I think a majority of our users doesn't actually care about namespaces, PSR standards and Composer, so I don't want to get too far off track, even if I personally have a strong desire for these things. But the driving aim of 2.4 is to help ProcessWire benefit from PHP 5.3+ as much as possible. This likely includes all of the things outlined. 

We could keep the framework seperate so that others can use it

I've always been interested in this. PW started as just the content framework, and underneath it still is. I'd like to retain and reinforce those roots. But don't think I want to actively maintain PW as two projects until there is real need for it (just as a matter of resources). 

I'd also like if PW used some proved libraries from (for example) Symfony (http://symfony.com/components) or Laravel (http://github.com/illuminate).

I'd like to make it easy for people to integrate components if they want to, and I think Composer is probably the way to do that. But don't currently see a need for any of our core components to come from another framework. Though I'm always open to the idea if there is a real benefit to our users. 

This would also give you the way to adopt new great concepts like IoC which allow to write ways more/ better testable code.

IoC is not a new concept. ProcessWire was written with an emphasis on best practices, patterns and concepts like this, everywhere beneficial to the project goals. 

Even if we keep the code it would be good to Unit test the core and make the framework available on composer.

The primary need for unit tests in PW has been with the selector engine, both DB and in-memory, and the consistency of the two. Luckily this is an active project, and it has already been hugely helpful and influential in ProcessWire 2.3 (thanks to Nik). In fact, I would probably consider the issues discovered and resulting solutions the most important upgrade to come with ProcessWire 2.3. 

[apeisa]

I have had few tests with Composer and gotta say it is pretty amazing.

Just plip and plop and all needed libraries with right versions are downloaded!

[ryan]

Forgot to mention that I'm not (yet) familiar with Composer, though it does sound interesting. Will have to take a closer look. Thanks for the tip!

There's really not much to it, it's nice and simple. This article is a great intro to Composer: 

http://blog.fortrabbit.com/handle-your-dependencies-with-php-composer/

[diogo]

Speaking of fortrabbit. I already emailed them telling about the change that has to be done on pw's .htaccess to install it there, and they answered that they will make sure to include pw specific insructions on their new docs. 

[FvG]

Thanks for your answers! I think I like the idea of using popular packages because I do quite a lot of PHP dev using Laravel .. The current way seems pretty much convincing and right for PW.

@Ryan

Well, I don't know. But people love it (IoC) at the moment Two projects? You could keep it the way it is and just split it (https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo). But I don't know how you would publish just the framework

[petsagouris]

Hello all, first post, nice to be here. Thanks for Processwire.

@ryan How are you thinking of going about namespacing and autoloading in Processwire? Isn't having the Wire class being the mother of all classes making this tricky?

While you are on the standards issue, why not go for PSR-2 too ? Common coding style would benefit everyone.

[diogo]

Hello petsagouris. Welcome!

I knew Ryan referred to this briefly somewhere... here it is http://processwire.com/talk/topic/1931-recommended-php-style-guide/?p=18141

[petsagouris]

Oh, no PSR-2 then... thats a little bit sad. Thanks for the link diogo.

[ryan]

I like and support code standards, especially the PSR ones. PSR-0 and PSR-1 affect the external use of your code, and provide consistency in how people access your code from the outside. I think these are important standards and am very enthusiastic about them for the most part. 

PSR-2 is not in the same class. It's a good standard, but is more about internal style than external access. It's one of a few good standards to consider if you are starting something new, especially with a team. 

But if a project has already adopted a style standard, it would be silly to change from one good style standard to another. The point of standards is unchanging consistency. Changing style standards is counter to the purpose of style standards. I don't think the committee behind PSR-2 would suggest changing from another good style standard to PSR-2. But I do think they would suggest PSR-2 as a solid style standard for new projects, and I would agree.

However, PSR-2 is not a clear choice even for new projects. It is somewhat controversial in that it's leaderless committee-design, full of compromises making concessions to differing opinions that don't usually go together. I think the committee-design is apparent in the resulting code style. I'm sure the folks behind it would agree and admit it is a lot of compromise. In this respect, I think it may be weaker than some other style standards, but that's always subjective. However, to focus on how or where it was designed is to ignore the point of the standard. So I very much respect what they were trying to do and have done.

I hope that PSR-2 will survive because I think the intentions are good. Though I'm not confident it will be so common 5 years from now. But I think PSR-0 and PSR-1 are here to stay. I hope that folks can understand why it would be a counterproductive (even disrespectful to the purpose of standards) for an established project to change from one internal style standard to another.

[petsagouris]

Yes I too believe that the intentions behind the PSR-2 are good mainly because it is a good thing to have if there are PSR-0 and PSR-1 standards in-place that promote code segmentation and proper focusing on the parts of the libraries. I am sad about PSR-2 being basically turned down in Processwire because having to deal with more than one source base (I am an avid open source stalker and minor contributor) hinders the ability to contribute by having another layer of adjustment before I get to see what is going on, that being the visual aspect of the code.

But my main question was about how you think that namespaces in Processwire will be structured? Are there going to be big changes? Anything the community can help with?

[ryan]

I am sad about PSR-2 being basically turned down in Processwire because having to deal with more than one source base (I am an avid open source stalker and minor contributor) hinders the ability to contribute by having another layer of adjustment before I get to see what is going on, that being the visual aspect of the code.

I understand. Well the good thing is that our code standards are mostly similar to PSR-2, without some of the oddities it has (though I suppose that's subjective). I've found that I can go to/from PW <-> PSR-2 largely with simple search/replace, so I have no problem if people submit PSR-2 code. One of the nice things about code standards is that they are generally consistent and predictable, so going between different standards is not difficult. 

But my main question was about how you think that namespaces in Processwire will be structured? Are there going to be big changes? Anything the community can help with?

Thanks for your interest in this. I haven't yet started here, though know that mindplay.dk has done some work in this area and ProcessWire. Ultimately I want to gain the benefits of namespaces in PW without changing the way that people use the API. If people have to \Start\Doing\Lots\Of\This in order to use PW for typical web development, then it's a failure. The end goals are in place but not yet the whole plan. The plan should start coming together within the next 1-2 months though. 

[petsagouris]

The solution to the deep namespace problems is just a matter of using namespace aliasing.

Code standards are great and a great tool to check on them is PHP_CodeSniffer. In an IDE such as PHPStorm (Ryan I am so sorry) you could just put the formating rules in place and just tell it to reformat the whole thing.

But this is all details compared to converting the source to PSR-0.

[ryan]

Namespace aliasing is fine, but I'm really hoping to isolate our users from having to think about namespaces at all (unless they want to specifically use something outside of PW). I would gather that most of our users don't care or know about namespaces, so any extra technical verbosity reflects poorly on the simplicity of the system. I don't want people to have to have 'namespace' or 'use' statements at the top of every template file (unless they want to, again), but module files are ok. Not sure if that's even going to be an issue. 

[petsagouris]

@mindplay.dk Could you please share what type/amount of work you've put into the effort to namespace Processwire's source?

(Maybe this belongs in another topic all together?)

[Hari KT]

Yey, nice time to get involved in ProcessWire. I have been looking at Processwire for a recent project. It is really nice from a user perspective hiding all the complex functionalities. Amazing work guys. I don't say you move to use this or that ( Though I am more inclined towards Aura ).

Composer is really a nice tool, and when we go with composer and you install it is always good to keep the files in vendor folder itself. Some of the things in my mind are

1. Flexibility to move the index.php to outside the main folder. So only index.php is the only file lies there.

else vendor folder will be visible to the public . May be readmes and all .

2. When working on aura v1 , we installed the packages in the package folder itself. But that is a hard way to manage. So we started with http://github.com/auraphp/Aura.Includer/

So it will be nice to have something like adding a certain configuration file in the module of PW which helps to recognise the file is processwires and which needs to be loaded via same ?

Also does the 2.4 development is finished ? There is PSR-4 also coming, which reduces the size of the namespace stuffs.

\ProcessWire\Event\Manager => src/Manager.php ( PSR-4 ) than the previous one /src/ProcessWire/Event/Manager.php

I am looking forward to contribute to PW aslo please choose PSR-2 also. It is all about future and how we all PHP community work ( For I contribute to Aura, Symfony, Zend etc life is easy ) .

Thanks

[pwired]

Looks like a post for dev talk, yet another php framework.

[Hari KT]

@pwired sorry.

I was just trying to ping the ideas I have when dealing with composer. It was not trying to move to any framework.

Thank you.

[ryan]

Composer is really a nice tool, and when we go with composer and you install it is always good to keep the files in vendor folder itself. Some of the things in my mind are

I look forward to getting ProcessWire compatible with Composer. That's one of the things I'd wanted to do with 2.4 though other priorities for ProcessWire have gone ahead of it and likely won't be supporting it till after 2.4, but hopefully soon after. We may need to make changes to directory structure, but I'm averse to doing anything major there as I think we need to give priority to what's best for the web sites that ProcessWire powers over what's best for Composer. But we'll do what we have to do, just always in the context of our intended audience over Composer's (which have crossover, but are also different in many ways). Our audience veers much further towards web developers than dedicated PHP coders. Most of our audience is not integrating multiple PHP projects, but we do want to better support the few that are.

Also does the 2.4 development is finished ? There is PSR-4 also coming, which reduces the size of the namespace stuffs.

2.4 development is pretty much finished. Just trying to work out all the bugs before releasing it. Though I think it is already just as stable as 2.3 for the most part. I am also very interested in evaluating PSR-4 for ProcessWire. With regard to PSR-2, I'm less enthusiastic. Standards are great, and I support the PSR-2 standard for new projects looking to adopt a standard. But I think it's silly for projects that have already adopted a standard, as PSR-2 is a lot of compromise. ProcessWire's own code standard doesn't compromise so much, and in our context PSR-2 is a downgrade. However, I also see it as largely a non-issue. I don't care what standard people contribute code in, as IDEs make it largely irrelevant, at least for the way we merge code here. PhpStorm converts code to ProcessWire's standard automatically. I just encourage people to code in a standard that they find most readable and usable for them, so long as it's consistent.