Search results for 'framework'

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.

In Osm Admin, I've finished indexing. It means that whenever you modify an object in the database, the changes are automatically propagated to all dependent indexed properties in the database.

I've also introduced a grid/form pair as the main user interface concept that is optimized for performing operations on multiple objects. There is also a programming interface (API) that will internally work in the same way, but without visuals. I implemented a part of this interface - an object creation form.

Osm Framework and all projects built with it - including this website and Osm Admin - are upgraded to TailwindCSS 3.0.

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.

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.

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.

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.

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.

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.