Can Processwire substitute an application framework?

[Neo]

There have been some interesting discussions before how to use Processwire for application development; i.e. the typical user login/logout scenario with a set of different roles and related capabilities. 

The question I was asking myself in the last couple of days while skipping through the Laravel documentation:

Can Processwire fully replace an application framework like Laravel?

Some aspects have been discussed to some extent some time ago in 2012. 

Would be interesting to know if in 2016 any developer in the community has completely replaced a "traditional application framework" with Processwire.

[Craig]

Based on own experience as well as observing some topics on here, I would say "yes, but...".

The "but" is that certain things need to be done differently, and other things need to be thought about:

Code

Where will the code that handles the app's business logic be stored and how will it be structured? Bespoke PW modules or use template files?

Data

The data that you will be storing - what does it looks like? How will it get from the source into the database? What output or reporting requirements are there?

URLs

Have one or two main entry points and call your custom code? Or have a new Page for most/all URLs.

Automatic page name generation

Every page has to have a name, and if many pages will be created using the API what is the naming scheme?

Re-use admin vs creating custom front-end

There's been some talk about this very recently, and the route chosen may depend on: who your audience is, what level of branding is required, and what functionality is available to who.

Having said that a lot of the stuff you need from an app framework is already there. Sessions, Users/Permissions, the data layer, output, templating, and other things I can't remember.

One thing I've found missing is a robust generic form validation library. I don't like the config format of valitron, so currently using a slightly modified simple-validator.

At my company, we've built various SaaS apps and CMSs over the years using CodeIgniter. More recently though, we have used PW where CI may have previously been chosen.

Perhaps an interesting example is a recent project where we used only the PW back-end. The branding was changed a bit, but there was no front-end at all. The main function of the app was to generate an HTML5 product showcase/catalogue/datasheet browser, for use on tablets (built with Backbone JS and JSON datasource). The PW admin was perfect for users managing the data. We built a bespoke Process module for the back-end that allowed users to preview and download the HTML5 app.

[LostKobrakai]

The thing I'm currently missing the most is probably a clear path to testing, which is still not the easy thing even in other libraries. Also you need to consider, that you'd need to implement any application logic (and it's structure) on your own, where other frameworks might already give you a predefined path e.g. for handling domain-events or queuing messages or just about where to put certain parts of the application. Validation is also a thing. I'm using nette/forms here, to have form generation and fronend-/backend validation covered.

[teppo]

Would be interesting to know if in 2016 any developer in the community has completely replaced a "traditional application framework" with Processwire.

Sure – where I work at we did exactly that, and haven't looked back since.

First of all, it's important to understand that at it's core ProcessWire is a (web) application framework. We prefer to call it a content management framework, but that's not very far from what most web applications do: they store, process, and output content.

The way I see it, the main difference to so-called traditional frameworks is that modelling and handling data is a built-in feature, not something you have to reinvent on a case-by-case basis. I have rebuilt a couple of old projects from the scratch using ProcessWire, and in all of those cases this has saved me a lot of time and made most of the model layer obsolete.

Before we started using ProcessWire we were doing sites with another CMS and custom applications with Zend Framework. At the beginning I had this idea that we would use ZF for "apps" and ProcessWire for "sites", but in just a few short months we realised that there just wasn't anything we could achieve with ZF that couldn't be done, usually with less work, with ProcessWire. Sure, sometimes we pull other libraries into the mix, but that's not a shortcoming; in my opinion it's just good design

Regarding some of the things that have been mentioned here:

• One thing I was originally missing from Zend Framework was a clearly defined structure. Built-in "one file per template" concept is great for simple sites, but that's just about it. This is why I built the original version of my MVC project. It's not perfect, but it has served us well for years.
• To get most out of ProcessWire you really should be using it's data modelling abilities. Sure, you can still mock up your own data structures and write SQL to fetch content from the database etc. but that's kind of missing the point: ProcessWire makes data modelling a breeze and the selector engine is both flexible and secure.
• Some users prefer to build custom management panels, but in my opinion that's another thing you should try to avoid. ProcessWire's admin GUI is flexible and extendable (see Process modules), and again: in most moderately sized projects it can easily save you days of work.
• For routing you can use page URLs, but I'd also suggest looking into URL segments. For me, coming from the world of Zend Framework, templates are a lot like controllers and URL segments make it easy to implement the concept of actions
• Try not to invent your own access management system. ProcessWire has a very good implementation of RBAC already in place, and if you need more flexibility, I'd suggest looking into modules such as Dynamic Roles and/or User Groups. Rolling out your own solution is risky, tends to cost a lot, and just generally speaking is a very bad idea.

Form validation has been mentioned twice here already. I don't have much insight into this, except that in the beginning we used to build forms using Zend Form, which has it's own validation built-in. That was always a bit tricky (not because of ProcessWire), and these days we use Form Builder for pretty much every form-related need. Sure, it's a commercial module, but it has saved us so much time that the price is absolutely not an issue.

In my opinion the answer to your original question is yes and no: ProcessWire can't substitute an application framework because it is an application framework

[LostKobrakai]

Just some additions to teppo's point 1 / 4 (mvc and routing):

In my current big project I'm using a hybrid strategy, where simple sites just use the default "file per template" – even though we have a dump router in the beginning to allow for different folders based on the rootParent – and for more complex pages / page-structures I'm using FastRoute in those template-file to route different urlSegments to a controller class. This way I don't need to roll a controller class for each and every tiny page, but still have the option to fall back to such a class if the need for more structure is there.

[Neo]

What I really like about PW is the abstraction of data-handling; no messing around with database modelling, which obviously comes with a downside as well: You should do it the PW way. However, the clean API is great to access and manipulate your data if you compare this with the messy approach of other frameworks.

Composer integration will be a big step forward.

Does anyone know when we can expect a stable version of PW 3?

[LostKobrakai]

Take that step right now and simply include "require __DIR__ . '/../vendor/autoload.php';" in your config.php or init.php. Until composer pw modules will become more often this is essentially what pw 3.0 does in terms of composer support.

[Jonathan Lahijani]

Coming from a Rails background years ago, I think it's best to stick with web application frameworks for any web applications that will have heavy iterations and multiple team members.  With a webapp framework, you get a testing suite, migrations, ORM, REST, MVC, specific deployment tools and many other necessities.  You would have to re-do all those with ProcessWire.  Furthermore, using pages to act as a router doesn't feel right.

"Use the best tool for the job" and all that.  

[JeevanisM]

bumping this in 2020 ? ?

[bernhard]

On 6/3/2016 at 3:23 AM, Jonathan Lahijani said:

With a webapp framework, you get a testing suite, migrations, ORM, REST, MVC, specific deployment tools and many other necessities.

True. At least we got Migrations and RockMigrations now.

On 6/3/2016 at 3:23 AM, Jonathan Lahijani said:

Furthermore, using pages to act as a router doesn't feel right.

Why not? Does that feel more like a router?

$this->addHookBefore('ProcessPageView::pageNotFound', function($event) {
	$url = $event->arguments(1);
	
	// ensure trailing slashes?
	if($url[-1] !== "/") $this->session->redirect("$url/");
	
	// prevent pageNotFound to fire
	$event->replace = true;
	switch($url) {
		case: '/my/route1/': return $this->route1();
		case: '/my/route2/': return $this->route2();
		default: $event->replace = false;
	}
});