Copy Page

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.

We will have several &quot;sub applications&quot; running &quot;inside&quot; swaf.

The basic layout of a swaf site, would be that these sub applications are &quot;tabbed&quot; next to each other.

According to their permissions, users should be able to select what subapps they want to use, and their position in their tab bar.

Some special subapps might be Aggregatable, in which case they'll be aggregated in a single tab by a Aggregator subapp.

Only one instance of each subapp should be allowed in the user's tabbar. (except for Aggregators...)

? Should each subapp &quot;remember&quot; it's state, so that when the user selects another tab then comes back to the previous one, he still sees the same screen? I guess that should be a choice left to the developer. We could provide a framework to do this, but that would be restrictive as to &quot;how to integrate with swaf&quot;. Actually, in any case, tab-capable browsers are there just for that. And if we would allow this, we would get into troubles if people use both browser tabs and swaf tabs and they'd get lost anyway.

The question's left open for Aggregator though. Should an Aggregator accept &quot;active&quot; subapps? (active being for example a subapp that would present a search form in a first screen, then display the results) If so, it wouldn't make much sense to have, say, two search forms, then get the results for one, and when searching in the second form, we would loose results from the first search. (I guess users would expect to keep results from the first search as well). There are multiple ways to handle this: * completely forbid active subapps in Aggregator. We would only allow non-active subapps, which could be for example &quot;informative&quot; subapps with no user interaction. That's probably the easiest. * allow active subapps in Aggregator, but user interaction results would appear in a separate &quot;tab&quot;. This should imply the fact that an aggregated active subapp would be registered by the user in its tabbar. (Otherwise it would lead to jetspeed-like non-sense where you see results of a subapp within a different, shitty stuff like that. Or if we are courageous, we can allow this without the user having a separate for the subapp, but we really need to be careful) * the most complex way would be to actually store the subapp's activity/state in the session and restore or re-execute it whenever there's user interaction with another subapp of the same Aggregator. I don't really feel like going into that, and we can probably manage to convince people it's not needed.

Each subapp should also be able to register user preferences of its own, which the user could modify through its profile screen. (which could for example look like most modern desktop application preferences dialogs, with a list on the left with the different sections (which here would be &quot;basics&quot; then each subapp's name) and the right part of the screen with forms)

The subapp user preferences would represented by an object which would be stored along with the rest of the user's data. (Find a clean way to define the preferences, something better than an HashMap?)

Skins are boring and a useless thing to propose. What we could have, eventually, is selectable stylesheets. But we have to think about not tying to developers to swaf too much here, too. While talking about stylesheets, we should maybe think about a way to let developers use their own css without having to edit swaf's main templates. Maybe &quot;stylesheet&quot; could simply be a parameter of a subapp's registration.s

See SwafBookmarks

– Main.gj - 17 May 2004