viewflex

viewflex

Member Since 4 Years Ago

Experience Points 14,970
Experience Level 3

30 experience to go until the next level!

In case you were wondering, you earn Laracasts experience when you:

  • Complete a lesson — 100pts
  • Create a forum thread — 50pts
  • Reply to a thread — 10pts
  • Leave a reply that is liked — 50pts
  • Receive a "Best Reply" award — 500pts
Lessons Completed 238
Lessons
Completed
Best Reply Awards 1
Best Reply
Awards
  • Start Your Engines Achievement

    Start Your Engines

    Earned once you have completed your first Laracasts lesson.

  • First Thousand Achievement

    First Thousand

    Earned once you have earned your first 1000 experience points.

  • One Year Member Achievement

    One Year Member

    Earned when you have been with Laracasts for 1 year.

  • Two Year Member Achievement

    Two Year Member

    Earned when you have been with Laracasts for 2 years.

  • Three Year Member Achievement

    Three Year Member

    Earned when you have been with Laracasts for 3 years.

  • Four Year Member Achievement

    Four Year Member

    Earned when you have been with Laracasts for 4 years.

  • Five Year Member Achievement

    Five Year Member

    Earned when you have been with Laracasts for 5 years.

  • School In Session Achievement

    School In Session

    Earned when at least one Laracasts series has been fully completed.

  • Welcome To The Community Achievement

    Welcome To The Community

    Earned after your first post on the Laracasts forum.

  • Full Time Learner Achievement

    Full Time Learner

    Earned once 100 Laracasts lessons have been completed.

  • Pay It Forward Achievement

    Pay It Forward

    Earned once you receive your first "Best Reply" award on the Laracasts forum.

  • Subscriber Achievement

    Subscriber

    Earned if you are a paying Laracasts subscriber.

  • Lifer Achievement

    Lifer

    Earned if you have a lifetime subscription to Laracasts.

  • Laracasts Evangelist Achievement

    Laracasts Evangelist

    Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.

  • Chatty Cathy Achievement

    Chatty Cathy

    Earned once you have achieved 500 forum replies.

  • Laracasts Veteran Achievement

    Laracasts Veteran

    Earned once your experience points passes 100,000.

  • Ten Thousand Strong Achievement

    Ten Thousand Strong

    Earned once your experience points hits 10,000.

  • Laracasts Master Achievement

    Laracasts Master

    Earned once 1000 Laracasts lessons have been completed.

  • Laracasts Tutor Achievement

    Laracasts Tutor

    Earned once your "Best Reply" award count is 100 or more.

  • Laracasts Sensei Achievement

    Laracasts Sensei

    Earned once your experience points passes 1 million.

  • Top 50 Achievement

    Top 50

    Earned once your experience points ranks in the top 50 of all Laracasts users.

26 Mar
2 months ago

viewflex left a reply on Laravel Soap Service

@KINGKOM001 - This package provides an instantly deployable SOAP server for Laravel, with automatic discovery and generation of WSDL definitions: https://github.com/viewflex/zoap

07 Jan
4 months ago

viewflex started a new conversation BREAD (CRUD) And DDD Package For Laravel

Eric Evans' book, Domain-Driven Design (the DDD bible), provides a great conceptual framework for modeling large applications, where complexity can easily get out of hand. But how does one apply that to development in the Laravel framework in such a way that the two support rather than struggle against each other?

I've seen some good Laravel-DDD examples at the application level, but with various opinionated directory structures, and a significant focus on integrating Laravel features into the core functionality, it seemed to me that somewhere along the line, the freedom to focus on modeling domains was lost in the details of the implementation.

I decided to take a different approach, requiring no fixed directory structure, and decoupling the code from Laravel-specific features to the extent possible.

For me the starting point was to build a foundation supporting easily-configured BREAD (CRUD) and context layers, for quick prototyping of simple or complex domains - integrating base controllers for both stateful web UI and API, and offering a flexible paradigm for implementing domains, configured either declaratively or by extending component classes where dictated by the complexity of a given domain.

By using the Repository Pattern to isolate use of Eloquent, I also avoided the heavy dependence on models that I've seen in other approaches.

The resulting structure supports skinny controllers, and a standardized, easily recognizable base functionality among all application domains, whether they exist in the application proper or in packages providing specific functionality.

I'd appreciate hearing your opinions on this package: https://github.com/viewflex/ligero

Note: This is not a CRUD generator, but it does include a working demo domain with migration, seed, views, and localization, which can be published and used as a domain template. Private versions of the package have been successfully deployed in production, and the latest public release includes greatly expanded documentation.

15 Dec
5 months ago

viewflex left a reply on Money Exchange Rate

The viewflex/forex package provides live currency exchange rates in Laravel and Lumen, with configurable caching. It currently supports free and paid versions of Fixer, Open Exchange Rates, and Currency Converter API.

09 Dec
5 months ago

viewflex left a reply on Laravel And SOAP WSDL

@ZALO - Thanks for trying the package! Sorry I didn't notice your comment earlier. The example service class accepts user/password or token, checking input(s) against hard-coded values; this is where you might run whatever real-world checks you have in mind, including authentication of request headers.

27 Apr
1 year ago

viewflex left a reply on Laravel And SOAP WSDL

I feel your pain. It's what drove me to create Zoap, a Laravel package providing an instantly deployable SOAP server. Turns any class into a WS-I compliant SOAP web service, with automatic discovery and generation of WSDL definitions. Wraps the Zend SOAP components to provide easy declarative configuration of services, requiring no additional coding.

https:://github.com/viewflex/zoap

Though old and sometimes viewed as unnecessarily complex, SOAP is still widely used to provide RPC-style services, particularly in financial institutions. The variety of specifications and options, along with the lack of good documentation and community resources, often means that you will do quite a bit of research and experimentation to arrive at a properly-configured SOAP service.

This package greatly simplifies the process of creating SOAP services using the popular 'document/literal wrapped' pattern, and can be extended to incorporate other SOAP patterns. It includes a demo service already configured as an example, with a collection of Postman requests including tests.

23 Nov
1 year ago

viewflex left a reply on Package Development Workflow

You will want to start with a directory in your project root for your packages under development (i.e. 'packages'). Once you release the package, and require it in another project, it will end up in that project's vendor directory. You will need to let the Laravel project you are using for development know where the package resides, by modifying the autoload attribute of the project's composer.json file:

"psr-4": {
  "App\": "app/",
  "MyName\MyPackage\": "packages/myname/mypackage/src/"
}

In this directory scheme, the namespace, and the relative path from the package directory to the project's phpunit executable will be the same, whether the package is in the 'packages' or 'vendor' directory: ./../../../../vendor/bin/phpunit. This makes a testing workflow as mentioned by @sandervanhooft that much easier. The benefit for development and testing is that you don't have to change any paths or namespaces when you push your package to the public space for requiring in other projects.

viewflex left a reply on How, Exactly, Can I Distribute Homestead With My Project (Homestead On A Per Project Basis)

It's not difficult to create your own custom box. This would probably be the most straightforward way to provide the required environment, if none of the existing Homestead boxes are sufficiently provisioned for your project. I don't think there is a way to spare the developer from learning a little bit about Homestead and Vagrant. This tutorial presents the process in a fairly clear fashion:

https://scotch.io/tutorials/how-to-create-a-vagrant-base-box-from-an-existing-one

13 Mar
3 years ago

viewflex left a reply on PHP Interfaces, What Are They Really Good For?

An interface is just a 'contract' that lists the methods any concrete class that implements it must provide. This allows you to code to interfaces rather than concrete classes, decoupling code (a good thing). It may sound like a lot of extra work, but I've found that it really helps me to think more clearly regarding project architecture. I'm now using interfaces as much as possible, for documentation, maintainability, and my own sanity, a way to manage complexity.

For me interfaces are like a high-level map of a project, they tell me quickly what I need to know about what each class does, and how they work together - without looking at one line of real code. I don't want to count on memory to understand my own code six months from now.

Jeffrey has a great series on SOLID principles which will make the advantages in coding more clear: https://laracasts.com/series/solid-principles-in-php

As others mention, you don't need interfaces, but the idea of a contract helps to keep you focused on exactly what each class really needs from it's dependencies. Of course, it also makes sense to use abstract classes to implement code common to their extended concrete classes. As a bonus, IDEs like PhpStorm automatically provide editor cues and prompts to enforce correct implementation of interfaces and abstract parent class methods.

BTW, in the same way you extend your abstract classes, you can also layer interfaces, creating primitive ones (corresponding to your abstract classes), and more specific ones (with the additional methods that your concrete classes of that type provide). In this way any class that depends on interfaces can be sure to receive the expected functionality, however primitive or specific, with no additional baggage required.