Download the PHP package sergeyugai/backpack-fields-as-classes without Composer

On this page you can find all versions of the php package sergeyugai/backpack-fields-as-classes. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package backpack-fields-as-classes

Better field/column syntax declaration for Laravel Backpack

This is a drop-in solution for Laravel backpack to replace column/fields declarations-via-array with object-oriented approach. Allows your IDE to help you write that stuff.

This version is compatible with Backpack 4.1 and above; for older Backpack versions, use 0.3.* versions of this package.

TLDR: With this package, you can write Backpack code like this:

Benefits:

Installation

How to use

There are 3 types of classes in this package:

I'll explain their usage, but first let me convey the basic idea - instead of creating array like so:

you use provided classes to construct object with the same configuration (as array above), but instead of setting array keys you call object methods and pass in values, like so:

So we have 1 class per field type and per column type.

Fields

You can create field by either creating new object or calling static method make(). They accept two optional methods - field name and field label.

Via constructor:

Via make() or name()

After that, you can chain various method calls. For instance, you know that text field can have "prefix" key - you can chain that like so:

In this example you can omit 'Title' because backpack is going to provide this label automatically based on name:

Or, if you want more clarity, feel free to not pass anything to constructor at all and instead pass name separately:

You can call ANY method, even methods not stated in documentation, even if method does not exist in my classes. The reason for it is that if you decide to use custom field, you can create your own declaration like so:

and that is going to be translated to array format understandable by backpack:

However, if you write your custom field, feel free to create new class and declare available methods for your fields:

Columns

Columns behave exactly the same way as fields:

If you use $this->crud reference, you have to add asArray() in the end:

If this package gets popular, I'll submit a PR to Backpack to fix this so that there would not be "asArray()", but for now that's how it is.

Field collections

One of the biggest issues IMO with readability of Laravel Backpack code is that there are sometimes a lot of repetitive things - for instance, if you use tabs, you could have lots of repetitive lines like:

or you may want to configure numeric fields in a similar way, or... whatever else you may want to do.

So what you can do is put all those fields into a special collection (or create them using builder method of that collection - i'll show both examples) and then call methods on that collection - and those methods will be applied to each field.

Create collection from existing fields:

Create field of specific class (in this example, I create two fields of NumericField class):

And then you can apply whatever attributes that are the same:

That's it - this collection knows how to represent its contents to Laravel Backpack's CRUD.

You can mix and match FieldsCollections of different types, but its up to you to control that specific field actually supports a passed parameter (although its usually not an issue since its safe to call non-existing methods on any field).

Extra perks that you get

Besides having a nice object-oriented declaration, IDE auto completion and ability to quickly jump into classes for more info, there are couple more things:

$field as object

If you've written your own views for fields, you know you have to deal there with array as well. However, if you use these classes, your $field variable can be used as object as well, allowing you to implement your own helper methods there.

Add your own methods!

You don't have to stick to helper methods just for custom views - you can extend classes however you like and implement all sorts of other helper methods, syntax sugar, etc.

Even more readability

To improve readability, I'd suggest doing something like:

This way, you can add/remove fields by commenting/uncommenting a method call, and you also get "one method is responsible for one field declaration", which may be clever for some methods with complex logic. Also gives your crud setup better overview. Then again, its just a matter of taste.

Rationale

Well, for the following benefits:

  1. IDE auto completion - the biggest reason for this, really
  2. Readability can be improved (since you can subclass my classes and add some sugar syntax)
  3. When building your own views for fields, you can use $field as object, rather than array, therefore you can implement your own helper methods here.
  4. Auto generation of fields - yeah, we auto generate all the field/column classes, I did not write actual fields manually. About that - below.

More discussion is here - https://github.com/Laravel-Backpack/CRUD/issues/2604

Code generation?

Yes, that's quite important - pretty much all the fields and columns are automatically generated from backpack's docs. Which gives us benefit of speed (I would kill myself if I had to write each field/column class manually), but there is a chance that some of the fields did not get generated well - either help me by issuing a PR or extend the field in your project and implement/override methods.

Backpack documentation for fields is column is quite consistent in its format (thus code generation was at all possible); if in future Backpack author/contributors make it 100% consistent, it may drastically improve the quality of this package as well.

Anyway, you can play around with automatic code generation yourself. To call it, you just issue:

This way, for instance, you can substitute fields with older versions of backpack, that is - if documentation had more or less the same format. The generator itself is in MainGenerator.php file, which reads documentation line by line, acting as a state machine and gathering information on fields.

What is supported?

Currently we support fields and columns. As list grows, I'll add more stuff here.

Tests?

There is very little testing; if this gets popular and backpack documentation is updated to better structure, then I'll add some tests, which would probably be autogenerated as well (at least partially) for all those fields and columns.

Contributing

Currently this project is just a helper to me, but pull requests are welcome.

You could help with:

  1. Docs (add jokes, remove jokes, make things more clear)
  2. Testing
  3. Extending functionality
  4. Bringing more syntax sugar

You could also help indirectly by making PRs for backpack's documentation to improve code generation for this package - that way you'd both help here and in backpack.


All versions of backpack-fields-as-classes with dependencies

PHP Build Version
Package Version
Requires php Version ^7.1.3
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package sergeyugai/backpack-fields-as-classes contains the following files

Loading the files please wait ....