~migadu/alps#28: 
Variables availability in templates

This is a consequence of not using Javascript and the entire page refreshes.

To support flexible templates and layouts, once signed in, every template needs the variables:

  • currently signed in user (to show it in the header )
  • current folder - name, and number of unread messages in it
  • subscribed mailboxes list
  • current folder messages list with pagination context

The data available on templates dictates the layout and flow, but at the same time it is pointless to keep refetching the IMAP data on every single request. Folders and messages list are unlikely to have changed between requests so they should be cached.

Status
RESOLVED WONT_FIX
Submitter
~migadu
Assigned to
No-one
Submitted
2 years ago
Updated
2 years ago
Labels
mvp

~emersion 2 years ago

I agree we need a cache for the mailbox list. Caching the message list is more involved, let's keep it for https://todo.sr.ht/~sircmpwn/koushin/29.

~emersion 2 years ago

Re base variables:

The currently signed in user can easily be added and is useful for the header. The mailbox list (with unread/total messages count, flags, etc) could probably be useful for a sidebar.

I'm not sure we need these on every page:

current folder - name, and number of unread messages in it

It's not clear what the current mailbox is when you're not displaying the folder or a message in it.

current folder messages list with pagination context

This is a lot of data and I'm not sure how it would be useful.


I think we'll want to add an additional Base data field guaranteed to be specified for all templates. Something among the lines of:

struct BaseData {
    Username string
    Mailboxes []*imap.MailboxInfo
    Extra map[string]interface{}
}

Extra can be used by plugins to add more base fields. We can add more fields as necessary.

~emersion 2 years ago

(In any case, what I wrote above about which fields should be included isn't final: it's very easy to add more base fields if we need them.)

~emersion 2 years ago

Introduced a Global field available in all templates in 3748b4413e69 (renamed from Base to Global, this new name makes more sense).

~migadu 2 years ago

current folder - name, and number of unread messages in it

Sure, if the context of the current mailbox is not available, then none would be selected. This is primarily for the case where you display the message body on the same page with the mailboxes listing, instead of separate page. We can obviously deduct the current mailbox from the message data?

current folder messages list with pagination context

This is necessary if you have a split view layout [messages_list + message_body], for example such as thunderbird. It is easy with Javascript, but otherwise it requires a lot of data. I think I wrote that bad above, this is needed only on the messages list and on the message display page. It is not needed in e.g. settings screen. We could also just say, single layout possibility and cut it short, but I would love to have it universal. Wdyt?

~emersion 2 years ago

Sure, if the context of the current mailbox is not available, then none would be selected. This is primarily for the case where you display the message body on the same page with the mailboxes listing, instead of separate page. We can obviously deduct the current mailbox from the message data?

The current mailbox variable is available on the mailbox and message views already, so it should be fine.

This is necessary if you have a split view layout [messageslist + messagebody], for example such as thunderbird. It is easy with Javascript, but otherwise it requires a lot of data. I think I wrote that bad above, this is needed only on the messages list and on the message display page. It is not needed in e.g. settings screen. We could also just say, single layout possibility and cut it short, but I would love to have it universal. Wdyt?

Ah, indeed, I haven't thought about that. I'm not yet sure what the best way to do it would be. It would be easy for a plugin to add the message list data to the message view, and change the template to display it. But message list caching is important for this case, I'll keep this in mind.

~migadu 2 years ago

More I think about this, more I am convinced we ought to keep it simple and not support the split screen layout. It is wasteful to server resources and it also is not a better layout. While it would be good that koushin is a "framework" for webmail, some opinion is not bad. Now, if Javascript is enabled, we could do this by simply using javascript remote fetch go get the message the user clicked. This means we do not need to get away from the messages list and by it we don't need to do mumbo jumbo magic with cache. The template should just have a hidden div, which 1) when displayed splits the screen (the message panel), 2) renders message into it.

I can do the JS for this - but it is not a high priority at the moment.

The simpler the things are the better. This would require only a handler which serves the message as JSON.

~emersion 2 years ago

We can always have a plugin for the split view.

~migadu 2 years ago

From a high level - how would you do that from a plugin?

~emersion 2 years ago

The plugin could add a hook to the "view message" route, adding the message list to the template data. Then the template could render the additional data. The plugin could handle caching in memory.

~migadu 2 years ago

got it, though it should in that case use same templates obviously.

~sircmpwn 2 years ago*

Since this is marked as mvp, ~migadu, can you summarize what portion or portions of this work is considered blocking and still needs to be done?

~migadu REPORTED WONT_FIX 2 years ago

This one boils down to having more data for the mailbox list. Will close and open another one.

Register here or Log in to comment, or comment via email.