Search results for 'framework'

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.

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.

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.

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.

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.

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

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 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.

Implemented in Osm Admin:

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