Latest Posts

I stopped working on the Osm Admin project, for financial reasons. Did it hurt? A lot. Was it necessary? Unfortunately, yes. This post is a short retrospection on this matter.

I waited for this day too long. Today, I've tried out GitPod, and made it work for a project based on Osm Admin.

Today, I reiterated on what's left in this iteration, and finished the side menu view, and created a trivial home page for the admin area.

After getting the main branch all-green (tests pass, CLI and UI works as expected), I decided that from now on, I'll keep it always green, and use feature branches for all major development.

Then, I started implementing the main menu of the admin area.

Yesterday, I created a template for new projects powered by Osm Admin.

This way, you can create and publish a project in minutes, just follow the README. Yay!

Yesterday, I identified the need to have some syntax in a formula query to join a notification table.

I'm still working on new Query::joinInsertNotifications() and Query::joinUpdateNotifications() methods.

I wanted to implement incremental indexing in one go.

Not so quick.

I hit some major roadblocks, and I'm working on removing them, one by one.

Use deleteAll() method on a search query to, well, delete all entries from a search index.

Yesterday, indexers started listening to query inserted, updated and deleted notifications and creating records in notification tables.

Now, saving a product complains:

Table 'admin2.zi9__products__inserts' doesn't exist

Fair enough. Let's create it.

While testing notification logic in Osm Admin, an exception is thrown in $db->committing() callback, and the logic in $db->rollback() fails.

Let's review how transaction callbacks work, and fix it.

Yesterday results:

• POST /create route handles the input of new object form.
• A decision to keep faceted navigation and search out of the editing page.
• Sending table change notifications.

I've got a little more organized, then fixed an error in selecting all products, and implemented filtered URL generation in the browser.

A list of references to the most useful blog posts about Osm Admin and Osm Framework. One day, they'll be a part of the official documentation.

Progress messages stopped working, and I fixed that. Then, I implemented a safety measure that prevent accidental deletion (or other operations) on all objects.

In Osm Admin, I've finished implementing editing behavior of input and select controls.

For other control types, a step-by-step guide is prepared.

In Osm Admin, object editing form is used not only for a single object editing, but also for editing multiple objects, and for creating a new object.

I also created the osmphp/extras package as an easy way of adding Font Awesome icons to a project. Later, I'll add more optional reusable goodies to this package.

On the list page, grid columns are implemented as control views. On the editing page, form fields are also implemented as control views.

The form Blade templates are completely migrated to Osm Admin v0.2.

I redesigned control rendering on list and edit pages. From now, a control contains view prototypes for a grid column, a form field, and other.

A View is a short-living object that is created and computed during page rendering. You can also create a pre-configured a View object prototype in advance, and then clone it for rendering.

It's important not to execute render-time properties while configuring the prototype.

Use view() helper function to create render-time view instances, and mark render-time properties using #[RenderTime] attribute to prevent accessing them before rendering.

After getting the list page to work, I returned to the editing page.

Done:

• new page layout based on template inheritance
• form header
• form field layout

Yesterday, I polished the product color facet, and, starting now, you can create a facet with a list of string options very quickly, just by marking a property as #[Faceted].

/**
 * @property string $color #[Option(Color::class), Faceted]
 */
class Product extends Record
{

In the product editing form, I implemented the id filter, and made the UI query work in database-only mode, too.

Three days ago, I started rendering faceted navigation, and namely, color facet on the product list page.

Yesterday, I continued working on it and got the first render of the faceted navigation, defined URL action syntax, and the first facet filter applied on the product list page.

The implementation of the faceted implementation in osm.software blog has shown that sometimes you need only facet counts, or only total count of matching entries.

Until now, Osm Framework had always queried total count, ids and facets. Not anymore - and the search engine only provides the information that is actually needed.

The implicit ElasticSearch hit limit is confusing. And you can't get all the hits - there is 10000 maximum hit limit that you can't exceed anyway.

Be explicit about the maximum number of search hits.

In my opinion, obfuscating object ID in a URL is not worth the effort, and here is why.

My current goal is a minimum list page, a form page and a faceted navigation for a Product data class.

Today, I've:

• implemented ElasticSearch + MySql combo that gets the list page data
• started rendering the faceted navigation

Today, I finished indexing design, described typical indexing logic, implemented full search reindexing.

Starting today, I'll write a daily blog post about how the Osm Admin development goes.

This is the first one. It reviews where I am today, covers creation of a search index, and revisits the design of the indexing engine and how queries orchestrate the indexing.

My current goal is to get some minimum Osm Admin user interface and API working - just for one property, one data type, one UI control type, and then improve.

And there is a lot of space for improvement. The main areas are listed in this document.

I'd really appreciate a helping hand, so if you are into this sort of things, DM me on Twitter.

I feel that both attributes decorating data classes, and object model parsed from it are too complex.

Let's have a fresh look at Osm Admin. If I had to start from scratch, how would it be?

Recently, I implemented mass-editing in Osm Admin. It allows you to view and edit multiple objects in a single operation.

This article describes mass-editing of products in a typical e-commerce application.

In the user interface, you can narrow displayed data using grid column filters, or filters displayed in the sidebar. To enable that, apply #[Filter\*] attributes to class properties.

Applied filters appear in the URL query parameters, for example, .../edit?id=5+16+19, and on the page.

You can apply filters not only to a grid page, but also to a form page - to mass edit all matching objects, or to an action URL (edit, delete, or custom) - to perform the action on all matching objects.

In the same way, you can apply filters to the API URLs in order to retrieve or modify matching objects in a script.

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.