I see your point on data first, and makes sense.

Now let me explain to you a use case based on my experience and with a example/rationale behind it.
It doesn't mean it has to be a better approach, or that it do not have flaws, but just consider it.

Suppose I'm creating a CMS, or a plain website. That website has pieces that I can put in different places
and conditionally: for example A/B testing or based on user preferences. Also consider that the amount of
html generated for those blocks could be potentially big and that we want to cache database queries and that we
want to prevent unnecessary database queries.

Now consider the following reusable piece of code:

suspend fun Tag.lastPostsInCategory(category: Category) {
    cache("last-posts-${category.name}") { // suspend call (inmemory, redis, memcached, ...)
        h1 { +"Last posts" }
        ul {
            for (post in category.lastPostsInCategory(category)) { // suspend call (uncached database access)
                li { 
                    a(PostRoute(post.name)) { +post.title }
                }
            }
        }
    }
}

Where cache block is just computed on cache-miss based on a key, and computes a plain string without having to generate objects per each tag for each requesst,
and that could provide (somehow) a graceful fallback like generating "Data not available" just for that block instead of a full 500 Internal Server Error.

You can always compute what is required and what is not before html rendering. But you have to do that explicitly while here it is just natural.
The data is computed just when required and lazily. You don't even have to have all that data in memory while doing the request, but potentially
just one row at a time. It just requires one kind of cache. Instead of potentially having to cache that whole query and later that html too if you
want to prevent that object creation.

Obviously this is just an idea. I have been coding a lot of years in PHP, and maybe this approach has too many flaws. But wanted to share anyway so you can consider it :)

In a plain MVC the controller usually grabs data and passes it to the view. But sometimes, you just compute more data than required, and that doesn't allow to compute it lazily. I worked for a big PHP company a lot of years ago and I have seen it. At least, they, computed more than required. Also since some people worked on views and other in controllers, that was pretty common.

Some years later I tried an approach where views were the ones that lazily requested what it needs. I did this https://github.com/soywiz/atpl.js and created a couple of sites with that approach.
That's not MVC, but after trying it I found it pretty convenient. Also using plain files for html views allows to generate less objects per request. Since it treats a whole chunk of html as a single string. But you lose static typing, assisted autocompletion and typesafety. So I thought about this approach: simple, asynchronous, lazy, typesafe, cacheable to reduce object creation. And it is pretty appealing to me at least for my personal projects.

Shouldn't DSL functions be inline? #67

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions