Latest Posts

Before diving into what should be in the docs, let's define what you should more or less know before using Osm Admin.

There are four types of people who will read the docs: power users, developers, vendors and contributors.

Here are my thoughts on product backlog and roadmap.

Implemented in Osm Admin:

• new ALTER TABLE algorithm
• NULL to non-NULL data conversion
• new query test suite

This time, I tackled adding an explicit property to an existing table, and then making it non-nullable.

It raised the need for data conversions - additional handling of the existing data - or otherwise, the database engine fails, or the data becomes invalid.

And it made me split migrations in two parts - the one that runs before the data conversion, and the other one that runs afterwards.

While working on diff algorithm I noticed a certain pattern that I use over an over again.

Using this pattern, I implemented notification table diff.

Finally, I rearranged diff/migration code for better code readability.

Yesterday, I moved the table creation code into new schema diff migration engine.

Now, working on notification table migrations.

This time:

• I found out that the whole search index creation should be done during indexing, not migrations.
• I refactored diff algorithm and made it much easier to read.

Before digging into property diff algorithm, let's dig into how exactly it's used, and what other property-related logic is there.

Yesterday, I continued working on schema migrations:

• implemented table diff algorithm;
• took into consideration table renames.

After a system update, I've got some problem with my laptop, and one thing to check was system log files.

This got me thinking: what makes a good log for my own application? And I think that application logs are as useful as they are able to answer potential questions I may have when an application is in production.

Let's think what kind of questions I might have, and what information might be useful to answer them.

Recently, I fixed numerous issues to make the first migration tests work.

Then, I started implementing the schema diff algorithm - the basis for schema migrations.

More dots got connected in the schema migration design, see this post for details.

Then, I tried to return to TDDing it, but strange errors met me there, so I left them to be resolved in the next piece.

Schema migrations are going to be generated and executed automatically under gulp watch. It will result in lots of tiny migrations: add a column, change its type, make it not nullable, and so on.

It's convenient during development, but it might be not optimal to reapply in production. Indeed, it's better to convert a large table to new structure all at once rather than running a conversion for each of the tiny migration.

This observation contradicts the previously stated migration workflow, so let's update it.

In spirit of TDD, I started with a meaningful, but failing test that is reasonably fast. Then, I worked to make it green:

• implemented the loading of schema fixtures from the codebase;
• worked on generating migration files.

After drafting some ideas of how the schema migrations should actually work, let's start implementing it in TDD way.

The goal of the current iteration is to adjust the database schema and preserve/convert existing data according to any changes in schema classes, grids, forms or indexers.

This post presents some thoughts how it might work with class definitions.

After finishing the iteration "#17 Minimum UI", I revisited the goals and the scope of the minimum viable product, and picked the most pressing task for the next iteration - "#18 Database Schema Changes".

I implemented the last user action that is typical to a CRUD application - object deletion.

Done:

• routes responsible for creating new products, and modifying existing products
• incremental indexing
• cloning query objects
• INSERT INTO ... SELECT ... statements

After 3 days of intensive work, I've got dot syntax working!

Along the way, I refactored the query internals once again, which reminds me a heuristics saying that you've got to implement something three times to get it right :)

New query implementation uses the concept of formulas - SQL-like expressions used for selecting, filtering and sorting data. Currently, formulas are quite limited, but with time, they should be a really powerful feature.

I decided to support selecting, filtering and ordering by properties of a related object using dot syntax: product.price, parent.level. This syntax will automatically join the table that stored related objects.

I realized that implementing joins requires a better query model than my current naive wrapper around Laravel query. This article describes the new query model.

This article is about running SELECT and INSERT queries on data objects stored in the database.

In short, use the query() function. It runs on top of Laravel Query\Builder. It handles the mapping of data class properties onto table columns, and initiates the computation of indexed properties.

Currently, you can only SELECT and INSERT, other operations are coming soon.

Today, I implemented computation of indexed properties during insert. The implementation dictated some changes in indexed property definitions compare to the initial design, and how indexers are reflected into the data schema.

Also, I implemented a table query class working on the top of Laravel Query\Builder. More about it next time, for now I'll review how indexed properties are computed during INSERT operation.

It's often needed to compute, or index, data in database tables based on data in other tables.

This article is the first sketch of a consistent indexing solution.

I've finished refactoring how Osm Admin stores data objects in the database. Also, in order to support multi-website, multi-vendor, multi-language applications, I've introduced the concept of scopes.

Most reasoning from the first version is still valid, so let's take a fresh look of what's changed.

I developed dehydrate()/hydrate() functions for a very practical need - storing the data class schema:

• in cache - to reduce processing time spent on reflection;
• and in database - to compare current and new database schema, and only add new tables and columns.

This article describes the information stored in the schema, and unit tests that I prepared in order to be sure that schema classes are property hydrated.

Recently, I developed a couple of helper functions for transmitting PHP objects over the wire, and saving them in database records:

• dehydrate() - recursively converts an instance of a PHP class to a plain untyped object. Then, store the plain object in the database, or convert it to JSON and send it to a browser.
• hydrate() - recursively converts a plain untyped object back to a PHP class instance. Use if after decoding a JSON received from the browser, or after loading a database record.

This article describes how to use these functions.

When active, modal elements - dialogs, pickers, or AJAX spinners - need to prevent user interaction with the rest of the page.

A common approach is putting an overlay <div> under the modal element covering the rest of the page, as a click shield. However, user can still navigate the page with the keyboard.

Today, I implemented a better solution by capturing mouse and keyboard events outside the modal element, and keeping focus inside.

Currently, I'm working on Osm Admin package, and I need a module to inject its HTML markup around some well-known place in a Blade template. However, Blade template extensibility is not a problem that's specific to Osm Admin project. It's a generic problem. Let's solve that.

As described in Migrations, most data objects of the same class will be stored in a database table.

But what about subclasses? In an e-commerce application, bags, dresses, and digital products, collectively known as subclasses, are all products stored in products table, and they may have bad-specific, dress-specific or digital product specific properties that should also be stored there.

This article describes how subclasses are defined and stored in Osm Admin.

Different data classes have repeating structural patterns. For example, most data classes stored in database tables have the auto-incremented id property. Use PHP traits to effectively introduce the same properties to different data classes over and over again.

I partly implemented data schema migration. It takes data class definitions, and incrementally creates or alters underlying database tables.

The article below describes how schema migration works, and what's not implemented yet, but most probably will be.

Note. This topic is continued in the new article.

After you got a project up and running, let's have a look what's inside. Every directory has its purpose. Learn where to put your creative efforts!

Note. This post is moved to Osm Framework documentation.

In Osm Framework, an application is a set of modules that you run as a whole. There are several applications defined in the project, each having its own PHP class. Mostly, deal with the main one, Osm\App\App. Beside the class name, every application also has a name, the main one is named Osm_App.

Access the current application object, and the main parts of Osm Framework, via the global $osm_app object and its properties. Add your own long-living objects there. Run an application using its HTTP or console entry point, or using Apps::run().

Note. This post is moved to Osm Framework documentation.

Modular software development is a well-known practice of dividing your application into several modules, each doing one thing, and doing it well. It increases readability and simplifies maintenance, as application concerns are fully separated from one another, easier to reason about, and to debug.

Modular development also encourages reuse. It's like a puzzle. Using one set of modules, you'll get an e-commerce application, using another set of modules - you'll get a blog application.

Note. This post is moved to Osm Framework documentation.

Using dynamic traits, customize anything. Inject your code in the beginning, in the end, or instead of any standard method. Even more, add new properties and methods to the existing standard classes.

Note. This post is moved to Osm Framework documentation.

Computed properties are one of Osm Framework pillars. They help to execute code only once, and only if it's actually needed. Computed properties control object serialization and caching. They provide meaningful insights into class interdependencies. Finally, computed properties are easy to test.

Note. This post is moved to Osm Framework documentation.

Osm Framework uses Monolog library for logging. Use standard loggers defined in the $osm_app->logs object, or add your own. Control logging in the settings.{app_name}.php and .env.{app_name} files.

Note. This post is moved to Osm Framework documentation.