View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0004227 | mantisbt | bugtracker | public | 2004-07-30 17:58 | 2020-08-25 04:50 |
Reporter | grangeway | Assigned To | |||
Priority | none | Severity | feature | Reproducibility | N/A |
Status | acknowledged | Resolution | open | ||
Summary | 0004227: Roadmap 1.0 - Templates | ||||
Description | Bug to group / discuss issues relating to possible roadmap task of Templates. (probably http://smarty.php.net) Allow users to choose any subset of supported fields in view/update/print pages. | ||||
Tags | patch, redesign | ||||
Attached Files | |||||
related to | 0000798 | closed | jlatour | Email Templates |
related to | 0006220 | closed | vboctor | Change order of fields |
related to | 0007206 | closed | Ability for Management/Administrator to change "Project" of bug. | |
related to | 0009818 | closed | rombert | iphone/mobile device optimized site |
related to | 0017919 | closed | syncguru | Modernize Mantis UI |
parent of | 0004708 | acknowledged | show status in email subject | |
parent of | 0006628 | closed | vboctor | Skinning |
has duplicate | 0002240 | closed | grangeway | Displayed fields not as required |
has duplicate | 0006829 | closed | grangeway | emails design should be improved |
has duplicate | 0002464 | closed | grangeway | Over general CSS |
has duplicate | 0007326 | closed | ryandesign | Use a Templating System to produce Page Output |
has duplicate | 0007607 | closed | ryandesign | Easier style editing |
has duplicate | 0009597 | closed | vboctor | Customization of Appearance for Fields on "Report Issue" |
has duplicate | 0003736 | closed | vboctor | Implementing Themes |
related to | 0003681 | closed | jlatour | Template System |
related to | 0001872 | closed | vboctor | Super simple report / simple report / advanced report |
related to | 0006671 | closed | ryandesign | Tracker themes, user selectable or not. |
related to | 0006768 | closed | atrol | Remove fields Reproducibility, Severity and priority from one project |
related to | 0006785 | new | 0007613: Move "product version" field up | |
related to | 0002814 | closed | daryn | Prefix CSS class names |
related to | 0003468 | closed | atrol | Steps to Reproduce on Simple Report OR Ability to customize report bug page |
related to | 0011070 | new | Email content change | |
related to | 0006713 | new | Customization of the attributes seen in report, edit and update bug views | |
related to | 0012000 | closed | atrol | Variables for Colors in Webpage |
related to | 0012339 | new | Design proposal for "View bug" to increase readability and reduce clutter | |
related to | 0012685 | closed | atrol | Enhancement |
related to | 0011385 | new | Put custom fields on top of the report page (before category) | |
child of | 0004181 | closed | Features in Mantis 1.1 release | |
Not all the children of this issue are yet resolved or closed. |
template_example. |
|
In case you have not started on it yet, please do not use smarty.
Apart from that, I somehow refuse to use a template engine, which talks about itself having a "Kernel". |
|
I'm a bit scared about the effort involving a major re-write an testing Anyway you have done a great work with this product !!!. |
|
I'd also like to recommend not using Smarty. It is far too bloated and is mostly wasted. More information very similar to what jotarp posted can be found here: |
|
i've personnaly rewrite some mantis page with smarty template engine. Why will you say ? because i need a cleaner view of php code. So to close this note i say Wonderful ! |
|
A smarty plugin is basically just a function for doing something with a templates. All of the plugins could be reproduced with Brian Lozier's template code by plain old PHP functions. Using smarty adds an extra layer of slow code. It's so bloated that there is a Smarty Light sourceforge project. I'd much prefer to avoid using any template syntax. |
|
excuse me but as smarty is basically php, i think it's obvious that "plain old PHP functions" could reproduce smarty plugin process. please have a look http://www.phpinsider.com/smarty-forum/viewtopic.php?t=102&postdays=0&postorder=asc&start=0 |
|
I would strongly suggest a cleanup of the codebase as a step towards this to separate presentation from business logic (similar to PHP-vs-HTML but a different view point). Right now to change e.g. the top menu you have to delve deep into the PHP code, rather than editing "templates/top_menu.php" or some-such. |
|
Using templates is a very important step for Mantis, but I don't know if smarty is the right solution (given the expectations). Have you ever considered using XSL Transformations? XSLT is much more powerfull than Smarty, and much more "solid", although it will require a much bigger rewrite of the user interface (well... we will REMOVE the user interface and let everything to be produced by a XSL file). If you don't know XSL yet, an example: The bug view page will be reduced to something like this (parenthesis are disguised xml tags):
Also, this solution couples much better with i18n, we need just a entity file for each language that will be linked against the XSL stylesheet, everything else will be handled by the XSL processor. XSLT can also be used to produce output in other formats like plain text from the same input data, very useful to produce e-mail messages. |
|
I wasn't aware that XSLT was available in all installations of PHP. I know that it's in PHP 5 but I think it's an optional (and often left out) extension of previous versions. I don't see any reason to add new languages or syntaxes to Mantis. It's written in PHP so what's wrong with using PHP for the templates? There's no need for any middle-language to interpret templates from. |
|
PHP has (at least some) support for DOM and XSLT since 4.0, but the currently supported implementation is since 4.1. Yes, it is an optional extension just like mysql is. PHP5 implementation is much better, indeed. Also, take into account that most users already use a web browser cappable of xslt processing (IE 6, Opera 7, Mozilla, Firefox and other gecko browsers), we will have to process on server only a few requests. Smarty is always processed on the server side. Of course, for a solution like this we'll have to raise Mantis requirements a bit, but see bug 0005102. |
|
Here's a little article that shows how easily XSLT separates logic and presentation: |
|
I like the XSLT idea - we could easily generate a bug view page, an email notification or even some kind of pager text from the same XML output using different translations. I've had the opportunity to use XSLT (see http://xorph.sourceforge.net), and in my opinion it's not that complex - can't say anything about it's speed though. |
|
Template Wars:
I dare to say no real difference at all ( I'm saying nothing about performance), Now you have a nice PHP page (call it BL.PHP) that is reponsible for getting the a. BL.PHP And what if you want to change the position on screen of one existen value ? The secret IMHO it's not using template engine, but developing not mixing The effort need to convert an application like Mantis to use a template OK, this statement is valid if you reorganize the code using PHP. I hope I've made my point clear Regards Francisco |
|
<vboctor> thraxisp, relating to templates. |
|
Regarding : I'm part of the development team of Testlink, and we are using Smarty (also dtoproject is using Smarty), and to do language handling I have took YOUR lang_get function, simplify it and register it as new function on Smarty. Obviously using gettext is on option, but anyway you need a smarty plugin Just my 5 cents, and my compliments for you great product !! |
|
I've started implementing this feature using Smarty as the template manager, and smartyML for localization. This add-on can be found on the smarty wiki. I'm looking at the following directory structure:
This development is being done on a branch labelled EXP_TEMPLATE, in CVS so that progress can be reviewed. |
|
I have some questions relating to the template fallback that we discussed before. This means that if template xyz is not found in the current theme, then we retrieve it from a fallback or default theme. This way users can create themes that only override the the templates they need to override.
I assume that in the directory structure that you are proposing the tpl files should be indented one level to be within the theme1 and theme2 folders. My preference relating to localisation are:
|
|
I am currently using smartyML for languages. The files are almost identical to the current ones. I'll modify it to use the current ones for simplicity. The gettext based engines use a similar process as they define text to be translated as a block and then operate on the strings as part of the compile. |
|
Is there a change set that can be used with this for testing or is it looking like it will be some time before a prototype can be used? |
|
Regarding this issue I'd like to throw The Templating System of phpBB into the round, or better the eXtreme Styles MOD as both provide a quite powerful, but easy-to-use interface to create templates with probably only little stuff to change with mantisbt internals. The drawback of this solution would be, that the templater would need to know all language string at one or them being assigned at runtime by hand as needed for the template. But with the templater looking stuff up itself should do fine in most cases. Also I think XSLT can be a nice solution it often lacks browser support and webmaster's understanding. |
|
I have spent a little time on a proof of concept for using Smarty with Mantis, and have reached a point where the main layout of the site is now generated with a single Smarty template rather than calls to html_blah(). I have attached an archive of the files http://www.mantisbugtracker.com/bugs/file_download.php?file_id=1139&type=bug to be added to achieve this; instructions follow for trying it out. This proof of concept was developed against v.1.0.5, but should work with other versions. Unpack the archive and copy the 'tpl' directory to core (ie core/tpl). Make sure that the web server can write to the directory core/tpl/templates_c. In core.php, comment out the line require_once( $t_core_path.'html_api.php' ); Add the line require_once( $t_core_path.'tpl' .DIRECTORY_SEPARATOR. 'template_api.php' ); Try it out - you shouldn't notice any difference apart from the Smarty logo in the bottom right. You can revert back by simply reversing the changes in core.php and deleting core/tpl. This is only a proof of concept, so please don't expect it to do anything exciting, but if you look at the code and the page.tpl template you should be able to see the potential. |
|
A lot of discussion around templates...and a great improvement for the next release...By the way, when is this likely to be and will templates or the capability to modify forms i.e remove/update fields be part of the next release? |
|
Hello there, Any news on templates ? It seems a long time since any bug related was updated. Thanks |
|
I've looked in the latest Git revision and I can find no mention of a template system or Smarty at all, not even in a branch. Did the work being carried out by thraxisp disappear? I thought this was a "Roadmap 1.0" issue? |
|
Hey there! Haven't thought about something else than Smarty yet? Seems to me that this kind of template engine is superfluous nowadays. I mean, I don't have anything against this template engine particularly, but I kinda notice now that people are not using complex template engines. For example, using MVC framework such as Symfony or Zend Framework will demonstrate that you could have efficient templates mainly written in (x)html but using small portions of PHP code, which isn't too hard to learn and implement for designers! See Zend_View library if you're not convinced, but seems to me that it's quite an efficient way to implement templates. Just a few thoughts to help setting up the template system. Mainly I've heard people complaining a bit about the global design of mantisbt, compared to Flyspray for example. In my opinion, once you get used to it, this tracker is quite effective, and have a great community (and frequent updates, keep the good job up!). It just misses optional choice for a design. Thanks! Scorpe51 |
|
Just an update for anyone who's listening in: Since it's a gradual integration process, it should be possible to have a completely working version at all times so feel free to try it out. Note that it is possible that once the pure PHP template system is complete it will pave the way for a Smarty/whatever based implementation but TBH if pure PHP works, then there's no need to change it. |
|
If you're going to add templating engine, please consider PHPTAL: http://phptal.org or at least don't tie Mantis to any particular template engine. Smarty is definitely waste of time. However PHPTAL guarantees XHTML well-formedness and protects against XSS, which is a major advantage over "find'n'replace" engines. I've noticed e-mail-related bugs are marked as dependent on it. Please don't mix templates for e-mails with templates for HTML. e-mail and HTML need different, incompatible escaping, which 90% of the time seems unimportant... until you get entities messing up your e-mails or XSS exploits in HTML. |
|
Just want to "vote" for this issue. This should have a high priority. The lack of a nice set of templates is one of the major disadvantages of mantis, e.g. when you want to give customers access to Mantis. |
|
I am wondering if this approach is feasible: Define ALL the fields on the issue reporting page as custom variables, where some of them would be mandatory in a way that the user must use them for each issue (like Summary). If all the fields would be "custom fields" then rearranging the fields would be very easy. Also each project could be configured independently. (so lets say now I either display the "additional info" field at every issue, or disable it for every issue. If it would be a custom field, then I can select if a certain project should or should not use it). |
|
I like how this issue has been in the tracker for over a decade with absolutely zero observable progress whatsoever. There's no sense shooting for the moon if you're not going to finish. Even a dirty filthy awful hack of a solution is preferable to no results. |
|
mmxbass, it seems you did not take some time to check which of the feature requests mentioned in the description are resolved in current version.
|
|
Linking a forum topic with this item. I think the scope of this ticket (tagged "redesign") is too broad. Rather than regarding this as a monolithic effort where individuals take on the task of trying to do too much before losing their spirit, I propose we establish a definition for a mechanism that abstracts the UI as discussed here, which anyone can then use to implement into parts of the core as time permits. As long as many people use a single mechanism, we don't need one person to do everything. Per the forum discussion I propose a two-fold form of abstraction (initially described in the forum) : First, have the core call out to external code for UI rendering. This first step is implemented by moving hard-coded UI elements to ui_default_Foo functions in new ui_originalname.php files. As a random example: ui_account_prof_edit_page.php. The function names do not correspond to functions in the files. They describe what the UI is doing. To override that code (as with the template API) a user can implement ui_override_Foo. Personally I'd prefer a different mechanism in the core implementation: The result is now that the same code, without templates is now abstracted out of the core. A successful implementation will show the exact same UI before and after the abstraction of any UI sections. Second, re-implement those functions using a commonly accepted templating method. A successful implementation will show the exact same UI with the hard-coded UI or with the templated UI. If in the future a better template method comes along, we'll already have that code abstracted out and it will be much easier to implement default functions without affecting the "core logic", which is now only responsible for rules, not the UI. As a side benefit, for users who do not wish to use templates for some specific purpose, they will still be able to implement UI changes however they wish, simply by overriding the UI functions. If a templating system is implemented directly into core, a user would always need to override using that same templating method. The implementation described here allows much more versatility. Does this warrant another ticket for consideration? |
|