Osm Admin

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.

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.

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.

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.

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.

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.

Today, I finished implementing an object creation form.

It works according to the specs on Interfaces and Forms. Currently, it only supports string and integer input fields; later, there will be a lot more.

Let's review how it works.

In Osm Admin, a form is an integral part of the class user interface. It's a very specific kind of HTML form.

In this article, I'll review what's in a class form, and how it's reflected from the application code.

Yesterday, I described a user interface pattern for managing data of a certain data class using a grid/form pair. Let's call this grid/form pair class interface in the admin area.

In this article, I'll examine what moving parts are inside a class interface.

So far, I've been concerned about how application data is modeled, stored and handled internally.

Yet, the final objective a user interface for viewing and editing it visually.

Let's dream a bit about how it might look like.

Yay, indexing works!

It's changed quite a bit, so let's review how it works from the very beginning.

I'm still working on indexing, and it seems to get one more refactoring. But more on that later.

Meanwhile, let's review Osm Admin modules, their responsibilities and dependencies.

The project repository, osmphp/admin, follows a typical Osm Framework-based project structure. However, this repository is going to be a reusable Composer package, and has important structural differences presented in this article.

This article introduces the core project concepts: data object, data class, data query, and data schema.

I'm super-excited to announce that I'm starting a new project codenamed "The Big Red Button". It's about defining application data structures and logic in PHP code, pressing the big red button (hence the codename), and getting fully functioning Admin Panel and API.