Dear GadgetMn,

I found both StudioC (michael) and Brad logic are great and both have some advantage and disadvantages. My requirements best fit with Brad logic, the way I organised my website.

Regards,

Hi Michael:

Thanks for your effort. Initially I apply your logic and it was working great but Brad just shows me another way to do the same stuff.

I looked into your website "xoopsfactory" and I really liked it. Its wonderfull. Though I take help from Bable Fish to read all content.

Thanks again./

@shivaji, yes... your right, xfactory will be in english soon, as i find someone who#s english is better than mine

hello to the creatives,

you will always find 100 ways to catch a cow...
i for one will always prefer using that way on which you don#t have to hack the core.. and i#m not only talking about possible updates...

if there#s more than one webproject, you have to look at you will go crazy looking what you#ve done in each project and upping these files each update comes. for me its easier just to have look at the theme.html and the blocks to see enabled functions.

let me say .. i prefer "displayhacks" !
but its still powerful to see that different ways here to come to the same result.

this is the way to get new ideas of using XOOPS and we need this... at that time, XOOPS team decided to use smarty, three drops as big as cherrys run out of my eyes as i read this [just going to be used with that theme.php] ..
now XOOPS and smarty engine show its fully possibilities, but we haven#t reached 10 % of its power yet for sure...

Now it#s our turn to put that what the core team included within functions and querrys in those clothes our VISITORs want to see...

@svaha ... it#s great to see that i#m not the only one thinking too difficult..
sometimes we should think easy as it is but sometimes around 5 corners..



greetings
from
GERMANY


michael

Hi, all:

Perhaps a long term solution could be to ask the developers to include conditional logic in the modules, something like...

Imagine a config option that says: this module's blocks will have title: yes/no. Assign this value to a variable $bt. Then, in the template, you could have something like





Could this work?

Cheers

Quote:

less code, better result. Only requires Module Developer to go through this thread once.

Hsalazar,

I like this, and why stop there. If you took this further, a "displayed" block could simply be an instance of a block class.

In the Admin->Blocks section you could configure the attributes of the instance. If deliverd in this way, this would allow block re-use as you would only be instantiating an instance of the block rather than the block itself, all controlled from the admin system.

Cheers,

GadgetMn

Interesting, I was pondering this myself. I'm not a fan of naming images to match the search since you might want to change the text someday and now have to change images to follow it.

For giggles I wanted to see what happens if I specify an image location in the Module name. I suspected that the sanitizer would trap it and spit it out. That is what happened but not before the final Submit Changes. The confirmation form showed my image and text just as I would have wanted it. The final Submit of course dropped that idea. Was fun anyway.

I would like to specify an object's text name And image in the same place. A library of images like the images core or smilies db but slicker. All site images are db'd and available for a variety of uses and associations.