Hello Alexander, I am doing what you are looking for using Turbine and Velocity. I apologize in advance for the length of the following response. I spent a lot of time solving the problem that you are looking at so that I could handle it in a nicely maintainable fashion. The following may contain some hints to help you.
... The company that I work for has products that we plug into affiliate web sites, and as necessary we re-skin the look per affiliate. This can include color, fonts, buttons, layout, different languages, etc... pretty much everything. The way that I accomplished this was to build my own session tool that resolved the linkages for me... so personally I think that you are on the right track with this. I did take it a few steps farther... In my world the vm's are more or less place holders. I populate the content of the vm's dynamically (through another session tool that I wrote). The advantage of doing this is that none of my programming logic ever changes, everything still references the same vm's, the same security still applies, etc. Also I can change the content of individual vm's on the fly without having to redeploy (kind of like dynamic content), a major league time saver. If you can "pull" the content into the vm then you can re-skin, translate, change the layout, etc without ever having to change external references to the vm. The same applies to the layout concept, since the layouts are also just vm's. In order to manage my security, content, languages, layouts, etc, I extended VelocitySecureScreen, and re-worked isAuthorized so that I could perform some pre-processing. This allows me to preset and track security, languages, pre-set layouts, etc. (When the session is first created I load up meta data to support this functionality... if I want a different result in a particular case I change the meta data). These pre-sets all happen in one place... consequently all of my apps have these capabilities.... In my world I sometimes think of English as ENGLISH_CUST1, ENGLISH_CUST2, SPANISH_CUST1, etc. ... As necessary I did put my customers content into different sub directories . My "content" directory structures look like... _cust1 /cust1_somefile.html /cust1_someotherfile.html _cust2 /cust2_somefile.html _cust3 /cust3_someotherfile.html Because of the default content capability not all custom content is required. I only have to change the content that is specific to that customer's needs. Since the system dynamically pulls the content into each vm it will automatically use default content if a particular piece of custom content is not available. I am not using velocity includes.... I allow my session tool to pull in the content from other "http" servers. This way I never have to worry about relative directory references. Content is managed for security, non-programmers can manipulate the content, etc. This is also what allows me to test for the existence of custom content and use default content as necessary. This "pulled" content that I am describing is your plain old Velocity macro content... I just don't type it directly into the vm's... I store it, and reference it as html pages from an http server. In my world content is recursive (including all velocity macro processing)... so individual pieces of sub-content can be re-used (even the non-static stuff). Also because of the security model, sub-pieces of content are automatically filtered out if a user does not have sufficient security rights. There is no embedded page or content security, layout settings, or language settings, etc, within any of my applications. It is all handled by meta data and the isAuthorized pre-processing. ... Hope these ideas help. -----Original Message----- From: Alexander Zimmer [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 17, 2007 3:17 AM To: [email protected] Subject: separate template sets for different customers: how? Hello list, I am trying to modularize an existing turbine 2.3.2 app. The app should be shipped to several customers, each with a distinct layout. But - how? As far as I can see, the skin mechanism is not enough because I can only "skin-ize" images, colors etc. Instead, what I want to do is to implement completely different layout sets having customer specific appearance beyond just replacing images: e.g. using a table layout for one customer and using sophisticated <div> elements for the other. My first idea was: put each customer layout set in different subdirs of the templates/app/* directories, e.g: templates app layouts default customer1 customer2 navigations default customer1 customer2 screens default customer1 customer2 Now each time I use a reference to a template file, I have to "qualify" it using the customer directory prefix. E.g.: customerDir = "customer1"; // this would be in fact a global setting rundata.setScreenTemplate(customerDir + "," + "Orders.vm"); To be able to qualify template links in my .vm files, I would implement a pull tool (here named $tpl): <a href='$link.setPage($tpl.qualify("Orders.vm"))'>Orders</a> Do you think this is the right, Turbine-friendly way to tackle the problem? Or am I missing something and there is a better way? TIA, Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
