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.

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.

Last two weeks were about implementing initial version of an Osm Admin grid, integrating it seamlessly with the editing form, and enabling mass-editing of multiple objects.

After finishing it, I realized that Osm Admin had become bigger than Osm Framework! To keep up, I started writing docs for it.

And now, you have a step-by-step guide for creating a project, adding Osm Admin to it and a practical example of an admin area that you can copy to your project and try it out locally.

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.

The last 4 weeks were mostly a vacation. It's been a time for reflection, but still, I delivered some new features.

In Osm Admin, forms already allow creating new objects and saving them to the database, and editing one or several existing objects.

I've also implemented URL query filters that are applied to the underlying database query and that can be displayed in the user interface.

From now on, Osm Framework and all projects built with it - can be installed and developed under Apache and on Windows.

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.

I had two weeks full of meaningful, productive work. I started with sketching Osm Admin grid and form pages, and implemented a very basic, but working home page, and success/error messages. To enable that, Osm Framework now have extensible Blade templates, and a nice JavaScript solution for capturing user input into a modal dialog box, or into some picker component.

Then, I undertook a major refactoring of Osm Admin, including moving lots of pieces of code to their new places, stabilizing the underlying object model, rewriting database migrations and sketching future effort on data indexing. During this effort, I implemented generic object hydration and reflection over named subtypes.

I've already shared most of this information on Twitter, so if you are reading this, consider following me on Twitter and getting daily updates.

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.

I had two very productive weeks. #buildinpublic works wonders.

Most effort went into my new project, Osm Admin. I sketched how data classes look like, generated database tables from class attributes, and started working on the Admin UI. It's very fulfilling to see how an abstract idea gains shape.

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.

New Osm Framework version comes with improved, configurable and easily customizable Gulp script, modular NPM dependencies, standard page layout Blade component and brand new README. osm.software website contains an easy-to-follow new project installation instruction.

The first osm.software blog articles have been written, edited and revised. Content changes are deployed in semi-automated way. The website got some SEO improvements, and now it scores 100% in Google Lighthouse.

Osm Framework introduced production mode and maintenance mode. osm.software website went live.

Osm Framework introduced JS controllers, and JS unit tests. osmcommerce.com website project was renamed to osm.software, it finalized the post rendering, and introduced a tool for checking broken links.