Hello dev-list, I am working in a small corporate and we are working very intensive with the otrs.
This lead to the wish for us to create a new theme which is easily manipulated. What we don't like about the actual way the gui is build is the huge amount of files with no consequent diversification of layout, design and category. That's why we begann to develop our own theme and now i want to share this ideas with you - the developers - to see how we can go the same way to bring our development back to community.. For a common language, some "vocabular" i will use ;) - a "gui" is a frontend/web-application, that is responsible for a type of user. In otrs this is agent- and customer-gui. - a "view" is a page like it is viewed in the browser, so a gui consists of views and a view consists (mostly) of several templates B) ##################### Style-convention ################### My first step was to eliminate every design-tag/-style/font/etc. from the mostly used files. I eliminated some tables that had no real meaning for the layout and put up three stylesheet-files, so that there is a clear structure in the design. As styles are handled in different priority, i had the idea to make the stylesheets in groups by weight, so i made: - css-byTags.dtl: For default settings that are for EVERY tag mentioned here(a, body, table,..) - css-byClasses.dtl: For all classes. Classes are for more individual tags, like different table-types(main, header, footer,..) - css-byId.dtl: This is the most precise one, Ids have the highest weight This means by example: 1. ALL tables get some properties like font-size, font-color, border, etc. in css-byTags.dtl 2. In hardly every dtl is a table, that forms a header, so here's the header-class in the css-byClasses.dtl 3. At last, there is ONE header in ONE page, it's ID is p.e. "AgentTicketZoom_header", that needs a differnet border-color. This is done in css-byIds.dtl After doing this, i had reduced the size of several files a lot and you can read them now more easily with the big advantage, that you can change the layout ONLY in styleheets. B) ##################### Naming-convention ################### Additionally, exspecially for Ids, i had to insert severall classes and Ids, removing some others. To have a comprehensive naming-convention, i used following schema: 1. Classes are named by their function, p.e. "main", "header", "footer", "submit",.. 2. Ids are named using the page-name AND the class-name, p.e. "AgentTicketCompose_header" or "AgentTicketOwner_submit" 3. A tag with an Id always has to have a class(!) This is easy and simple to understand for all, who wants to make their own classes and Ids in future. C) ##################### Filesystem ################### We were not so happy about dozends of files from different guis resting in only ONE directory, so we seperated them: We have now three theme-directories named: - customer_<themename> - agent_<themename> - admin_<themename> Additionally, for developping-purposes, i added "<!-- templateName.dtl -->" at hte end of EVERY file, so i could easily see,w hich template i'll have to modify (in the theme-dir: "ls|while read fil;do echo '<!--'" $fil -->" >> "$fil";done") D) ##################### Wishlist ################### Some points are open for us in the moment and we would be glad, if we could go for a solution together: 1. Integrate same-looking pages in ONE file, p.e. AgentTicketForward, AgentTicketBounce, AgentTicketPhone, AgentTicketCompose, etc.: Perhaps this could be done easily if the application looks for a seperate file and ELSE(!) takes the (not yet devlopped) default one(p.e."AgentDefAnswer.dtl", which has all necessary dynamic code in it to fullfill the needs of all similar pages agregated in this template? 2. implementing less tables and more divs or spans for reducing the needed "width"-properties in the html-code 3. working over the files we didn't done yet 4. theme-file-structure: More convenient would be, if a theme could be handled in one directory with several subdirectories for the category/gui-type, but i didn't had the time 'til now to find out, where i'ld have to change something, so a theme could have subdirectories for this. I could imagine something like this for future: + <themename> +--+ common (common things for all others) +--+ agent +--+ customer +--+ admin Exspecially point(1) and (3) would lead in a VERY smart and easy to manipulate theme and would however not prevent users from creating different templates per view! I think it's enough now at a first glance, i am very curious about your opinions now ;) Kind regards Florian Rustedt IT-Administrator/-Entwickler =========================================================== Email: [EMAIL PROTECTED] Telefon: +49(40)-5540-0 Telefax: +49(40)-5540-1040 =========================================================== smartnet Online Service GmbH Ust.IdNr.:DE191136350 Handelsregister HRB 66463 Geschäftsführer: Steuernummer FA: Christian Suding Hamburg 54/855/01047 Claus Masch =========================================================== Weitere Informationen siehe http://www.smartnet.de Hinweis: Diese Email kann vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der beabsichtigte Empfänger sind oder diese Email irrtümlich erhalten haben, informieren Sie bitte sofort den Absender telefonisch oder per Email und löschen Sie diese Email aus Ihrem System. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser Email ist nicht gestattet.Wir haften nicht für die Unversehrtheit von Emails, nachdem sie unseren Einflussbereich verlassen haben. ********************************************************************************************** IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email in error, please notify the system manager or the sender immediately and do not disclose the contents to anyone or make copies thereof. *** eSafe scanned this email for viruses, vandals, and malicious content. *** ********************************************************************************************** _______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
