Re: Pain-Free Theme Development?
Hi Bob,
Efficient theme and template development was important to us.
One of the key requirements for us when moving to the new CMS System (Magnolia) was to improve and simplify development. In the old system development was "code-heavy", the templating was weak, and tightly coupled to the code, and deployment was a nightmare - changing anything required a redeploy, and was error-prone and time-consuming.
We looked at the possibilities, and decided on the following:
1. We treat templates, dialogs, theme resources as "their own thing". In our point of view, they are not part of the (Java) code, and they are also not part of the content. They are considered "layout", its own category. This conceptual separation lets us develop our Java-Code one way while handling the templates and theming in a different way. It also makes for a nicer "separation of skills" - Java Developers can use eclipse, version control, deployment, etc... while templaters and designers just need a browser and a text-editor.
2. We use inline-templating for templates and the resources/dms workspaces to store theme resources and images. (in Magnolia 4.5 the theme images can also live under resources).
--> This means we never need to restart the server or do any messing around with deployment when we change themes or templates
--> We use the XML-Import / Export or the Magnolia Packager Module (EE only) to move theme resources and templates between environments
--> Another option could be (but we don't do this) using the activation mechanism to move this data between environments
--> This makes us very fast and flexible when changing templates and themes. Often, when in meetings with our customers, we are able to make simple changes "live" during the meeting. This speed and flexibility has been greatly appreciated by our customer.
--> We pay a price: our templates and theme resources are currently not version-controlled. We can't easily go back to a previous version of our templates. So far we have not missed having access to old versions, but we have missed the automatic merges and collision-warnings that come with source control. When we have conflicts (when moving templates from the different developers workstations to the qs system) we have to find and resolve them manually.
3. We use webdav to make editing nice for developers.
--> very important for the theme and template developers. They can simply open the freemarker, css or js files in their favourite text-editor. Works well once you find the right DAV client. Under Mac it works out of the box, under Windows it can be a pain to find a client. In Windows, we have had success with the products:
- Webdrive
- CrossFTP
but neither is perfect.
Regards from Vienna,
Richard
-----Ursprüngliche Nachricht-----
Von: user-list-owner@magnolia-cms.com [mailto:user-list-owner@magnolia-cms.com] Im Auftrag von Bob Ziuchkovski
Gesendet: Mittwoch, 04. April 2012 00:58
An: user-list@magnolia-cms.com
Betreff: [magnolia-user] Pain-Free Theme Development?
Hi,
I am working on a new magnolia project and am in the process of creating a custom theme. The project is making use of magnolia 4.5.1, soon to switch to 4.5.2.
The problem I am having is with regard to workflow efficiency. My goal is make direct updates to the css and image content and test the changes immediately, without extra copy/upload steps.
I am aware of the 'bypass' option and am already using it. However, the only way I have been able to get this to work is to run Tomcat with the 'reloadable' option, which means every time I make a simple CSS tweak, Tomcat reloads everything in entirety and I have to log back into adminCentral.
I have a feeling I must be missing something simple. Would someone who is using an efficient theming workflow be willing to share some tips?
Note: I am aware the webdav module would probably help here, but it currently does not work with magnolia 4.5.x -- a JIRA is open for this issue already.
I appreciate any/all advice. Thanks!
Bob
Hi Bob,
Efficient theme and template development was important to us.
One of the key requirements for us when moving to the new CMS System (Magnolia) was to improve and simplify development. In the old system development was "code-heavy", the templating was weak, and tightly coupled to the code, and deployment was a nightmare - changing anything required a redeploy, and was error-prone and time-consuming.
We looked at the possibilities, and decided on the following:
1. We treat templates, dialogs, theme resources as "their own thing". In our point of view, they are not part of the (Java) code, and they are also not part of the content. They are considered "layout", its own category. This conceptual separation lets us develop our Java-Code one way while handling the templates and theming in a different way. It also makes for a nicer "separation of skills" - Java Developers can use eclipse, version control, deployment, etc... while templaters and designers just need a browser and a text-editor.
2. We use inline-templating for templates and the resources/dms workspaces to store theme resources and images. (in Magnolia 4.5 the theme images can also live under resources).
--> This means we never need to restart the server or do any messing around with deployment when we change themes or templates
--> We use the XML-Import / Export or the Magnolia Packager Module (EE only) to move theme resources and templates between environments
--> Another option could be (but we don't do this) using the activation mechanism to move this data between environments
--> This makes us very fast and flexible when changing templates and themes. Often, when in meetings with our customers, we are able to make simple changes "live" during the meeting. This speed and flexibility has been greatly appreciated by our customer.
--> We pay a price: our templates and theme resources are currently not version-controlled. We can't easily go back to a previous version of our templates. So far we have not missed having access to old versions, but we have missed the automatic merges and collision-warnings that come with source control. When we have conflicts (when moving templates from the different developers workstations to the qs system) we have to find and resolve them manually.
3. We use webdav to make editing nice for developers.
--> very important for the theme and template developers. They can simply open the freemarker, css or js files in their favourite text-editor. Works well once you find the right DAV client. Under Mac it works out of the box, under Windows it can be a pain to find a client. In Windows, we have had success with the products:
- Webdrive
- CrossFTP
but neither is perfect.
Regards from Vienna,
Richard
-----Ursprüngliche Nachricht-----
Von: user-list-owner@magnolia-cms.com [mailto:user-list-owner@magnolia-cms.com] Im Auftrag von Bob Ziuchkovski
Gesendet: Mittwoch, 04. April 2012 00:58
An: user-list@magnolia-cms.com
Betreff: [magnolia-user] Pain-Free Theme Development?
Hi,
I am working on a new magnolia project and am in the process of creating a custom theme. The project is making use of magnolia 4.5.1, soon to switch to 4.5.2.
The problem I am having is with regard to workflow efficiency. My goal is make direct updates to the css and image content and test the changes immediately, without extra copy/upload steps.
I am aware of the 'bypass' option and am already using it. However, the only way I have been able to get this to work is to run Tomcat with the 'reloadable' option, which means every time I make a simple CSS tweak, Tomcat reloads everything in entirety and I have to log back into adminCentral.
I have a feeling I must be missing something simple. Would someone who is using an efficient theming workflow be willing to share some tips?
Note: I am aware the webdav module would probably help here, but it currently does not work with magnolia 4.5.x -- a JIRA is open for this issue already.
I appreciate any/all advice. Thanks!
Bob
Magnolia Community Forums
Magnolia Community Forums (beta)
