Loading...
 
[edu.t.o] Development

[edu.t.o] Development


reconsidering the workspace desktop...

posts: 52
I was thinking about this lately.
The ws desktop works like this:

-when we create a workspace type, it is like a kind of prototype for the creation of new workspaces of that type
-we also define a base ws desktop for that type
-when we create a new ws of that type, an admin (or delegate ws admin) has also the possibility to define a specific desktop for this workspace, different from the prototype one, with different modules etc.

So when that ws is opened, if it has his onwn specific desktop, you'll get that. Otherwise you'll fallback to having the prototype desktop, as defined for that ws type.

But in what does a desktop differs from a normal wiki page, with wikiplugin modules placed in it?

-With a wiki page you can have better placing of columns, using tables, so you can have a row that comprises two columns for example.
- with a wiki Page any member with edit permissions can add stuff to the page
- with a wiki page you can assign perms to it, so that eg: delegated admins (member of a WSXX-Teacher group) can modify all of it, Students only parts of it.
- You can still force people to see that page after login, by setting it as a 'group Homepage', obtaining the same effect of a Desktop.

An alternative way could be to define a Desktop with just one module: the workspaces_viewpage module, that will just show a well manufactured page like above

This would give more flexibility and finer permissions on the Desktop layout, and take away a lot of code.
Supposed there exist a way to do it automatically for all workspaces... But I think this can be worked out


What do you think
posts: 158
> I was thinking about this lately.
> The ws desktop works like this:
>
> -when we create a workspace type, it is like a kind of prototype for the creation of new workspaces of that type
> -we also define a base ws desktop for that type
> -when we create a new ws of that type, an admin (or delegate ws admin) has also the possibility to define a specific desktop for this workspace, different from the prototype one, with different modules etc.
>
> So when that ws is opened, if it has his onwn specific desktop, you'll get that. Otherwise you'll fallback to having the prototype desktop, as defined for that ws type.
>
> But in what does a desktop differs from a normal wiki page, with wikiplugin modules placed in it?
>
> -With a wiki page you can have better placing of columns, using tables, so you can have a row that comprises two columns for example.
> - with a wiki Page any member with edit permissions can add stuff to the page
> - with a wiki page you can assign perms to it, so that eg: delegated admins (member of a WSXX-Teacher group) can modify all of it, Students only parts of it.
> - You can still force people to see that page after login, by setting it as a 'group Homepage', obtaining the same effect of a Desktop.
>
> An alternative way could be to define a Desktop with just one module: the workspaces_viewpage module, that will just show a well manufactured page like above
>
> This would give more flexibility and finer permissions on the Desktop layout, and take away a lot of code.
> Supposed there exist a way to do it automatically for all workspaces... But I think this can be worked out
>
>
> What do you think

This is a great idea to make things simpler! :-)
Well thought (imho)

The only things I see that we would be missing right now (but I guess that they can be worked out somehow with minimum code for refactoring and applying templates for wiki pages, at least) are:
  • the tabs (zones) of the ws desktop that can be defined per ws and per ws type.
    • in 4.0 (I think) luci committed the tabs plugin, which would be nice alternative to have similar tab-oriented display of content in the wiki page... HAve you seen it? (but it should be backported to tiki 3.x LTS, I guess)
  • the easy interface to add columns, modules, and zones. With a basic wiki pages, newbies will need to learn wiki syntax...
    • However, if a good wiki templates is applied to the group homepage at ws creation, things might be easier for a newbie.
  • The ability to edit a page shown in the ws desktop, save changes, and automagically be back at the ws desktop. (sometimes this could be - was - handy)
posts: 52
Anyway I gave this a try on workspace Doc-test
In the Ws admin page I applied a specific desktop for this workspace, with a single module:
workspaces_wiewpage that points to the page ))Doc-test-Desktop((

Now follow these steps in this order:

1) look at it through the ws_viewpage module from the Doc-test desktop zone, it is not wiki parsed. This will set your session current workspace to that test workspace (top left: current workspace doc-test)
2) look at the Doc-test-Desktop page itself (with current workspace set at doc-test): modules get parsed (but you have to select Doc-test as current workspace first)
3) set another ws, eg WSDOC, as current workspace eg by visiting its desktop
4) visit again Doc-test-Desktop while having the current_ws set to another ws: no ws selected..

...

Yes, I think reconsidering the desktop, zones etc is a great semplification. We could provide some example pages one can import as desktop. The modules should work mostly with no parameters, because the workspaces_xxx ones rely on the value of the current_workspace to get their data.
posts: 158
> Anyway I gave this a try on workspace Doc-test
> In the Ws admin page I applied a specific desktop for this workspace, with a single module:
> workspaces_wiewpage that points to the page ))Doc-test-Desktop((
>
> Now follow these steps in this order:
>
> 1) look at it through the ws_viewpage module from the Doc-test desktop zone, it is not wiki parsed. This will set your session current workspace to that test workspace (top left: current workspace doc-test)
> 2) look at the Doc-test-Desktop page itself (with current workspace set at doc-test): modules get parsed (but you have to select Doc-test as current workspace first)
> 3) set another ws, eg WSDOC, as current workspace eg by visiting its desktop
> 4) visit again Doc-test-Desktop while having the current_ws set to another ws: no ws selected..
>
> ...
>
> Yes, I think reconsidering the desktop, zones etc is a great semplification. We could provide some example pages one can import as desktop. The modules should work mostly with no parameters, because the workspaces_xxx ones rely on the value of the current_workspace to get their data.

Ok, so far, so good. Next steps?

Switch Language