51
frankblack
Re: smarty inside js file?
  • 2009/12/23 20:03

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Did you grab an older version of debaser 3.05 before 2009-12-17? Guess so, there was - shame on me - a bug in the sql. Right after the last player is inserted, there is a comma instead of a semicolon.



52
frankblack
Re: smarty inside js file?
  • 2009/12/23 15:11

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Hi kaotik, old jquery genius. Two observations I made.

Best place for jquery.js should be really the upmost top of the theme.html, right under the title if possible, because jquery scripts behave badly, when they are placed before jquery.js. Problem is that addScript and $xoops_module_header get placed at different locations in the structure. So if the site uses jquery a lot, I would not mind to embed it manually in the theme.html instead of assigning it with xoops_module_header or addScript.

Second observation: when Javascript and smarty are mixed in template sometimes (in very small cases) smarty isn't properly translated. So it helps, when you put smarty between backticks. Maybe this information is outdated, but I ran into this problem a while ago.



53
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 17:11

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Yes, Protector preload. Including 4 files and making one query.

I repacked the firephp-debugger (addons firebug and firephp have to be installed with Firefox) with Smarty debug enabled. I hope I packed it well - get it HERE.

For those who want to log variables on its own, just include this in your file:
require_once XOOPS_ROOT_PATH.'/class/logger/firephp/FirePHPCore/FirePHP.class.php';
$fb FirePHP::getInstance(true);
$fb->registerErrorHandler(false);
$fb->log($whatsmyvalue);


If you want some deep insight to your XOOPS just copy this to the file where you want to get some information about:
function getDefinedVars($varList$excludeList)
  {
      
$temp1 array_values(array_diff(array_keys($varList), $excludeList));
      
$temp2 = array();
      while (list(
$key$value) = each($temp1)) {
          global $
$value;
          
$temp2[$value] = $$value;
      }
      return 
$temp2;
  }

require_once 
XOOPS_ROOT_PATH.'/class/logger/firephp/FirePHPCore/FirePHP.class.php';
$fireme FirePHP::getInstance(true);
 
$excludeList = array('GLOBALS''excludeList''output''xoopsTpl');
 
$varList get_defined_vars();
 
$fireme->log(getDefinedVars($varList$excludeList));


This should be too much of info!



54
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/22 10:15

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


A quote from your quote.

Network Performance Tips:

Quote:
1. Minimize traffic by fetching only what you need.
1. Paging/chunked data retrieval to limit
2. Don't use SELECT *
3. Be wary of lots of small quick queries if a longer query can be more efficient
2. Use multi_query if appropriate to reduce round-trips
3. Use stored procedures to avoid bandwidth wastage


Quote:
Sounds interesting. Where can I download state-of-the-art module?


Well, in fact you gave me the advice to look at these series of modules if I remember correctly.

Quote:
And XOOPS Boot is before module loading, how are we getting different values?


I would no worry about that. Test scenario is running locally on XAMPP with other programmes open and working. So this might be a reason?

Maybe if we look at the files included, there could be optimization? I have to look it up again to say nothing false: there were protector queries and files included although not installed. I'll take a closer look...



55
frankblack
Re: XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 17:58

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Having a closer look at the queries tells astounding things: queries for permissions are scattered all over the place. Queries for protector although not installed. Good module: query for smiles which is never used.

So I "demand" what I thought earlier: permissions are in a bad shape. I am still looking for a solution to get ALL permissions in ONE shot. One of the reasons, why I was "outsourcing" permissions to the preferences.

Next one is the prevention of SELECT * in queries. Maybe it is just a rumour I heard, that the performance is better with SELECT xy, yz in queries. Where applicable of course.



56
frankblack
XOOPS coding standards the wrong way? OR the benefits of old fashioned coding
  • 2009/12/21 17:18

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Sounds provoking and yes it should be! First of all: with this thread I don't want belittle any other coder. This just should a matter to be discussed. So if I annoy anyone with this: SORRY!

My intention for writing this this afternoon was a good one. I just wanted to lift my module on a higher/better level of coding and started roaming around for some state-of-the-art modules. Installed it, looked at the code and was - first of all impressed. So this is top-notch coding I thought and was curious how the modules where behaving in matters of speed performance and consumption of queries.

Testing preferences: all notifications turned off, refreshing templates off, banner off, turned on all permissions. Good module = state-of-the-art module. Bad module = debaser.

My first test scenario: Two empty categories with no files.
Good module:
26 queries
142 included files
XOOPS 1.769 seconds
XOOPS Boot 0.412 seconds
Module init 0.203 seconds
XOOPS output init 0.576 seconds
Module display 0.258 seconds
Page rendering 0.306 seconds
Memory usage: 6675088 bytes

Bad module:
20 queries
93 included files
XOOPS 1.269 seconds
XOOPS Boot 0.299 seconds
Module init 0.049 seconds
XOOPS output init 0.596 seconds
Module display 0.055 seconds
Page rendering 0.256 seconds
Memory usage: 5112800 bytes

Second test scenario: just adding one category:
Good module:
28 queries

Bad module:
21 queries

This means for every added category two queries for the good module?

Third test scenario: submitting a file
Good module:
20 queries
148 files included
XOOPS 1.203 seconds
XOOPS Boot 0.179 seconds
Module init 0.236 seconds
XOOPS output init 0.351 seconds
Module display 0.299 seconds
Page rendering 0.124 seconds

Bad module:
16 queries
136 files included
XOOPS 1.066 seconds
XOOPS Boot 0.251 seconds
Module init 0.239 seconds
XOOPS output init 0.293 seconds
Module display 0.133 seconds
Page rendering 0.135 seconds

For the being inside the categories the bad module was a bit better performing and for the detailed page was better performing, but this was only due to a visual captcha for the bad module.

Test scenario end!

So why should anyone comply to XOOPS module coding standards, when the "old" way is performing better? Security? Can't be. My forms are locked up with token or captchas as well. Compatibility? No, I am using no deprecated functions.

I still can minimize the code lines and increase the speed for my module. Does this also apply for the state-of-the-art modules?

Ony serious answers expected - no flames please. I am just desperately looking for reasons to "move to Blue".

edit: typo in the title. question mark was missing



57
frankblack
Re: debaser 3.05 Abandoned released!
  • 2009/12/18 7:27

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


I can assure, that EVERY ajax based function SHOULD work properly. I installed tons of browser (except for Linux) to make some tests.

Perhaps one thing: where is your jquery.js inside your theme.html? I experienced, that the best place is on top of everything, just right after the metas or the title.






58
frankblack
Re: debaser 3.05 Abandoned released!
  • 2009/12/17 13:13

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


Whenever a file is deleted and a new one is uploaded on dev.xoops.org, the path is changed:

Download new

Tell-a-friend works for me on the following platforms
XP: Firefox 3.5.6, IE6, IE7, IE8, Opera 10.01, Chrome 3.xx, Safari 4.04
Mac OSX Tiger: Firefox 3.5.6, Opera 10.01, too lazy for Safari

Does the popup do not show up at all? Or are you trying this is as a guest? For guests it is not allowed, but this is quite easy to correct.



59
frankblack
Re: debaser 3.05 Abandoned released!
  • 2009/12/17 7:40

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


@xsell: sorry you are absolutely right for the sql. Fixed on d.x.o. Seems to be that I have to make a fix release.



60
frankblack
debaser 3.05 Abandoned released!
  • 2009/12/16 17:59

  • frankblack

  • Just can't stay away

  • Posts: 830

  • Since: 2005/6/13


I am proud to announce the release of debaser 3.05 Abandoned (Final). Just a few things have changed compared to the beta. For upgrading from Half-Finished to Abandoned I made a small upgrade script.

It has been a long way from debaser 0.92 to 3.05. Although the module is bloated and is programmed in XOOPS 1.x-style, as a nice portuguese guy told me (eheh), it works! Anyway the beauty of the code lies in the eye of the viewer.

An updated documentation is soon going to be released.

So here is the final feature list (not everything is a feature, but a bug):

- Works only for XOOPS 2.41 and higher
- Uploading, editing, deleting restricted only to registered users
- File manager removed, because managing files should be duty of the core
- Multilingual in conjunction with xlanguage with NO extra markup for different languages
- Playlist for various formats (if the player is capable to play playlists)
- I am quite sure about the fact, that nearly every player could be embedded, even external players
- Advanced setup of players
- Advanced setup of mimetypes
- Batch processing of files uploaded with FTP
- Re-encoding of MP3 files with Lame (not included)
- Broken files can be reported
- Radio stations can be added
- TV stations can be added
- Nearly all kind of files can be added
- debaser makes use of getid3 to get file information when uploaded
- Per-user defined directories (with quota)
- Playing lofi MP3 can be triggered from different options
- Flash uploader integrated with display of progress and time
- Batch uploading through Flash uploader
- Permissions for categories, uploads, playlists etc.
- Anti-hotlink feature
- Code embedding of player code is possible
- Flash token (kind of) for Flash uploader integrated
- Tell-a-friend with visual captcha
- Search bar with suggestions integrated
- Playlists can be public or private
- Display of files can be embedded or popup
- Files from the same user can be displayed (or limited to a certain amount or turned off)
- Links can be submitted for plain URLs to files or for videos from YouTube et.al.
- Equalizer added for audio files, when played with a Flash based player
- Lots of blocks
- Playlist can be sorted via dragndrop
- Made the xoopsforms look a bit nicer (hope so)
- Page to get detailed information on a file in administration
- Donation button added (shameless plug), pointing to joe_l@gmx.de.

Upgrade from 3 Beta to 3 Final
Download 3.05 Abandoned (Final)
Bug tracker
Docs for pre-Alpha

So here my final words (read my signature): Thx to all the nice people I met along my way developing this bloated bastard, especially xsell for pushing me and having nice feature request, trabis and alfred for always being helpful, mamba for making me xotm, longtailvideo.com for their written permission to add JWPlayer to the package and all the others I forgot to mention for their code which I shamelessly stole.

Good luck and have fun

ATB frankblack




TopTop
« 1 ... 3 4 5 (6) 7 8 9 ... 53 »



Login

Who's Online

216 user(s) are online (140 user(s) are browsing Support Forums)


Members: 0


Guests: 216


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits