Hi all
I think it is pretty obvious that all themes will share quite big load of CSS. Originally I though about extracting these bits to Theme class methods, but now I think it would make things even harder to maintain.
What I feel would be better to create core CSS file, which would be always included and theme authors will just override/extend it.
This way, we can make changes in core without breaking older themes too much - maybe some things will not look 100% intergrated, but at least the layout won't be broken.
Currently original and pmahomme themes share about 2500 lines, they differ in 1000/500 (pmahomme/original) lines.
On 14/05/12 12:58, Michal Čihař wrote:
Hi all
I think it is pretty obvious that all themes will share quite big load of CSS. Originally I though about extracting these bits to Theme class methods, but now I think it would make things even harder to maintain.
What I feel would be better to create core CSS file, which would be always included and theme authors will just override/extend it.
This way, we can make changes in core without breaking older themes too much - maybe some things will not look 100% intergrated, but at least the layout won't be broken.
Currently original and pmahomme themes share about 2500 lines, they differ in 1000/500 (pmahomme/original) lines.
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
Thoughts?
Bye, Rouslan
Hi
Dne Mon, 14 May 2012 13:11:16 +0100 Rouslan Placella rouslan@placella.com napsal(a):
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after sending mine :-).
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
I think this is really good approach.
On 14/05/12 13:42, Michal Čihař wrote:
Hi
Dne Mon, 14 May 2012 13:11:16 +0100 Rouslan Placellarouslan@placella.com napsal(a):
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after sending mine :-).
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
I think this is really good approach.
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file, it will necessary to add the name of the new CSS file (without any extensions) to the $css_files array in the Theme class so that it can be picked up and proceesed by PMA.
Bye, Rouslan
Hi,
2012/5/19 Rouslan Placella rouslan@placella.com:
On 14/05/12 13:42, Michal Čihař wrote:
Hi
Dne Mon, 14 May 2012 13:11:16 +0100 Rouslan Placellarouslan@placella.com napsal(a):
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after sending mine :-).
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
I think this is really good approach.
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file, it will necessary to add the name of the new CSS file (without any extensions) to the $css_files array in the Theme class so that it can be picked up and proceesed by PMA.
Bye, Rouslan
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC and on the demo server), but I don't know if this was caused by your commit.
Kind regards,
Dieter
Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 19/05/12 17:44, Dieter Adriaenssens wrote:
Hi,
2012/5/19 Rouslan Placellarouslan@placella.com:
On 14/05/12 13:42, Michal Čihař wrote:
Hi
Dne Mon, 14 May 2012 13:11:16 +0100 Rouslan Placellarouslan@placella.com napsal(a):
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after sending mine :-).
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
I think this is really good approach.
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file, it will necessary to add the name of the new CSS file (without any extensions) to the $css_files array in the Theme class so that it can be picked up and proceesed by PMA.
Bye, Rouslan
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC and on the demo server), but I don't know if this was caused by your commit.
Yes, it's clearly caused by my last commit in that branch. That said, I'm not sure how to fix it right now.
Bye, Rouslan
On 19/05/12 17:44, Dieter Adriaenssens wrote:
Hi,
2012/5/19 Rouslan Placellarouslan@placella.com:
On 14/05/12 13:42, Michal Čihař wrote:
Hi
Dne Mon, 14 May 2012 13:11:16 +0100 Rouslan Placellarouslan@placella.com napsal(a):
I mentioned a few days ago that I'm already working on this, thought I didn't get into details, so here's my plan.
Well I had some mail backlog so I managed to read your mail just after sending mine :-).
I will merge theme_left with theme_right first (we'll only have one frame in 4.0). Then split the resulting file into smaller files, e.g.: common.css, pmd.css, gis.css, rte.css, etc... The idea here is to make the css files more managable, right now it looks to me like everyone just appends new stuff at the bottom of our huge files creating an ever bigger mess out of them.
Then all of the resulting files will be reassembled back into a single file by the Theme class at run time and sent to the browser along with a cache header.
As far as the code duplication goes, the idea is to make all of the new, smaller, css files overridable. So only the default theme will include all the css files and if another theme is selected and it, for example, only has a common.css file, all the other files will be included from the default theme.
I think that this approach will both minimise code duplication and improve the maintainability of CSS files.
I think this is really good approach.
I've implemented my idea in pull request #67 [0].
Anyway, there is still room for improvement in splitting the new common CSS file as I've only factored out the few obvious parts that I found.
If, in future, anyone wants to factor out a part of the common CSS file, it will necessary to add the name of the new CSS file (without any extensions) to the $css_files array in the Theme class so that it can be picked up and proceesed by PMA.
Bye, Rouslan
Looks good, I renamed a private variable to comply with coding style.
When I tested, changing the theme didn't work (I tried both on my PC and on the demo server), but I don't know if this was caused by your commit.
Fixed in git now.
Bye, Rouslan
-
Dieter Adriaenssens -
Michal Čihař -
Rouslan Placella