Tailor features into builder

Tailor is really good feature, I’m very impressed with this concept. But for me is unusable for these reasons (please correct me if I am wrong):

  • Tailor doesnt create separate model and controller - this is for me crucial, because in my projects I often need some changes into the model, controller, change the import function or export function.
  • Tailor for the static pages with group repeater is also great, but the data is saved into the database, so its a little bit slower than the Static Pages with custom variable group repeater.

So my Idea is combine the really great Tailor features into the Builder plugin.
Builder now doesn’t automatically create database fields, model fields and colums, also import and export function has to be written manually.

If you can bring the scaffolding function to the builder with automation like this:

  1. User create blueprints like in the Tailor
  2. Builder plugin automaticaly create database migration, fields and columns for model, controller with sorting, import and export feature. And then user can manage the rest like now in builder.

Developer has the power to modify everything from database, model to controller, which is crucial.
I would really appreciate this feature, I will even pay for it.

Please correct me if I’ve got some mistakes in the Tailor understanding.

Welcome @zaq,

I’ll try to answer as best I can. Tailor and Builder do not compete; both are distinct features, even though, on the surface, they appear similar. Tailor is closer to the Static Pages plugin in terms of its purpose.

Builder is a great scaffolding tool for learning October CMS by creating models, controllers, permissions, and navigation into an actual plugin. It gives you complete flexibility and freedom to define your functionality exactly how you want. The builder plugin closely aligns with the low-level process of building a plugin by hand; there is no magic involved.

On the other hand, Tailor lets you quickly define the content, and has pre-built controllers, navigation, permissions (and much more coming). These things are what we might consider high-level opinions about the model’s use. These opinions translate to limited flexibility with some magic behind the scenes. These opinions are a good thing when it comes to solving the same problem over and over, as is the case with content.

Regarding your idea, it doesn’t quite make sense because the blueprint is discarded when it converts to the builder plugin. In Tailor, blueprints live forever and are continuously modified as the requirements of the content change.

Regarding performance and storing content in the database, the content can be cached in the filesystem, so the performance is about the same. Still, the benefits of using a relational database are huge compared to a file-based system.

In summary, it’s best to think about Tailor and Builder in these terms:

  • Content should be built with Tailor
  • Data/Functionality should be built with plugins (Builder)

Here are some examples:

  • Need to publish some articles and show them on the website → Tailor
  • Need to store the make and models of every car and filter them → plugin
  • Need to track a supply chain order as a single source of truth → plugin
  • Need to display a team page with members and their bios → Tailor
  • Need to establish the biological hierarchy of all living things → plugin

Finally, Tailor is far from finished, and we are releasing it in stages. Eventually, you can expect the ability to extend any model with Tailor blueprints. Think about extending the User model with custom profile fields. In this context, the model can begin to focus on its business logic and less on solving the needs of storing content.

I hope this clears some things up. Let me know if you have any other questions.

Thanks for the really detailed answer, this clear a lot of things to me mainly the content/function things. I agreed with you in every aspect.

But anyway, it will really save me a lot of time if the blueprints also work for Builder (I know that after “migrating” the blueprint it will be discarded/useless, but generated model, fields, database fields, controllers with slug, import, export, sort feature will be for me ultra time saver).

Thanks for the clearing things out and keep up the great work you’re doing.

1 Like

Building a plugin to promote a Tailor blueprint to a plugin is a fantastic idea and something possible. Tailor uses a dynamic model class that functions almost identically to a static model class found in the code.

Knowing all the fields in advance could be easier to use an interactive command-line tool that asks for all the necessary information. Then you don’t need the blueprint.

In most cases, it seems more natural that the field design builds up over time. So it might make more sense to allow the structure to exist in Tailor first, then when it is ready, convert it to a plugin.

1 Like