Osm Admin: GitPod
2 years ago ∙ 2 minutes read
I waited for this day too long. Today, I've tried out GitPod, and made it work for a project based on Osm Admin.
2 years ago ∙ 2 minutes read
I waited for this day too long. Today, I've tried out GitPod, and made it work for a project based on Osm Admin.
2 years ago ∙ 2 minutes read
Today, I reiterated on what's left in this iteration, and finished the side menu view, and created a trivial home page for the admin area.
2 years ago ∙ 2 minutes read
After getting the main branch all-green (tests pass, CLI and UI works as expected), I decided that from now on, I'll keep it always green, and use feature branches for all major development.
Then, I started implementing the main menu of the admin area.
2 years ago ∙ 1 minute read
Yesterday, I created a template for new projects powered by Osm Admin.
This way, you can create and publish a project in minutes, just follow the README
. Yay!
2 years ago ∙ 3 minutes read
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.
2 years ago ∙ 1 minute read
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.
2 years ago ∙ 2 minutes read
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.
2 years ago ∙ 3 minutes read
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.
2 years ago ∙ 3 minutes read
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.
2 years ago ∙ 3 minutes read
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.
2 years ago ∙ 3 minutes read
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.
2 years ago ∙ 3 minutes read
I developed dehydrate()/hydrate()
functions for a very practical need - storing the data class schema:
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.
2 years ago ∙ 2 minutes read
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.
2 years ago ∙ 1 minute read
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.
2 years ago ∙ 1 minute read
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.
2 years ago ∙ 2 minutes read
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.