Jump to content

LuisM

Members
  • Posts

    46
  • Joined

  • Last visited

About LuisM

  • Birthday 03/17/1985

Contact Methods

  • Website URL
    luis-mendez.de

Profile Information

  • Gender
    Male
  • Location
    Germany
  • Interests
    Product and Project Management.
    Coding and trying new things.

Recent Profile Visitors

406 profile views

LuisM's Achievements

Full Member

Full Member (4/6)

80

Reputation

  1. 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
  2. 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
  3. Thank you Teppo for that detailed answer. Really appriciate it. 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 This would describe it best I guess. I actually use Wireframe as Output Framework in the Project im working on πŸ™‚ 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 Dont worry, I knew you would give great insights the moment I tagged you πŸ˜„ Have to dig into TemplateEngineFacotry code now πŸ˜‰
  4. 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.
  5. 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
  6. 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.
  7. 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
  8. 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
  9. 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 πŸ™‚
  10. @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 πŸ™‚
  11. 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 Documentation The Symprowire Wiki https://github.com/Luis85/symprowire/wiki How to create a simple Blog with Symprowire https://github.com/Luis85/symprowire/wiki/Symprowire-Blog-Tutorial Last Update 16.07.2021 // RC 1 v0.6.0 centralized ProcessWire access trough out the Application by wrapping to a Service https://github.com/Luis85/symprowire/releases/tag/v0.6.0-rc-1 Requirements PHP ^7.4 Fresh ProcessWire ^3.0.181 with a Blank Profile Composer 2 (v1 should work, not recommended) The usual Symfony Requirements Features Twig Dependency Injection Monolog for Symprowire Support for .env YAML Configuration Symfony Console and Console Commands Symfony Webprofiler Full ProcessWire access inside your Controller and Services Webpack Encore support Caveats Symfony is no small Framework and will come with a price in terms of Memory Usage and added Overhead. To give you a taste I installed Tracy Debugger alongside to compare ProcessWire profiling with the included Symfony Webprofiler So in a fresh install Symprowire would atleast add another 2MB of Memory usage and around 40ms in response time, should be less in production due to the added overhead of the Webprofiler in dev env
  12. 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.
  13. 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
  14. 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 πŸ™‚
  15. 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.
Γ—
Γ—
  • Create New...