View Issue Details

IDProjectCategoryView StatusLast Update
0004227mantisbtbugtrackerpublic2020-08-25 04:50
Reportergrangeway Assigned To 
PrioritynoneSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Summary0004227: 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.
Allow users to define the mandatory fields (eg: by definining [field_name]_mandatory hidden field in the template).
Allow users to customize the look 'n' feel of Mantis by providing their own templates.
Allow users to define templates to be used in generation of email notifications.
One theme may include several templates for the same page (same like simple/advanced now).
Get rid of redundant code by providing one view page rather than simple/advanced/print).
Allow users to customise fields that appear in View Issues page via a template (unless it is customisable as a setting per user per project).

Tagspatch, redesign
Attached Files
Smarty_for_mantis_PoC.zip (125,829 bytes)

Relationships

related to 0000798 closedjlatour Email Templates 
related to 0006220 closedvboctor Change order of fields 
related to 0007206 closed Ability for Management/Administrator to change "Project" of bug. 
related to 0009818 closedrombert iphone/mobile device optimized site 
related to 0017919 closedsyncguru Modernize Mantis UI 
parent of 0004708 acknowledged show status in email subject 
parent of 0006628 closedvboctor Skinning 
has duplicate 0002240 closedgrangeway Displayed fields not as required 
has duplicate 0006829 closedgrangeway emails design should be improved 
has duplicate 0002464 closedgrangeway Over general CSS 
has duplicate 0007326 closedryandesign Use a Templating System to produce Page Output 
has duplicate 0007607 closedryandesign Easier style editing 
has duplicate 0009597 closedvboctor Customization of Appearance for Fields on "Report Issue" 
has duplicate 0003736 closedvboctor Implementing Themes 
related to 0003681 closedjlatour Template System 
related to 0001872 closedvboctor Super simple report / simple report / advanced report 
related to 0006671 closedryandesign Tracker themes, user selectable or not. 
related to 0006768 closedatrol Remove fields Reproducibility, Severity and priority from one project 
related to 0006785 new 0007613: Move "product version" field up 
related to 0002814 closeddaryn Prefix CSS class names 
related to 0003468 closedatrol 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 closedatrol Variables for Colors in Webpage 
related to 0012339 new Design proposal for "View bug" to increase readability and reduce clutter 
related to 0012685 closedatrol 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.

Activities

jotarp

jotarp

2004-09-16 03:51

reporter   ~0007619

template_example.
I like MantisBT. It is planned to use it in my company (public organization, 40 users), but I need some customization in the look'n'feel. I think that to use a template engine, smarty or other, is an error ( please, read: http://www.sitepoint.com/article/beyond-template-engine ). I have uploaded an example of how it would be possible to be done (with the just-php-template-engine from that article).
Test it and comment. Thank you.

philippg

philippg

2004-11-07 15:57

reporter   ~0008270

In case you have not started on it yet, please do not use smarty.
The prior poster is - in his article - correct in saying, that smartys approach is good.
However, having used Smarty before, I'd like to say that Smarty

  • is too big (especially for the job)
  • has too much funcionality that makes it become "PHP light-edition"
  • has far too many inconsistencies in terms of style and usage
  • is not very efficient

Apart from that, I somehow refuse to use a template engine, which talks about itself having a "Kernel".

fman

fman

2004-11-08 09:53

reporter   ~0008284

I'm a bit scared about the effort involving a major re-write an testing
of Mantis.
I think that to get rid of redundant code , it's enough to start developing
php functions to manage in a simple way the User Interface, instead of
using the pattern: CTRL-C , CTRL-V .

Anyway you have done a great work with this product !!!.

Thox

Thox

2004-12-13 09:24

reporter   ~0008597

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:

http://www.massassi.com/php/articles/template_engines/

bloodrath

bloodrath

2004-12-17 07:45

reporter   ~0008692

i've personnaly rewrite some mantis page with smarty template engine. Why will you say ? because i need a cleaner view of php code.
Sorry but i could'nt be agree with this (extract from the link posted) "In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code". mixed php+html+css+javascript cause a web page becoming ugly to maintain, this is the reason why i love smarty (and other template engine) : keeping html page cleaner.
I think the reason why i prefer smarty is the ability to create plugin.

So to close this note i say Wonderful !

Thox

Thox

2004-12-17 07:58

reporter   ~0008694

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.

bloodrath

bloodrath

2004-12-20 04:01

reporter   ~0008736

excuse me but as smarty is basically php, i think it's obvious that "plain old PHP functions" could reproduce smarty plugin process.
sure it was slower than coding function directly but not slower than any other wrapper

please have a look http://www.phpinsider.com/smarty-forum/viewtopic.php?t=102&postdays=0&postorder=asc&start=0
(brian himself taking part of the thread).

DamienMcKenna

DamienMcKenna

2005-01-12 23:57

reporter   ~0008993

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.

jferraz

jferraz

2005-01-14 22:06

reporter   ~0009026

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):

<pre>
(bug-view-page mode="simple")
(bug bugid="4227")
(summary)Roadmap 1.0 - Templates(/summary)
(description)...(/description)
...
(relationships)
(relationship role="related" bugid="798")
(status)closed(/status)
(resolution)duplicate(/resolution)
...
(/relationship)
...
(/relationships)
...
(/bug)
(/bug-view-page)
</pre>

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.

Thox

Thox

2005-01-15 03:20

reporter   ~0009027

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.

jferraz

jferraz

2005-01-15 10:49

reporter   ~0009030

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.

gtomlin

gtomlin

2005-01-15 11:13

reporter   ~0009031

Here's a little article that shows how easily XSLT separates logic and presentation:
http://www.quepublishing.com/articles/article.asp?p=27861

vwegert

vwegert

2005-07-19 16:25

reporter   ~0010880

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.

fman

fman

2005-09-22 02:20

reporter   ~0011422

Template Wars:
I would to understand the big advantages adn difference between developing the
presentation layer /user interface logic using:

  1. XSLT
  2. Smarty
  3. PHP functions.

I dare to say no real difference at all ( I'm saying nothing about performance),
regarding code cleaness. All you have done (the template engine force you to do this) is take your code and organize it better trying to draw a clear separation
between business logic (bl) and presentation logic (pl).

Now you have a nice PHP page (call it BL.PHP) that is reponsible for getting the
data, prepare it and send to the presentation logic, call it PL.PHP, PL.XSTL or
PL.tpl (smarty).
But If I'm not wrong if your user want to add a NEW info at user interface
level, and BL.PHP has not getting it, then the user NEED TO modifiy:

a. BL.PHP
b. PL.(what you want).

And what if you want to change the position on screen of one existen value ?
You need to modify PL.XSTL, or PL.tpl, or PL.PHP, then I see no difference.

The secret IMHO it's not using template engine, but developing not mixing
presentation logic and bussiness logic in the same page, then
the anwser if better code organization and modularization.

The effort need to convert an application like Mantis to use a template
engine will be enormous, and you will need a lot of regression testing.

OK, this statement is valid if you reorganize the code using PHP.
The difference (not to say no to new things) is that you need to
gain confidence with new languages (XSTL, smarty) instead of usign
you PHP knowledge.

I hope I've made my point clear

Regards

Francisco

vboctor

vboctor

2006-04-16 09:44

manager   ~0012509

<vboctor> thraxisp, relating to templates.
<vboctor> the obvious options are:
<vboctor> - Smarty
<vboctor> - PHP templates, i.e. use PHP as the template engine and use decipline to make sure that in the template code we are not doing coding that is not relating to presentation.
<vboctor> for both options we need to restructure our code.
<vboctor> for example, smarty uses the concepts of functions and modifiers. These are used from templates
<vboctor> For example, a bug_id modifier formats 23 as 000023
<vboctor> I believe if we use PHP templates, we can easliy port to any template engine later on if we find the need.
<vboctor> we should implement a template class in core that we use as our mini template engine.
<vboctor> takes an associate array with all the variables + a template file name.
<thraxisp> 'evening, vb123. I had originally thought of writng the templates in php with calls to format any of the data required.
<thraxisp> Smarty seemes to have dome a lot of that already, but interfacing to it does require a lot of rework.
<vb123> I am not sure what is the best option.
<vb123> smarty vs php custom template class
<vb123> smarty introduced a dependency on another package + requires setting up write access to a templates_c folder.
<vb123> which complicates the installation process.
<vb123> I'm not sure if Smarty compiled templates will be faster than php custom templates.
<thraxisp> The only way to pass information to it is via variables, or objects. Our current code uses a lot of function calls. I've prototypeed some of this using objects.
<vb123> it = smarty?
<thraxisp> Yes, Installation is harder, particularly if you don't have shell access.
<thraxisp> yes. it = smarty
<vb123> usually template engines allows the script to register some variables that are accessible from the templates.
<vb123> The templates can also use (in case of Smarty for example) modifiers which are functions taking one parameter and functions.
<vb123> For Mantis, we need to separate the calculation of data from the formatting.
<vb123> For example, print_blah_options() typically puts the combo-box options and calculates them.
<vb123> we need to separate the calculation of the entries, from the code that formats them for a combobox.
<vb123> I think we should start by refactoring the code to allow for the use of templates.
<vb123> during this period we should php templates.
<vb123> if we find a reason, we can easily port our templates to Smarty.
<thraxisp> That's fairly straightforward. I was looking at things like the config_get() calls.
<vb123> I think we should create a themes folder, and classic folder under it. This folder should have the same UI as now but using templates.
<vb123> templates should be called xxxx.tpl.php
<vb123> we should use a templates class to make sure that the templates only access variables registered with them, rather than access to global variables.
<thraxisp> I was also thinking of using the templates to implement simple and advanced views.
<vb123> we can have the list of supported views as a configuration variable. For example:
<thraxisp> The problem with the assignment is that there are possibly hundreds to assign given the amount of configuration we do.
<vb123> simple, moderate, advanced.
<vb123> Then we open issueview<mode>
<vb123> from the templates.
<vb123> This shows how we can allow users to use configuration to make mantis use extra templates.
<vb123> I also think we should use fallback themes.
<vb123> For example, use theme "Victor" and if template is not found, use theme "classic".
<thraxisp> I was thinking that we would have view.php open templates/x/view.advanced.tpl.php for advanced.
<thraxisp> I agree on fallback.
<vb123> This way I can define a new theme that only overrides a couple of templates or add a couple of new ones.
<vb123> yes, that's what I meant relating to view advanced stuff.
<vb123> we should also support project specific themes
<vb123> project x use theme a, project y use them b, a and b may use classic as their fallback theme.
<thraxisp> Do we want to make it simpler to hide a field? I can't see someone copying templates and editing for a single field.
<vb123> this requires some thought, since doing so in the templates will also compicate them, since the hidding of a field may affect the page layout.
<vb123> initially creating an overriding theme shouldn't be too hard.
<vb123> I also don't think that we should implement themes/templates on a branch.
<vb123> if we use the approach we are discussing here, then it can be done as a gradual thing.
<vb123> the steps will be:
<vb123> 1. build the infrastructure.
<vb123> 2. Change one page at a time to support templates.
<vb123> The main pages are:
<vb123> 1. view/update/report - advanced/simple
<vb123> 2. view issues (e.g. ability to define the columns)
<vb123> although this may be defined via configuration.
<vb123> rather than templates
<vb123> the columns is not really part of formatting and hence it should be part of the configs.
<thraxisp> Handling visibility (and editability) of fields in the template would be useful in handling updates and reporting from the same view.
<vb123> the templates should be as smart as needed, but no more.
<vb123> ideally they should be stupid, but in some scenarios we will need some if structures in there. The decisions should ideally all be made by the calling script.
<thraxisp> The current bug_change_status_page is a smarter template. It tries to show fields that need to be changed with the change in status. I was thinking that it should really look like the update page with the changeable fields enabled.
<thraxisp> What's the best way to document the plan?
<vb123> It is ok that the template does some checks and accordingly changes it's output.
<vb123> However, the template should look as follows:
<vb123> if ( a ) {
<vb123> }
<vb123> rather than
<vb123> if ( a && b || c ) {
<vb123> }
<vb123> where a, b, c are either variables passed to the template or functions that are called by the template.
<vb123> e.g. can_edit_blah()
<thraxisp> That's what I was thinking. Like:
<thraxisp> if ( visible['field'] ) {
<thraxisp> echo content;
<thraxisp> }
<vb123> the template should be able to call functions that are defined in the core APIs or in the script that called it.
<vb123> yep, the case you mentioned is where the output is controlled by the variables registered with the template when running it.
<vb123> we should also support the case where a template internally refers to other templates.
<vb123> e.g. template for view issue page may use header, menu, then the bulk of the view, then footer.
<vb123> the main template should be able to pass data to the templates it is calling internally.
<thraxisp> The other big problem with Smarty is the language handling. I've seen plugins for that.
<vb123> yep, we need to provide an easy way to handle this. Perhaps we can consider using the gettext
vb123> I'll post the script of our discussion in the templates issue in the bugtracker.

fman

fman

2006-04-27 10:38

reporter   ~0012741

Regarding :
"The other big problem with Smarty is the language handling. I've seen plugins for that. yep, we need to provide an easy way to handle this. Perhaps we can consider using the gettext"

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.
Everything is working OK.

Obviously using gettext is on option, but anyway you need a smarty plugin
to handle it, and have one problem for mantis (IMHO) the strings.txt files
can not be used.

Just my 5 cents, and my compliments for you great product !!

thraxisp

thraxisp

2006-04-27 22:14

reporter   ~0012747

Last edited: 2006-04-29 13:13

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:
<pre>
|- mantis

  • core
    | +- smarty (smarty engine and support)
  • languages
    | +- eng
    | +- etc....
  • themes
    | +- theme1
    | +- header.tpl
    | +- footer.tpl
    | +- page.tpl
    | +- theme2
    | +- page.tpl
  • themes_c (compiled templates)
    | +- theme1
    | +- theme2
    </pre>
    Parameters for the pages are passed to the page template through arrays or objects. I've started with the view pages. In this case, an array ($show) is used to pass information that may be used to control the display. Another array ($display) is used to pass configuration information from the config system to the template. Bug information is passed through an object that already existed in bug_api.php.

This development is being done on a branch labelled EXP_TEMPLATE, in CVS so that progress can be reviewed.

vboctor

vboctor

2006-04-27 22:56

manager   ~0012748

Last edited: 2006-04-27 23:23

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.

  1. Once the templates are resolved, do the compiled version get added to the themes_c/my_current_theme independent from where the template was fetched? This way in future references we just use the compiled version from the current theme and hence no need for further resolutions.

  2. If the user overrides header.tpl, will this be picked up from view_issue.tpl that is sourced from the fallback theme?

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:

  1. Implement a smarty plug-in that uses our current language files without changes. Consider using fman's work (see previous note).
  2. In the future, consider replacing this plug-in and our language files with gettext. This will allow us to re-use the standard infrastructure that are used to manage and update such standard format. An example tool is http://www.poedit.org/ , but I'm sure there are others.
thraxisp

thraxisp

2006-04-29 13:21

reporter   ~0012755

  1. Yes,the compiled versions get added to the themes_c/ directory corresponding to the theme directory the template came from. They are also stored separately based on language. This does imply that the theme is compiled once, but it does get resolved each time the page is loaded.

  2. Yes. Smarty uses a search order to find templates. I've set it up to use the user selected theme first, the, 'classic' This could be extended to do user/project/classic. All templates, including 'included' ones follow this path.

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.

DGtlRift

DGtlRift

2006-07-17 10:26

reporter   ~0013103

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?

BenBE

BenBE

2006-08-02 20:53

reporter   ~0013184

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.

djnz

djnz

2006-10-04 19:27

reporter   ~0013582

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&amp;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.

dino

dino

2007-08-20 02:25

reporter   ~0015460

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?

lbertin

lbertin

2008-02-16 14:27

reporter   ~0017063

Hello there,

Any news on templates ? It seems a long time since any bug related was updated.

Thanks

milliams

milliams

2009-03-30 13:39

reporter   ~0021299

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?

scorpe51

scorpe51

2009-04-01 07:34

reporter   ~0021352

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

milliams

milliams

2009-04-02 18:53

reporter   ~0021374

Just an update for anyone who's listening in:
I've started work on this. I began using Smarty but given the design of Mantis it's neater to implement it using pure PHP. If anyone wants to try it out, you can find it in the 'phpt' branch of my mantisforge fork at http://git.mantisforge.org/w/mantisbt/milliams.git?a=shortlog;h=refs/heads/phpt

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.

klkl

klkl

2009-11-20 11:32

reporter   ~0023776

Last edited: 2010-01-12 10:47

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.

blueberry

blueberry

2010-01-11 08:25

reporter   ~0024127

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.

istvanb

istvanb

2012-04-11 10:19

reporter   ~0031642

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).

mmxbass

mmxbass

2015-11-03 15:14

reporter   ~0051809

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.

atrol

atrol

2015-11-04 02:54

developer   ~0051813

Last edited: 2015-11-04 02:56

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.

Even a dirty filthy awful hack of a solution is preferable to no results.
Dirty hacks will not make their way into the standard product.
The right way to implement dirty hacks is to fork our repository on Github and to implement them in a private branch.

Starbuck

Starbuck

2018-04-23 16:56

reporter   ~0059657

Last edited: 2018-04-23 17:17

Linking a forum topic with this item.
The relation is that I opened a discussion about creating a FAQ to help people with common questions about UI changes. That led to my suggestion for abstracting UI changes out of the core for replacement by custom code - or using templates. Then @atrol mentioned this ticket.

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:
if(!function_exists('ui_foo')) { function ui_foo(...) {...} }
That way we don't need to deal with "default" and "override" function names.

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?