I was updating XOOPS Module Repository, and unfortunately the block showing latest modules was not looking very good, because the names of some modules were too long:
I was wondering how can I make them fit, and first I thought that I might need to do the truncation in PHP before submitting the value to Smarty, but thanks to Google, I found an easier solution, because the good guys at Smarty thought about that. It was enough to add to: this Smarty truncate command, where "11" was the number of characters I wanted to have: Quote: Now the block look much better: More info here: Smarty truncate If you have interesting tips, please share with the rest of us...

Great! I'm using it for a years to reduce title of article to 60 chars, and meta description to 180 :)

He he he! I am not a Smarty expert at all, so this was new for me.

It's always good to learn something new!

I hope, that people will start sharing tips here more often. Something that is totally obvious for one person, might be totally new for another.

You can also use the XOOPS core function xoops_substr() for this, which uses XoopsLocal to make it local aware...



But using the $smarty option may make it easier for some theme developers to tweak the look-and-feel of a specific theme without having to hack the PHP code...

Quote:
Yes, that was the idea behind using the Smarty function. Somebody might have a wider blocks, and could easily accommodate the length, so I didn't want to hard-code the length into the module. With the Smarty, I just modified it to fit our needs...

But this is a very good discussion, because we can learn more about what could we use in XOOPS to accomplish something. For example, I was not aware of "xoops_substr", so again, I've learned something new today

Mamba you show the community we can always find a better solution for the same obstacle.
Actually any developer can find a solution but the first solution is not always the best solution.

IMO to add feature/solve a bug, this priority should be followed by all developers in all modules/core
1- user side codes.
As a developer/debugger you should always try to find a user side solution. it is much better than manipulating php codes.

1-1- css: CSS is the best choice. You should always try to find a solution using css
pros: it is OS/Browser independent. even a very simple webmaster knows some css codes. It is local aware and multilingual.
cons: Nothing

1-2- html: It is good in combine with css

1-3- smarty: it is the third choice if you can not solve the issue using css/html
cons: it is not local aware. Xoops maybe use another template engine in the future.

1-4- javascript: it is the last resort in user side programming.
big disadvantage: user may turn the js off in the browser.

2- server side codes.

2-1- php: try to hack php codes only if you could not find a solution using css/html/smarty/js

2-2- mysql: altering/changing database is the last resort

It maybe time consuming to try to find a solution in all above ways but the outcome is best.

ok back to this issue Mamba raised, we can follow the above protocol.

1- css:
there is a solution you can use overflow: hidden;


then in template:

pros: it is local aware and multilingual
cons: it can not recognize letters. so maybe you end up with a part of the last letter show up.

2- smarty (Mamba stated)


cons: it is not local aware. it cannot be used in 2-byte languages like persian.

3- php (zyspec stated)
IMO it is better to use the class directly because in xoops 2.6 these kind of functions will be removed.


IMO the css solution is the best one.

Quote:
That's why those discussions are so important, so we can learn from each other, and not be afraid that our solution might not be the best
We need to be more open to learn from each other!

And thanks for all your points here. It seems like we will need more CSS/HTML exports who can help us here! I am definitely not one of them

#irmtfan

My option to use PHP is still available in XOOPS 2.6. The API may be changing in XOOPS 2.6 to use the static call but the functionality still exists. Right now there's just a function wrapper around it. Until the class is autoloaded in XOOPS 2.6 it's better to use the current method in XOOPS 2.5.x - which is why I used it in the example above.

Maybe this is off topic and should be in a different thread but - I, as a module developer, and not a UI CSS guru would find it useful if a small team of people could update xoops.css and then also provide documentation of when these are to be used. I asked for this years ago, but it got no traction. The problem is that I'm STILL just a module developer and not a front end CSS guru - so my templates always end up looking mediocre.

Having things like .width90 is useful but it would be better to have a class that is named something like .max-width-table { width: 90% } would be better. I frequently use things like width90, width70, etc. but it would be better if there were names that reflected what they are used for instead of just 'repeating' the attributes.

Something like:


seems better than:


Then if an admin, etc. needs to modify how error messages look they can just edit the CSS and not have to find all the places where the color red is used and figure out if it's an error message or not.

It would be REALLY useful if we could have a document that outlines the minimum CSS requirements for a XOOPS theme too (maybe that's what xoops.css is intended to be?). It'd be good if module developers could count on specific classes, ids, etc. to always be present in a theme so we can take advantage of them instead of either including our own in each module or just hard coding the styles, etc.

Just a thought, not a complaint.

@zyspec:
about xoops_substr function:
I should explain more in the last post.
xoops_substr is deprecated in 2.6.0 and will be removed in future 2.6 versions. so why we use this function in our modules in 2.5.5 when we can use the XoopsLocal class which is more understandable and consistent. Yes as you stated well currently in 2.5.5 we should load the XoopsLocal class manually, but IMO it is better to use all possible ways in current modules to make it more compatible with 2.6

About Xoops.css:
Very well mentioned.
I will think about sending a request to update xoops.css for xoops 2.6
IMO xoops.css should have the minimum required css codes with a single line to show the usage. It should be enough for a proper design.
currently there is very few css3 codes. xoops.css should be updated frequently and also documented as you suggested.
Also different class names is really needed.

@Mamba:
Quote:
I dont know css well too and im not a designer but i always try to stick to my guide lines and priorities.
So CSS is the first solution for any user side features/bugs.
Yesterday after submitting, I searched about "truncating strings using css" and find this link:
http://quirksmode.org/css/user-interface/textoverflow.html
So my last suggestions need some enhancements.

I suggest to add these css codes to xoops.css


It will work very well. I test them in userlog!