Search results for 'framework'

This sprint was dedicated to writing Osm Framework documentation, and indeed, there are 8 new in-depth documentation articles, 4-5 minutes long each.

Despite documentation focus, I kept improving the website. From now on, you can assign a canonical URL to a blog post or a documentation page, and use GitHub friendly relative URLs in documentation.

But the most important thing - I started sharing progress and insights daily on Twitter.

osm.software website. From now on, Osm Framework documentation resides in the docs/ directory of the osmphp/framework repository, and it is displayed in a separate section of osm.software website. New data source indexing engine allows running complex interdependent data synchronization with a single command, osm index. New Placeholder class simplifies dynamic Markdown content generation.

Osm Framework. Apply dynamic traits within the same file using #[UseIn] attribute. Implement fast dynamic routing using new DynamicRoute class. Generate URLs using new $osm_app->base_url property.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.