search

getkirby / ideas

This is the backlog of ideas and feature requests from the last two years. Use our new feedback platform to post your new ideas or vote on existing ideas.
https://feedback.getkirby.com
20 stars 0 forks source link

Add field() method to ModelWithContent as an alias for $page->content()->get() #514

Open hdodov opened 4 years ago

hdodov commented 4 years ago

I'm using the Kirby Editor and created a field content for it. The docs warn you that you can't use magic calls when field names conflict with Page methods. However, this:

$field = $page->content()->get('content');

...is very confusing. If a new person joins the project, he'll have a fun time understanding what that does.

My proposal is to have a field() method on Page that can retrieve conflicting fields:

$field = $page->field('content');

So basically, you have three ways to get a field:

$page->title();
$page->field('title');
$page->content()->get('title');

I think that using a field() method is intuitive and the docs should recommend that when you can't use magic callers.

This would also make it easier for people who value stability and consistency over brevity. Some people might want to just define fields in the blueprint, always use $page->field() in their templates and not care if they have naming conflicts.

hdodov commented 4 years ago

If ModelWithContent receives the field() method instead, you could use it in files and the site object as well. StructureObject should also have this method for the same reasons.

Then, a team could make the decision to always use field() and quickly find fields in their codebase. If you have a field called text and you use the magic text(), a search would return kirbytext(), myText(), etc. as well...

On the other hand, searching for field('text') will always return fields named text.

hdodov commented 4 years ago

Furthermore, using a field() method is future-proof. What if I have a field called foobar and I use $page->foobar() but in an upcoming Kirby release, you introduce a foobar() method on Page?

In fact, for the reasons I mentioned, I think Kirby should slowly move to encouraging the usage of field(), while magic methods remain as added benefits for people who decide to use them. This explicitness is more stable, maintainable, future-proof, and promotes a healthier codebase.

It would also make it cognitively easier to structure your project because you don't have to think "is this a native Page method" every single time you add a field in a blueprint. Kirby is all about making things simple and easy, and I think this falls under that category.

I remember a couple of years ago when I first started with Kirby, I tried $page->field('myfield') and was confused why it didn't work. I didn't know what magic methods were in PHP and it took me some time to get used to. Maybe the PHP magic stuff should be left for experienced PHP users who understand it. Stuff like this adds friction for newcomers.

Even after years of experience with Kirby, I still find myself calling:

$page->image()->toFile()

...and forgetting that image() returns an actual File object. That's because when I have an actual field, I have to use $page->myImage()->toFile(), which is very similar. If you develop the habit of using $page->field('myImage')->toFile(), you won't have that problem because $page->image() is a lot more different - it's obviously not a field and therefore has no toFile() method.