Re: Module Standardization Team - looking for volunteers [Blue Move]

Search

Donat-O-Meter


Stats
Goal:	$100.00
Due Date:	May 31
Gross Amount:	$65.00
Net Balance:	$61.80
Left to go:	$38.20


Donations
studioC ($25)May-17
Anonymous ($15)May-16
Anonymous ($25)May-4

Learn XOOPS Core

Click to see original Image in a new window

OOP with XOOPS

XOOPS API

Cumulus Tag Cloud

2 2.5 2.6 3.0 2013 Abuse AntiHarvesting AntiMalUser AntiSpam API ASP Beats billige black block Blocking Blocks blue Captcha cell Christmas chronolabs Client content Conversion demo Dictionary docek download Dresses editor evden eve Evening facebook floor forms framework free herre Honeypot Human Hymn instant-zero IP jQuery kantor Karaoke lamps Load log logger mobile module modules Monster MyAlbum-p newbb news online PageRank Party Permissions pink Plugin pollos portal Prevention profile project Protector publisher REST Rights rmcommon Room sale security Server site Smarty Spam stem StopForumSpam Studio tag tags tdmcreate Theme themes Transaction Twitter userlog website Whitepaper Wishcraft XFriendica xoops Xortify ZendFramework

more...

New Users

Registering user

# 136034

kennabee

Welcome to XOOPS!

Forum Index

Board index » Xoops Development » XOOPS Module Development » Blue Move » Module Standardization Team - looking for volunteers

Bottom Previous Topic Next Topic Register To Post

« 1 (2) 3 »

#11 Posted on: 1/11 4:29 Re: Module Standardization Team - looking for volunteers

good conversation.
I think Mamba more think about php codes inside modules but the topic goes to images.
Anyway about css3 buttons i did some attempts in newbb and i am satisfy with it.
Now i think we can implement that bootstrap way for buttons too. it just need to add a customization method for designers to add more classes. Of course now the classes can be added by designer but it is hardcoded in newbb/class/icon.php like 173


if (in_array( substr($image,0,2),array('t_','p_','up') ) && $extra === "class='forum_icon'") {

            $extra ="class='forum_icon forum_button'";

        }

so the designer can add the classes required for bootstrap.

but about "sprites" I think it is not good for a general CMS but it is good for a specific high traffic website like FB and yahoo.
did you read these interesting comments?
Quote:

While I understand the principles behind it, it really just doesn’t make a lot of practical sense (aside from the request argument) to do this.

The reason I mainly dislike this probably comes from my bias of having worked on a site using it, that I didn’t originally design. I didn’t have the original graphic files, and it was a pain to have to try to recreate it from scratch (when all I wanted to have to do was change one little icon and not have to worry about the other 4 in the same graphic).

Better site performance, maybe a little. I would say the biggest time hit on most sites are server-side these days, especially with all the database driven platforms out there now.

It’s worth it if you’ve got the time I say, but I say especially if you are under deadlines it could cost you more than it’s worth.

and this:
Quote:

I think there is probably a sweet spot where using CSS sprites is the most beneficial to use. If you have a fairly low traffic site on a decent server…yeah…it probably doesn’t matter to much. If you are running a super high traffic news portal like yahoo.com, there are definite benefits and using them to reduce server requests is a must.

so the customization would be a nightmare for a simple webmaster:D

Top

irmtfan

Module Developer

Joined:
2003/12/7 14:14

From In the middle of nowhere

Group:
Registered Users
Community Coordinator (temporary)

Posts: 3304

(Show More) (Show Less)

#12 Posted on: 1/11 5:03 Re: Module Standardization Team - looking for volunteers

Quote:

I think Mamba more think about php codes inside modules but the topic goes to images.

My focus is on everything that will help us with:

- faster module development by reusing existing parts (source code, plugins, images, etc.) that have been tested and are bug-free

- lower learning curve for the users (because all standard features look the same, and work the same)

- easier maintenance of modules (so we don't have to analyze the module in detail first, to understand what each little part does and making sure that we don't break anything by changing something in one place)

- more efficient documentation writing (so we can reuse parts dealing with the same features of the module)

The reality is that we don't have thousands of developers working on XOOPS, so with our limited resources we have to work "smarter"

I hope that all agree that using the XOOPS 2.5.5 Admin GUI for all modules was a first step in the right direction. But there are many more opportunities to streamline development and maintenance activities

So if you see a good feature that you think it should be in all other modules, let us know.

To give you an example, Mastop modules have following functionality for each table:

- each table has sortable columns
- each table can show/hide filters
- each table has pagination where you can decide the number of rows right there
- each table highlights the row the mouse is over
- each table has "in-place" editing
- each table has checkboxes for each row, so you can select all rows or individual ones, and then you have an option for "bulk actions" (like delete selected)

I've seen variations of the above in several modules, but each time programmed differently.

So the goal would be to find a way to encapsulate this functionality in a standard "table class" that could be used generically across all modules. The developer could send a ObjectHandel which will populate that table, and specify which fields will be visible as columns, and which actions will be visible for the Admin.

A lot of this is already happening in XOOPS 2.6.0, where we'll have plugins and helpers and extensions, that will be used consistently among modules, and the Core Team is doing an awesome work there.

But let's look for more ways for achieving our goals stated above, so using XOOPS, and developing for XOOPS is fun!

Top

Please support XOOPS & DONATE
Use 2.5.6 | Debugging | Requests | Bugs

Mamba

Moderator

Joined:
2004/4/23 13:58

From Ohio, USA

Group:
Webmaster
Registered Users
Designer Group

Posts: 6940

(Show More) (Show Less)

#13 Posted on: 1/11 5:36 Re: Module Standardization Team - looking for volunteers

Humm,
just an idea : let me try to explain (hope it xould be clear)
The overloaded templates (in french = la surcharge des thèmes) is a very great functionnality.

Lot of webmaster hacks their XOOPS in order to get a web site like they want.
But i hate hack my site cause maintenance and support is difficult, update is more dangerous...

In the modules, there are a lot of functions but sometimes, i would add some variables, instance, class or another functions in the php files.
So i needed to hack the php files and i hate that...

Let me show you an example :
in order to make this blocks, i should modify the default comments block with hack on \modules\system\blocks\system_blocks.php (overload template cant display like that cause some functions and variables not available)

Now, the idea :

Is it posible to use the overloaded template with php ?
For exemple, overloaded the functions in the file :
/themes/my-theme/modules/system/functions/system_blocks.php or if not like that, with this idea !

Perhaps, there would be security trouble, running trouble, but, my dear developpers, could you just think about the idea.
So, then, no hack, "just using overloaded functions"

Top

alain01

Just popping in

Joined:
2003/6/20 4:07

From FRANCE

Group:
Registered Users

Posts: 90

(Show More) (Show Less)

#14 Posted on: 1/11 7:59 Re: Module Standardization Team - looking for volunteers

Quote:

alain01 wrote:
Is it posible to use the overloaded template with php ?
For exemple, overloaded the functions in the file :
/themes/my-theme/modules/system/functions/system_blocks.php or if not like that, with this idea !

I don't think is good idea to overwrite php files. Even with templates there is problems. A module developer can change the php code of a block and your template will stop working. For php it may be even worst, as some of the functions provided by that module may be deleted or have other behaviour.
A better way would be to add a preload event on each function so they can be hooked by other modules/themes.

I think a better solution may be possible when we have controllers/response/router classes implemented on core. Before each module/action we will be able to trigger events. The theme could catch the event for system_blocks and change the response (changing the template or replacing even the action for example)

Top

Xoops User Utilities | Xoops Search Engine | vil3/trabisdementia

trabis

Core Developer

Joined:
2006/9/1 13:10

From Portugal

Group:
Registered Users
Webmaster

Posts: 2198

(Show More) (Show Less)

#15 Posted on: 1/11 8:42 Re: Module Standardization Team - looking for volunteers

Quote:

trabis wrote:
A better way would be to add a preload event on each function so they can be hooked by other modules/themes.
I think a better solution may be possible when we have controllers/response/router classes implemented on core. Before each module/action we will be able to trigger events. The theme could catch the event for system_blocks and change the response (changing the template or replacing even the action for example)

ok i understand.
But with this way, server request could be slow, no ?

May be official team could just add some class and functions on "old" modules ? In the original files...

Top

alain01

Just popping in

Joined:
2003/6/20 4:07

From FRANCE

Group:
Registered Users

Posts: 90

(Show More) (Show Less)

#16 Posted on: 2/26 22:56 Re: Module Standardization Team - looking for volunteers

I shared before the "XD-207_XOOPS_ModuleStructureGUI_Draft" Guide, to document some thoughts about standardizing our modules.

I've have updated it with few more screenshots of examples from various XOOPS modules that I think, are really cool and they should be in all our modules.

You can download the document XD-207_XOOPS_ModuleStructureGUI_Draft2.pdf here

Of course, we are not done yet, and we'll be adding more screenshots, as we discover new ones. But we need to do it as a community:

1) Let us know what you think about the ideas in this document - do you like them, can we make them better? Are there any XOOPS modules that have solved it better, and that we could reuse?

2) What other "Best in Class" elements for a XOOPS Modules have you seen in other modules that we could reuse? Which module?

3) What other features are missing that should be in every XOOPS module?

The first step will be to discuss and agree with the users and developers what is needed.

After that we'll need to figure out how to encapsulate such features (as a library, plugin, or via code generator) into pieces of code that could be easily reused among all modules - new ones, as well as those old ones that we are refactoring/rewriting for latest versions of XOOPS.

Please help us with that.

The bottom line is that there was and is a lot of cool innovations within XOOPS, but we were not very good in embracing those cool ideas, and reusing them in other modules. I hope, we can change this in the upcoming XOOPS 2.5.6, and especially in XOOPS 2.6.0.

Top

Please support XOOPS & DONATE
Use 2.5.6 | Debugging | Requests | Bugs

Mamba

Moderator

Joined:
2004/4/23 13:58

From Ohio, USA

Group:
Webmaster
Registered Users
Designer Group

Posts: 6940

(Show More) (Show Less)

#17 Posted on: 2/27 4:45 Re: Module Standardization Team - looking for volunteers

huum
I read that document.
I dont like that it is all focused on GUI and in specific the GUI in admin parts.

as i said many times codes are more important than GUI and main part is far more important than admin part.

admin part is just good for us but we should care about our users :D

I think all parts of this document is very obvious. we should use Core API and one of them is moduleadmin class.
In this tutorial you just document this one class of core.

all developers should use core API as much as possible to make life easier for themselves and for others.

Im very tightin using Xoops API so i stick to XOOPS API so that the userlog module will only work in admin part of modules used the moduleadmin class.

there is some little issues and typo in this document.

1- in page 13
Quote:

You can call the 16x16 icon by calling the appropriate path and the name of the icon:
<img src=". $pathIcons16 .'/edit.png'." alt='" . _EDIT . "' title='" . _EDIT. "' />

please dont promote it. it is hardcoded html in php files.
everybody must use xoModuleIcons16 smarty var.

2- typo in image page 14
mymodule/block/myblock.php

should be
mymodule/blocks/myblock.php

3- page 14
Quote:

Please also update the help.php file located in:

should be help.html

Im also completely against of this tutorial from page 15 to the end

the 2.9 Tables section is just promoting hardcoded html in php files.
there is no instruction how to do those nice things.
for example you promote TDMdownloads which has very bad hardcode html for creating those nice tables.

every developer should use templates in admin parts of the module like the user part.

eg:


$template_main = "userlog_admin_logs.html";

if ( !empty($template_main)  ) {

    $GLOBALS['xoopsTpl']->display("db:{$template_main}");

}

so we need a typical template html files for those nice tables/form things.
that is not very hard and we can find it everywhere in the net.
It makes life easier for everybody.

ok. i want to share with you one of the very nice works from trabis. it is the request class which is in xoops 2.6 but i hope all developers use in 2.5.5 too.

I used it in userlog.

instruction is very easy.
just copy publisher/class/request.php to YOUR_MODULE/class

open request.php file.
- replace all "PUBLISHER" with your desired word: eg the name of your module.(use match case)

that's it. now you are free from get/post methods and sanitizers.
just can use it like this everywhere in your module.


$startentry = UserlogRequest::getInt('startentry',0);

$limitentry = UserlogRequest::getInt('limitentry',$Userlog->getConfig("logs_perpage"));

$sortentry = UserlogRequest::getString('sortentry','log_id');

$orderentry = UserlogRequest::getString('orderentry','DESC');



$options = UserlogRequest::getArray("options");

the second one is default var as you can see yourself.

Top

irmtfan

Module Developer

Joined:
2003/12/7 14:14

From In the middle of nowhere

Group:
Registered Users
Community Coordinator (temporary)

Posts: 3304

(Show More) (Show Less)

#18 Posted on: 2/27 5:14 Re: Module Standardization Team - looking for volunteers

1) Thanks for all the typo reporting, I'll fix them in the next update

2) And thanks for the feedback.

Quote:

the 2.9 Tables section is just promoting hardcoded html in php files.
there is no instruction how to do those nice things.
for example you promote TDMdownloads which has very bad hardcode html for creating those nice tables.

I promote "ideas", and not a particular implementation of those ideas.

This document is only the first step to gather agreement about what are the "Best Practices" in "functionality" and cool ideas. At this moment we don't look yet into "how" it was done, and if it is a better way. We can decide about the "hows" later, incl. what will be done with PHP and what with JavaScript (e.g. via jQuery).

And the best way will be to do it as much and as close to XOOPS API as possible, with clear separation of PHP and HTML code, and clear separation of business logic and presentation logic.

I've converted by now many, many modules to XOOPS 2.5 Admin GUI, and I am amazed how many different ways people used to solve the same problems. Clearly, it's a maintenance nightmare, and we need to fix it soon!

The positive side: I am learning a lot!

Quote:

so we need a typical template html files for those nice tables/form things.
that is not very hard and we can find it everywhere in the net.
It makes life easier for everybody.

Absolutely! That's what I'm looking for. We need to promote "Reuse" in everything that we do! And we need to find the best solutions on the Web and implement them in XOOPS. We need to stop with the "Not-invented here" syndrome! The beauty of GPL is that we can take any GPL code from any where in the world, and use it in XOOPS!

So if you see something really cool that could replace a lot outdated code, please let us know.

Top

Please support XOOPS & DONATE
Use 2.5.6 | Debugging | Requests | Bugs

Mamba

Moderator

Joined:
2004/4/23 13:58

From Ohio, USA

Group:
Webmaster
Registered Users
Designer Group

Posts: 6940

(Show More) (Show Less)

#19 Posted on: 2/27 21:01 Re: Module Standardization Team - looking for volunteers

Thank you mamba now i understand you better.

IMO you should separate wishes from instructions in that tutorial.

why i said you promote hardocde?
when you show for example mastop_go2 way for having a nice filter show hide a developer will go directly and download that module and look codes and follow them.
Also i should correct myself. just section 2.9 is hardcode promoting.

I put some times and add pagination, sort, order to userlog to show you how is the right way for doing them with Xoopsform class and template.


<a class="ui-corner-all tooltip" title="<{$title}>" href="logs.php?limitentry=<{$limitentry}>&sortentry=<{$header}><{if $query_page}>&<{$query_page}><{/if}><{if $sortentry eq $header}>&orderentry=<{if $orderentry eq 'DESC'}>ASC<{else}>DESC<{/if}><{/if}> " alt="<{$title}>"><{if $sortentry eq $header}><img src="<{if $orderentry eq 'DESC'}><{xoModuleIcons16 DESC.png}><{else}><{xoModuleIcons16 ASC.png}><{/if}>"/><{/if}><{$title}></a>

you can see that it is understandable. if $sortentry eq $header means if sort is equal to header show the order arrow.

Note: i find a limitation in xoModuleIcons16 smarty. it cannot accept other smarties inside it. so i cannot use something like this:

<{xoModuleIcons16 <{$orderentry}>.png}>

section 3. BULK ACTIONS ON TABLES is done in xoops core xoops.js and you could add the instruction how to do it.

in newbb:


<form name="form_posts_admin" action="action.post.php" method="POST" onsubmit="javascript: if(window.document.form_posts_admin.op.value < 1){return false;}">

                <{$smarty.const._ALL}>: <input type="checkbox" name="post_check" id="post_check" value="1" onclick="xoopsCheckAll('form_posts_admin', 'post_check');" />

so xoopsCheckAll(_NAMEOF_FORM, 'bla bla') will do it nicely.

4.4 Dashboard

it is done in moduleadmin class.


function addInfoBoxLine($label, $text, $value = '', $color = 'inherit', $type = 'default')

so for example for red when value = 0 and green when the value is greater than 0 i add this to userlog.


// use sprintf in moduleadmin: sprintf($text, "<span style='color : " . $color . "; font-weight : bold;'>" . $value . "</span>")

            $indexAdmin->addInfoBoxLine(_AM_USERLOG_STATS_ABSTRACT,

                    sprintf(_AM_USERLOG_STATS_TYPE_PERIOD, "%s1", $types[$type], constant("_AM_USERLOG_" . strtoupper($periods[$period]))),

                    $arr2["value"],

                    $arr2["value"] ? 'GREEN' : 'RED');

so please separate some wishes from some parts that already is done in core and have clear instructions.

also Mage can add those nice filters to moduleadmin class or xoops.js and let us use it!!!

Top

irmtfan

Module Developer

Joined:
2003/12/7 14:14

From In the middle of nowhere

Group:
Registered Users
Community Coordinator (temporary)

Posts: 3304

(Show More) (Show Less)

#20 Posted on: 2/28 1:45 Re: Module Standardization Team - looking for volunteers

Quote:

so please separate some wishes from some parts that already is done in core and have clear instructions.

Well, these are not really wishes, because they are working solutions implemented already by at least one person, if not more, even if differently.

We just need to decide which way we will choose, or if we need to recode it, so it is consistent with the overall coding styles.

Please remember: this is a "Draft", i.e. it is the same as an "Alpha" version - please don't use it in a production site, but take a look into it, think about it, you can even try to implement it in the right way, and then make improvement suggestions.

For me creating these guidelines is to start a discussion about how should we standardize our modules. It's like drawing a house and discuss it before we actually build it.

The focus is on:
- reuse of code between modules, resulting in consistency of features and GUI elements across all modules
- simplifying module development
- improving user experience with XOOPS modules (both front-end, and back-end)

So please submit ideas and code that could be helpful to achieve that.

Top

Please support XOOPS & DONATE
Use 2.5.6 | Debugging | Requests | Bugs

Mamba

Moderator

Joined:
2004/4/23 13:58

From Ohio, USA

Group:
Webmaster
Registered Users
Designer Group

Posts: 6940

(Show More) (Show Less)

Board index » Xoops Development » XOOPS Module Development » Blue Move » Module Standardization Team - looking for volunteers

Search

Donat-O-Meter

Learn XOOPS Core

Local Support

Advertisement

Cumulus Tag Cloud

New Users

Forum Index

About Us

Learn

Use

Develop

Contribute

Connect