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.

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.

Use config:nginx, config:host and install:nginx commands to automate Nginx configuration of your project. Now, it's fully automated!

Yesterday, I tested the instructions for installing Osm Admin locally as a contributor.

Yesterday:

• Osm Admin in-browser functionality was fully restored after creating search index in the indexer.
• All test suites started passing again, and being run automatically on git push.

Yesterday started as usual, planning new iteration, and then BAM! - one folk - Saif - joined the project. It made me correct the course a bit, and take care of potential contributors:

• README explains what the project is about, and how to get started as a contributor;
• I'm fixing things to make the project actually runnable just after installing it.

Yay! After implementing invalid data conversion, I finished the iteration #18 dedicated to diff-based migrations!

I must say, it's a bit disturbing to implement the same thing for the third time. Still, the goal is to get it finished, and have it sustainable.

After the effort, the code has become su much easier to read!

I continued working on property diff algorithm that plans all the migration details.

Yesterday, I finished implementing data conversion for int and string property types.

Then, I started refactoring it.

Last time, I pushed through string property migrations and created a migration log.

Today, I continued solving data conversion issues.

• I finished implementing string property migrations.
• Migrations have got a meaningful log explaining what migrations take place, and why.
• Along the way, I fixed numerous issues.

Yesterday, I finished writing int property migrations. True, testing it is still a todo.

The major part of the code (type change, nullability and other attribute handling) will be reused in other property types.

I refactored Property::migrate() using additional Migration classes. It's so much more convenient to compare property definition versions and generate migration SQLs!

New code structure already handles property explicitness changes.

After enumerating what kind of changes can happen to a property, I started implementing the most hard one - changing property type.

The Query::bulkUpdate() method is implemented in the TDD way.

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.

Yesterday, I optimized search responses, made search hit limit explicit, and decided not to obfuscate ID in URL.

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.

I came with an idea of much cleaner Osm Admin data class "markup", and more straightforward architecture, and I decided to give it a go in a separate experimental branch v0.2, and to see if it's viable.

After three weeks of implementation effort, I can say that it is viable, and it's so much better! And it's not a completely new effort, I mostly copy code from v0.1 and some parts of osmphp/framework:old_v4, and adapt it.

You can already define data classes using new markup, generate the database tables, and query it using new formula syntax. I really wanted to come with some UI working, but there wasn't enough time for that. It stays my priority for the next iteration.

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?

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.

This website got a completely new look. There are new blog posts diving into core Osm Framework features. Osm Framework itself offers more convenient page layout, website-wide header, footer and <head>, customizable error pages. The themes support theme-specific CSS styles and JS scripts not bound to any module. New projects come with a handy bin/install.sh script that simplifies installation on Linux. From now on, run osmh without any parameters.

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.

From now on, this website is deployed on push, and by the way, you can easily play with the website copy locally. In the Osm framework, new Osm_Project application allows reflecting over modules and classes regardless to which application they belong. New experimental project is aimed at quick creation of the Admin UI.

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.

After pushing changes to GitHub, osm.software website is updated without any additional manual action. On push, GitHub executes the deployment script on the production server. Most changes are done to content only, and in this case, the deployment script only updates the search index. Otherwise, with the website being on maintenance, it additionally updates Composer and Node dependencies, builds JS and CSS assets, and runs the database migrations.

Readers of osm.software blog can search the blog for a specific phrase, and narrow down listed articles using multi-select layered navigation. Let's see how it works under the hood.

osmcommerce.com (now osm.software) blog got multi-select layered navigation, category management, FontAwesome icons, Tailwind CSS Typography. Osm Core allows debugging accidental assignments of the computed properties.