cpg and tables

[chtito]

I (too) have written a completely tableless theme that i will release as soon as it is finished. The theme is completely functional and does not incorporate a single table. The size of a typical page is 70% smaller. Still, from outside the theme, tables are created.

My request is this: there are many places in the code where the "starttable" is called and then a table is created. In some cases it is legitimate, in some cases, not.

But i understand perfectly that some people prefer the table layouts, this is a matter of taste.

SO

I suggest that when the use of a table is dubious (example: to display the list of smilies), there be a "if function_exists('theme_do_something')" that checks for the existence of the corresponding function in the theme.

More generally, i don't think that any html formatting (example: the ubiquitous tag <b>) should be performed outside of the theme php file. There should be a call to a theme function instead.

Moreover the "style" attribute should be used only when a dynamic change is performed. The normal way to give a style to an element is to give it a class name and to set the style in the css file.

Following these simple principles would simplify the code of cpg a tremendous lot, and would help the designers to do a better job.

Reactions?

[Joachim Müller]

I fully agree to what you say. All the overhead formatting inside the code is there for historical reasons (coppermine is a group effort, the themeing engine being based on a very old version of phpbb's theming engine) and should be replaced in future versions with less generic code and functions that are easily customized. Yet we have to decide with each step we take if the modification makes things easier for the end user - adding functions just for the sake of purity (avoiding tables under all circumstances) is not an option if it makes creation of custom themes more difficult for the majority of users.
As a first step, the next version of coppermine (cpg1.4.x) will be xhtml transitional compliant (but not tableless), further modifications in the core code are planned. Currently, we're discussing a new theming engine inside the dev board.
You're most welcome to join the discussion by submitting your changes and giving your thoughts. Preferably you'll want to take a look at the cpg1.4.x code and base your work on it, as (from a developers point of view) the cpg1.3.x code is "dead" already. To do so, start reading the sticky thread on the "cpg1.4 testing/bugs" board.

Joachim

[chtito]

Yet we have to decide with each step we take if the modification males things easier for the end user - adding functions just for the sake of purity (avoiding tables under all circumstances) is not an option if it makes creation of custom themes more difficult for the majority of users.

I agree. I don't think that tableless design should be imposed, but rather left as an option. That is why my proposition is that before any html formatting code is perfomed, to check if a theme function exists. An example is the slideshow function, that first checks whether the 'theme_slideshow' function exists.

These changes are easy to make, and the theme design is also easy. If the designer wants to use table, he does not write the function 'theme_something'. If he wants a tableless design, he has to write a 'theme_something' function.

What i'm basically saying is that the tableless and tablefull worlds can perfectly live together, with only minor changes to the code.

I'll have a look at the discussions in the dev board.

cheers,

== Olivier

[Joachim Müller]

I'll have a look at the discussions in the dev board.

Sorry, you can't - it's restricted to dev team members

Joachim

[chtito]

I'll have a look at the discussions in the dev board.

Sorry, you can't - it's restricted to dev team members

Is that so?  :-\\ Would you mind giving me access to this board? (you're talking about a board like this one, right?) I would appreciate to be aware of the future changes to coppermine before I change the code.

I published in that thread the simple changes that i suggested above (the breadcrumb function needed a lifting anyway ). I hope that these changes will be incorporated in the version 1.4.

cheers,

== Olivier

[Joachim Müller]

Would you mind giving me access to this board? (you're talking about a board like this one, right?) I would appreciate to be aware of the future changes to coppermine before I change the code.

So far, this is only being discussed in general, without actual code changes. Dev board access is restricted to team members, however new team members are welcome. We haven't agreed on a special recruting / membership policy yet, so this is being currently decided case-by-case. Usually we ask active board members (who have contributed mods/hacks) if they're interessted in joining the team.

I published in that thread the simple changes that i suggested above (the breadcrumb function needed a lifting anyway ). I hope that these changes will be incorporated in the version 1.4.

Moved the thread you're refering to to the feature requests board, flagging it as valid. Needs looking into - hopefully, Tarique will have the time to do so soon.

Joachim

[chtito]

Would you mind giving me access to this board? (you're talking about a board like this one, right?) I would appreciate to be aware of the future changes to coppermine before I change the code.

So far, this is only being discussed in general, without actual code changes. Dev board access is restricted to team members, however new team members are welcome. We haven't agreed on a special recruting / membership policy yet, so this is being currently decided case-by-case. Usually we ask active board members (who have contributed mods/hacks) if they're interessted in joining the team.

I see. But i don't see any point in writing code that will never be implemented because of changes in the code policy that i'm not aware of. So i don't think that i'll write any further code if i have not at least reading access to the dev board.

I'm just willing to help, here.

If you don't want/need this help, please just say it boldly and i'll stop rambling in these boards, thus returning to a more normal life .

Just a last obvious remark: the code of cpg is excellent, but it's getting old. Many parts of the code could do with a real cleaning. Without cleaning the code it will just be harder and harder to implement new functionalities. I suppose that the developers are aware of that.

Bye,

== Olivier

[Joachim Müller]

I appreciate your readiness to help, and I will bring this issue up on the dev board.

Joachim