LuisM

3 minutes ago, netcarver said:

Nice, are you using mermaid-js for the diagramming?

Yes, currently generating diagramms by code definition in the editor, but planning to let generate diagramms by parent-child relations in a future iteration.

Its good for now and me but not that user-friendly ?

Well hello,

today is the day I would like to introduce Flowti, my biggest Project I have worked on for the last 2 1/2 Years and the reason I am developing Symprowire, too. 

So, what is it all about you may ask.

• Flowti is my daily driver to Plan, Document and Execute Projects
• Flowti is my tool to work on concepts and ideas
• Flowti is my tool to present Work
• Flowti is my tool to organize and support Product Management Work
• Flowti is my digitalization Framework

To give you a glimpse about what Flowti is already capable of I attached some screenshots for you to study ? 

To make this one short, I plan to fully Open Source Flowti this year after Symprowire reaches v1.0 and will use this post as a way to show progress. 

 

Cheers,

Luis

I wish everyone a good start into the new Year. To round up this year I released v0.10.0.

The library is runnable as intended in a ProcessWire Environment and fully testable in Standalone mode for developing. 

Symprowire Release v0.10.0 - Backpain

I will publish a demo implementation next year. Hope it will be of use for some of you guys. 
 

Oh BABY... I am nearly done with wiring it all together ?

Routing is based on the Template which will ultimatly resolve to a Controller based on the Template Name.

its coming together nicely ? The Framework itself is running without ProcessWire and is capable to get a ProcessWire instance injected as a Service. Which is HUGE!

What does this mean? Once I manage to resolve ProcessWire related config inside the Kernel we can then use Symprowire to build a Testsuite for the ProcessWire Core itself!!!

 

I also managed to abstract the whole Setup away into an easy to use API for the Developer. The future Symprowire Template file will look like this

<?php namespace ProcessWire;

use Symprowire\Symprowire;


/**
 * This is the Symprowire FrontController
 * -----------------------------------------
 * 
 * We require the composer autoloader
 * Add some parameters to Symprowire
 * Execute the App with the current ProcessWire instance
 * If ProcessWire is running in debug and TracyDebugger is installed we will dump the whole executed Kernel to Tracy
 * and echo a HTML string back to ProcessWire
 *
 */

require_once($this->config->paths->site . 'vendor/autoload.php');

$params = [
    'renderer' => 'twig',
];

$symprowire = new Symprowire($params);
$symprowire->execute($this->wire);

if($this->modules->isInstalled('TracyDebugger') && $this->config->debug) {
    bd($symprowire, 'Symprowire / Executed Kernel', [4]);
}

echo $symprowire->render();

 

Nothing to add... let the pictures speak for themself (hint: we are testable)

----

On 12/25/2021 at 12:57 PM, bernhard said:

Sorry, I still don't get what you guys are trying to do here. What problem are you solving? Don't get me wrong - I don't want to discredit your work just trying to understand, maybe learn or maybe help ?

….

There are a few things I want to solve, atleast for me, with Symprowire.

- poluted global state 

- dependency injection

- clean separation of concerns

- Raw PHP in Template Files

- no standards in templating

- testable code

Due to the way ProcessWire handles his templating the global state could get pretty poluted with vars floating around and on top you will most likely add business logic to your template. I prefer a more concise and separated aproach.

As a developer I do want to use libraries from the Userland with composer to manage my dependencies and not have to wrap them into a module with the added overhead.

I need a Dependency Injection Container to have a nice and manageable way to use my Objects.

I want to use twig as template language to benefit from template inheritance, autoescaping and all the other goodies it ships.

I need proper Event Dispatching and Handling  driven by Types as Subscribers.

I want to be able to test my codebase.

Symprowire will be niche and way too much for a light, few pages webpage, but it will give you a well structured way for accessing and rendering your data outside of the admin.

Symprowire is more like an application framework but could replace the ProcessWire renderer easily and is flexible enough to just serve your templates.

In fact, I pushed the new concept to the repo so you may have a look at the codebase.

As of now, Symprowire will add ~ 7-12ms to your Request after resolving to a Controller action and gives you a proper Controller Resolver, Event Handling, Twig, Dependency Injection.

Im looking forward to release 1.0 ?

 

Project Update 24.12.2021 - Edited start post.

@MrSnoozles thanks for your kind words.

Yeah my main intent is to handle ProcessWire in a sane way with current "best-practices" in PHP Userland.

Which includes things like

• Composer all the way
• Dependency Injection 
• Migrations!!!
• Separation of concerns (hello Twig for example)
• proper Headless Content distribution

On 9/28/2021 at 3:53 PM, MrSnoozles said:

• having the PW core and PW admin be independent packages
• being able to load these packages through composer
• having proper namespacing with autoloading
• being able to use bundles for easier separation of business logic
• going headless first (PW is so close to being there although not focusing on it at all)

Nice, I had the exact same thoughts so far ?

I really like ProcessWire and it is my first go to whenever I need a MVP or an Prototype. But in the long run, or whenever I have more than 1 Developer working on the code the nightmare begins, atleast for me.

On 9/28/2021 at 3:53 PM, MrSnoozles said:

One question: How would you manage to stay compatible with future PW version? Would that be possible without additional work in the future?

I really dont know ?

The main problem is the way ProcessWire is organized, as it was never intended to be used as Dependency in another Project. So yeah, right now, whenever @ryan is in production mode and pushes new Versions I have to manually update the codebase. 

The thing is, I started to develop Symprowire because I had a Prototype in ProcessWire which acted as a Proof of Concept for some client presentations. To develop the concept and bring it to production ProcessWire just wasnt enough, I learned it the hard way ? *cough* migrations *cough cough*

So in the course of 1 1/2 year I ported the PoC to Laravel with the intent to use Laravel Spark as our Product is a SaaS with fully fledged Multi-tenancy. Unfortunatly Laravel Spark wasnt that good of a solution back in the days as it was too opinionated and the general direction Laravel as a Framework is developed... mhhh I would say is not my cup of tea. 

So I started to port over to Symfony as we worked with Symfony some years ago to develop a Marketplace supporting 72 Languages and had ~ 350 active sellers from the beginning. I would say it was a fairly big project and I felt confident to work with the Framework, but I missed ProcessWire's CMS/CMF possibilites which ultimatly brings us to Symprowire.

As of today, we ditched ProcessWire completly from our Product and went full ham with Symfony as we are using

• symfony/notifier for async notifications 
• symfony/messenger for RabbitMQ 
• api platform for our headless needs
• and all the bits and pieces symfony brings

To give you an idea, I just published a basic Fullstack Template covering all our needs. You can find it here: https://github.com/Luis85/symfony-full-skeleton

Right now, I really dont know how to develop Symprowire or in which direction I would like to go with the Project. 
I have a lot of Ideas but every idea would be a complete refactor. I thought something like, yeah just copy the Data Modell ProcessWire uses and port it to Symfony to make a new CMS based on Symfony with the spirit of ProcessWire. I really dont know right now ? What I know is, I want to contribute to ProcessWire.

 

Bump up to v0.6.0

Breaking Changes

• renamed AbstractRepository to AbstractPagesRepository
• added new ProcessWireService / ProcessWireServiceInterface as wrapper to access ProcessWire in a centralized way and to reduce wire() function calls.
• replaced all wire() function calls with using ProcessWireService

Bump up to v0.5.0 

I added a tutorial for a simple Symprowire Blog Application.
You can find the tutorial here: https://github.com/Luis85/symprowire/wiki/Symprowire-Blog-Tutorial

To keep up with development and organize the project I added a GitHub Project and corresponding Issue Management. You can find it here: https://github.com/Luis85/symprowire/projects/1

Thank you Teppo for that detailed answer. Really appriciate it. 

1 hour ago, teppo said:

I can't say that I have a strong opinion here either. Also not sure if I grasp the whole context — when you say "routing" and mention URL segments, does that mean that you create routes automatically based on page structure (I assume so but...) or that there's a separate routing setup for front-end and page structure is only reflected in the data? Or do you mean something different with this? ?

My first take was similiar to Wireframe. Adding a Template as alternate Template file and replace the render accordingly. But it didnt felt quite right, taking the tools Symfony provides into consideration. I now let Symprowire act as a drop-in solution to replace ProcessWire rendering completly. 

What this basically means is, ProcessWire will no longer be in charge about anything URL or rendering related. 
As of now Symprowire will intercept the Request and manage routing decoupled from ProcessWire. So ProcessWire will step back and act as a Data/Service Provider for Symprowire.

What I actually did here is separating into more or less 3 layers. 

• ProcessWire as Data and Server Provider 
• Symprowire as Businesslogic Backend MVC style powered by a Symfony Architecture
• a separated Frontendlayer served by Twig Templates

ProcessWire Admin will be used as Data Editor / Content Management System and Symprowire will consume this data and do stuff with it before handing over to Twig.this

1 hour ago, teppo said:

... or that there's a separate routing setup for front-end and page structure is only reflected in the data ...

This would describe it best I guess.

 

1 hour ago, teppo said:

Wireframe is my pet project and something we've used for our production sites for a while now, so that's what I'm mostly familiar with.

I actually use Wireframe as Output Framework in the Project im working on ?

Quote

 I intentionally decided not to use hooks, since I felt it was best to let the developer decide if they want to use Wireframe for everything, just a small part of the site, or something in between. In fact it's possible to skip the MVC structure entirely, and just use Wireframe for its partials and/or components ?‍♂️

I am still not sure if this should be a possibility or an option in Symprowire. Its tempting to let the Developer decide, but on the other hand I mainly create Symprowire to give a somewhat strict structure and to have Phpunit tests in the not so far future. Which would be hard to integrate if just parts could be tested. Decisions decision decision... ? 

 Another reason I am into this is the clear and concise way Symfony handles the Request/Response, it just makes so much sense for me to combine this both worlds. Take the very very strong parts CMS/CMF wise from ProcessWire and combine it with Symfony. I dunno ? just feels to be like this 

 

1 hour ago, teppo said:

Template Engine Factory may be a bit closer to Symprowire feature wise, although Symprowire clearly has a much larger scope (and is more opinionated). So not sure if any of what I've said here applies as-is ?

Dont worry, I knew you would give great insights the moment I tagged you ? 
Have to dig into TemplateEngineFacotry code now ?

 

 

Working Full-Time on the Module for this week after getting it running its just good old Symfony Development to make the Glue hold tight on ProcessWire. 
I plan to build a Blog with Symprowire next to see if everything works as expected. 

I added a small Project over at Github to keep you informed. Will continue to post release notes. For now, I edited the 1st Post as this would be my Base to develop the Blog.

Release v0.3.0-rc1

- added Webpack Encore Support
- removed Symprowire Autload condition. Symprowire is now configured to server every request except admin
- implemented recommended template structure into lib/twig 
- added more context and information to the HomeController
- added $user and $session as Global Twig Variable // both as ProcessWire Objects
- implemented example Webpack Encore Application using stimulus.js served by lib/twig

26 minutes ago, bernhard said:

I've never used symfony (only the CLI component) so I have to admit that I don't understand what you are doing here, sorry ? 

Oh hahaha, my question is more about, what would be the best method/hook to intercept ProcessWire rendering or routing to replace the Response completly.

Looking forward to your experience @netcarver ?

What I actually dont like at all right now is how I hand over the Request handling.

My idea is, to use ProcessWire as a DBAL and load Pages via a Repository to centralize modification, loading of PageData and use the Admin to create a Structure, Content and handle Templates and let Symprowire use Entities as simple DTO to reflect ProcessWire Templates.

I think this will open up a clear Migrations path later on and will make Form creation easy with the symfony/forms component.

Right now I add a replace hook on TemplateFile render() and the used frontcontroller template will allow UrlSegments to be set.

I must admit, Routing is not something I have invested much tought into yet. Maybe you guys have some ideas what could work best here 

@teppo

@bernhard

@netcarver

Release RC1 v0.2.0 -> https://github.com/Luis85/symprowire/releases/tag/v0.2.0-rc-1

• added Session Handshake to integrate PW Session into Symfony
• added $page, $pages, $input, $session, $modules, $users as member to AbstractController 
• added Symprowire autowire Services outside of userland into /lib/src and added own Namespace for the lib
• added Repositories (Pages, Modules, User) to the lib
• added UserRepository to HomeController::index() as Dependency Injection for Demonstration / as Example

I just finished to clean up the repo and pushed Symprowire as stand-alone module to GIT. 

I marked the commit as RC-1 

The Framework should work right now like every other Symfony App handling wise, with the exception of twig templates bound to the processwire directory structure.
Next would be to integrate ProcessWire Services like logger, input et all as Symfony Services and autowire them into the Controller.

Stay tuned, oh and feel free to comment ?

@netcarver oh wow thanks for the Larawire mention. Didnt knew there where similar attempts but with Laravel.

Anyways, I have a slow day in the office and wanted to clean up a bit. So meet PoC v.0.1.0. I completly encapsulated Symfony now to dont mess with ProcessWires file/directory structure and keep things clean. 
I think, this should be a good base to develop this thing further. Am happy ?

Update - 24.12.2021

After long days of reconsideration and experimenting I will deprecate the current state of Symprowire. 

I decided to get rid of my trys to integrate the whole Symfony experience as it grew pretty large pretty fast.

Whats left you may ask?

Well, the project is not dead. I am currently refactoring the whole setup to just use SymfonyHttpFoundation and Twig. I have a working proof right now, but have to polish some things first.

The whole setup will come as a simple composer package to get called via a controller.php template file. Much like WireFrame. As you can see in the picture we will use the normal ProcessWire Workflow and just use the normal PageRender process.

You as a Developer will get in control if to use the Setup for a particular Template or not. Looking forward to publish the proof. 

Cheers, 

Luis

 

Debug Dump WIP 25.12.2021

Symprowire is a PHP MVC Framework based and built on Symfony using ProcessWire 3.x as DBAL and Service-Provider

It acts as a Drop-In Replacement Module to handle the Request/Response outside the ProcessWire Admin. Even tough Symfony or any other mature MVC Framework could be intimidating at first, Symprowire tries to abstract Configuration and Symfony Internals away as much as possible to give you a quick start and lift the heavy work for you.

The main Goal is to give an easy path to follow an MVC Approach during development with ProcessWire and open up the available eco-system.

You can find the GitHub Repo and more Information here: https://github.com/Luis85/symprowire

 

I had your workflow in mind when creating the Module ? But needed a baseline to get it going.

I will update the Product Requirements, just hadnt tought enough yet how to merge the different approaches. 

My inital thought was to let the user define Modules he want to manage with the module, build an array of Modules and Folders according to the user configuration and scan affected folders.
Which will result in a structure like

• /site/migrations 
• /site/modules/XYZ/migrations

On a sidenote, I also want to add Template and Field changes done via the ProcessWire Backend under Migration Control just to support a easy "click-and-collect" Workflow. 
For example you are building some Templates via UI to test things out on your local machine, Migrations will be added automagically and after a Push to your GitRepo you will have your executable Migrations in place.

Bernhard,

thanks for your detailed and well tought answer, really appreciate it. 

I definitly see where you are coming from. 
We are working both on very different topics, you are working on a multitude of projects and you need to keep track of your modules and the various different combinations and connections between them. I am glad I dont have to deal with this ?

My usecase is a bit different as I am working on a single Installation with a well defined set of Modules and the same functions for every single user/customer. Your approach to deal with Migrations on a Module Base makes sense, yes. Thing is, I really dont like to mix Business Logic, Domain specific Logic and Application Logic hence my file based approach to solve my first need. 
My second need would be to put Modules under Migrations Control like you do. 

My primary thought was to create a /site/migrations/ folder and let the User decide which Module he wants to set under Migrations Control and act accordingly.
So moving the Module bound migrations folder into the site scope. I dunno yet ? but I will definitly support a usecase as you have in the future, just because I would need that feature, too ?

Regarding the granularity of Migrations, yes, it could end in a mess. My reasoning to seperate the different types of Migrations is to force the developer to atleast think about execution order and implications in his database change. You are forced to discipline yourself so to say, to avoid a mess ? #me #myself and #i

Pushed to Master

• renamed FlowtiMigration::createMigrationFile() to ::createMigrationBoilerplateFile()
• renamed FlowtiMigrationService::addDefaultMigrationValues() to ::addMigrationValues()
• Moved default Value creation in his own function, added default values array with all options
• cleanup

You cann now define your defaults/globals for all Templates and Fields. To set a default Value just remove '//' for your particular option inside the src/FlowtiMigrationService class.

I pushed my current default values, so please change them as you need them ?

thanks for the warm words webmanufakturer @wbmnfktr.

I am happy to walk you trough the concepts of migrations if you want. The most complexity should be abstracted away with RockMigrations and a companion.

As a note regarding my module, the FlowtiMigrationsService class has a function called addDefaultValues, I use this method to keep my migrations a lil bit lighter.

Unfortunatly, I have to maintain 2 Versions of the module right now. The public version and our internal module.

Therefore I forgot to empty the defaultValues Function.

I try to push a cleaned up Version later today with a configurable AddDefaults method.

A companion Module for RockMigrations to gather and execute Migrations in one place. !Alpha RELEASE!

Hi there,

I just wanted to share my take on Migrations and how I am using RockMigrations to make my deployments somehow manageable. 

First of all, a big shoutout to @bernhard for his efforts and accomplishments for our beloved CMS. 
We recently had a video-call and talked about our daily problems and how to handle them, with a focus on Migrations. As of now you might think 'Gosh, not another Migrationsthingy' but wait. 

Wouldnt it be nice to have a nice overview or some kind of list regarding Migrations and stuff and one place to manage them?

Speaking for my own, yes I would like to have something like this. So yeah, here we are with a Companion Module for RockMigrations. 

 

 

Product Requirements

• I want to manage Migrations on the Application level (done)
• I want to have one place in my FileSystem to place my Migrations (done)
• I want to see in which state my Migrations are (done)
• I want to have an execution order, execute migrations one by one (done)
• I want to trigger Migrations via CLI (open)
• I want to group multiple Migrations into One Migration to create Build Versions (open)
• I want to Rollback Migrations (open)
• I want to create a deliverable build out of migrations (open)
• I want to track changes to templates and fields and create migrations accordingly (open)
• I want to manage Migrations on the Module level (open)

Module Requirements

• ProcessWire 3.0.178
• RockMigrations latest
• PHP 7.4
• Composer

Current release: v1.0.2Alpha

How does it work?

On installation the Module will create a new Database Table, here we will hold information about migrations states.

Your Migrations are empty on first installation, so just click on 

You can now choose which Type of Migration you want to create, be it Templates, Fields or Pages and a according Action. 
Im still working on this function, so yeah its a lil bit confusing right now. 

The philosophy here is, every Type of Migration could be easily identified and we can Migrate on a very sepcific and granular base. As you can see in my Screenshot, I am using migrations to build an entire App from Migrations.

After creating the new Migration File, switch over to your IDE and find a timestamped .php file inside modules/FlowtiCore/migrations. 
This file just returns a simple Array.

This is all the Info RockMigrations needs to do his thing while we keep track of the execution. Easy.

Values Arrays have to follow PW and RockMigration field naming Conventions. 

To make a Migration Executable set 'boilerplate' to false.

After creation of your first Migrations your overview should be filled so lets go. We have to migrate our files in a specific order just to make sure we can create page_references and Parent/Child connections. To achieve this, Migrations are timestamped on creation. The older the higher the priority. To enforce execution order, every migration needs to have his predecessor executed and installed.

How could this help my workflow?

My workflow is based on Git, Webhooks and Git Events. So whenever I merge 'staging' into 'master', a build will be created and a deliverable should be pushed to a Server via SSH. 

The Problem with ProcessWire is the lack of support for such Workflows and Toolchains due to its User-Friendly Admin Backend which is fine for a simple website but not suitable long-term if working in a multi-tenant environment or with more developers in a dev-staging-test-production setup.

My Goal is to provide methods and ideas to support such workflows but also support a User-Friendly Interface to work with migrations.

I really hope it could be of use for someone.

Installation

I will add the Module to the Directoy once it reached a stable state.

But you can get current version at GitHub

https://github.com/Luis85/FlowtiCore

Just clone it to your Modules Directory.

The Module will create a new Database-Table on creation. The Default Name will be 'flowti_core_migrations'. To change this just edit 

const DATABASE_TABLE = 'flowti_core_migrations';

Inside the Module Class. 

Thats it, from there on just create new Migration Files, edit them and execute them.