-
Notifications
You must be signed in to change notification settings - Fork 307
Allow modules to choose the theme #168
Comments
I like the idea except how would it "merge" the stylesheets? |
The idea is mainly for the new type of modules which create the UI specific to them. So theme will necessarily have template section which will do option.getStyles(); and I don't seem to see a problem here... I will explore though. For e.g. one could create a blog as an module with its own theme, and also leveraging other calipso modules (for e.g. for content, for content types, roles, user management and what not.) Then when one deploys this blog application as is, the UI is already good to go if user chooses the module's theme. The idea is that this will make calipso help allow module writers to create embeddable components for application. For e.g. if I want to create a new app, I would get ready made
|
Are you using module templates? |
I am trying to figure out what kind of things you would want to put into the module specific theme. If you only need to put templates, then couldn't you just add the template to the template folder of the module? Since as we previously talked about merging css would be pretty hard. |
Let me explain my usecase: A locally installed service where clickable mockups can be created and managed by a product team. (I chose calipso for the purpose as base framework, and right now working on a specific module for this purpose.) I would want end users to do exactly two steps: 1. Install calipso. 2. Install the mockup module. They should have readily working mockup site under particular URL. And now, let us say, somebody contributes a totally independent 'mindmap' module, with its own theme/layout. Those already using calipso for mockup module, will not have any conflicts with this mindmap module. Nor do they have to do any specific setup, or fiddle with different blocks in the layout pages etc.. URL spaces for both modules would be different. Both these modules should feel like they are independent applications. (Perhaps, another way to look at it is that themes are specific to URL paths. /mockups is one theme, and /mindmap is another theme.) These 'apps' may offer some simple controls for the user preferences, but definitely can't meddle with layouts and overall application experience. Open issues as I see them:
|
I do understand the usecase. I guess my question was if you put layouts and templates for each module in the module templates folder then they will be private to the module until at a later date someone decides to make a new theme which includes your templates and overrides them. I guess we would need to come up with a good naming convention so that templates are not inadvertently overridden by themes just because there is a name collision. Is there something you cannot do by controlling the views within the modules templates? I do agree that the name collision problems is probably the most concerning thing. My thought was to allow the modules templates folder to supply layouts and templates but then allow override of those in any theme. However I have not specifically tested what and if there are breakages. To load a whole theme per module might be interesting but then modules would no longer play nice with each other when they are both on the same page, we'd have to require iframes or something like that. On Oct 29, 2012, at 2:02 PM, Vinod Kulkarni [email protected] wrote:
|
I meant that I ship a module + a theme combination. (Of course, they are still independent). The theme is meant for the app, and may use some of the other existing templates and their blocks (such as tagging block). Under the namespace (such as /mockups), this theme will be used by default as application UI (overriding site theme), and the mockup template drives the UI with its own blocks. In essence, I am delivering a totally independent app using calipso platform. Yes, namespace management has to be cleaned up. For e.g. I want to register ownership for "/mockups", and then locally handle those URLs; and for unhandled URLs under this namespace, mockup template will be owner for error messages as well. |
If you follow drupal, there are many application-specific forks; see http://www.ministryofdrupal.org/Drupal_Forks_and_Distributions. For e.g. http://managingnews.com/ is a fork of drupal, but totally converted into dedicated application. And forks are bad; they reduce the reusability. And in such apps, the control over the theme/look-and-feel is of most importance. In calipso, my example mockup module can become such a full-fledged app. It will use capabilities of calipso; neverthless acts as independent app to end user. That is the idea that I am talking about... |
I do understand. I am not convinced that having a theme per module is the right thing to do. Personally I would like to add all that functionality to a module (i.e. having it's own default theme) and still allowing a theme to override those things. This would require better name spaces for overrides though. But I need to think this through a little more. Your idea of dynamically loading a theme would work but it seems kind of inflexible if someone wanted to take that module and apply their own theme to it. |
How much would adding a "public" folder in addition to the "templates" folder to each module help? We could make the static server so that it serves the files from all the public folders joined together. Making a new template which included those files in the future would then override those files. |
I made this change in the user module to illustrate. This is in the git repo but not yet published to npm. |
Seems good idea. I will try to use it. In the meanwhile, I have made my current codebase available here: https://github.com/codevin/calipso-screenswiki/tree/devel. It is working code with lots of copy-paste, but I hope you get the intent. |
I see we need to resolve layouts. The theme.layout object won't get custom layouts from anywhere. We'll need to add capability to add module themes into there. On Nov 4, 2012, at 2:06 PM, Vinod Kulkarni [email protected] wrote:
|
I made some steps toward this.
|
This is good, appreciate adding these capabilities as needed. I will check it out over the weekend. |
If this works well I am planning to add it to the documentation. Were you able to try this out? |
It works, and no issues found so far. There will be other requirements for module-as-app, I will open separate issues for them as required. (For e.g. "/" should be configurable to be mapped to any module etc.) I am in process of putting up a sample TODO application module for the same. Ideally on lines of typical express application, with its own internal routing, but leveraging all existing modules and themes from Calipso. I filed this stackoverflow question: http://stackoverflow.com/questions/13666435/using-match-engine-of-node-js-express-module-independent-of-app-server |
I have now created a sample Todo app that can become a template for such module-as-app. Can you check it out? /todo is registered as app URL base. I have separated out the module specific code within _module.js. So one can cleanly develop over calipso. Before we can release it for wider circulation, I need to add user module block for login/logout within local theme. |
How do I get _module.js? It's missing from the repo. On Dec 6, 2012, at 1:28 PM, Vinod Kulkarni [email protected] wrote:
|
Have updated now. Please check. |
That looks good.
On Dec 7, 2012, at 2:06 AM, Vinod Kulkarni [email protected] wrote:
|
You have identified both the issues, and I was going to open tickets for Here is my thinking: You essentially have two types of modules:
Let us open a new ticket for it. User module: I am about to look into this, as to how to leverage it within On Fri, Dec 7, 2012 at 6:16 PM, Andreas Richter [email protected]:
|
Could you also support overriding of module template blocks in the private theme? When I render user.login block within the application module (todoApp), I would like full control over how this block is rendered. In particular, the URLs like /login may have to be redirected to the application module. |
This would be tricky just in terms of figuring out which template would override which? Module, theme, module? I guess we could set a precedence level or allow renaming of template. Or did your other comment about the login screen take this into account? |
One more issue to tackle: When I use multiple app modules (usually copied from the template app module), I find that the layout names clash, and thus, the module's layout name is not loaded since one is already present with same name from previous app Module. Of course, we can just rename the layouts of each new app Module. (And write this in documentation.) But I was thinking if we can solve it elegantly - i.e. should module name be embedded in theme namespace? We have are two different concepts:
I am undecided about this. Can we think of something? |
When distributing a new module, it will be nice if it can have its own UI (i.e. its own theme and layouts). That way, the users don't have to worry about including its blocks in existing theme. There is instant gratification - install it and see it working. (The assumption is that the module is completely responsible for its namespace, say /mypath.)
With this approach, I am also able to use calipso as application framework i.e. module becomes an independent application by itself, while leveraging all the good functionality of calipso framework.
The code change is simple. (The module sets 'res.theme' to a precompiled theme.)
(File: lib/core/Module.js)
And the module writer can keep a version of precompiled theme using this code base:
(File: Your module; define 'mymoduletheme' as variable.
And in the handler function, one can then assign
The text was updated successfully, but these errors were encountered: