XOOPS 
Forum
Forum Index General Forums Community Support Modules Support Themes Support Development International Support Module Hack Reviews Theme Designer Talk


(1) 2 3 4 ... 21 »


1
mvandam
Re: How to use Xoops database?

  • 2004/4/20 3:25

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

It's not only the datatypes that differ.

Even if you only use MySQL, there have been changes in version upgrades.

For example, UNION and subqueries.

I don't know how a generic interface would handle that.

Exactly.

SQL (ANSI 92 or something like that) is supposed to be a 'standard' that all database engines are supposed to support. I must admit I do not know exactly what this standard defines, nor what the databases support exactly... But what I've heard is that practically NONE of the popular databases implement the full standard. Instead they have diverged to try to force 'vendor lock-in' among other things.

The divergence consists of:

- different levels of support (not all databases support subqueries or 'union' or triggers or stored procedures)
- different names for built in functions/operators (e.g. 'CONCAT' vs '+'; also the various databases apparently have different syntax for 'JOIN' operations)
- different datatypes

By restricting yourself to a small set of datatypes and simple queries then you can go a fair ways. This is how ADODB works I believe. There are a few wrapper functions to take care of major differences and if you use those religiously, you shouldn't have many problems. Of course, by restricting yourself, you often throw away a HUGE opportunity to do any database optimization. (Not sure how relevant this is in typical web apps though - maybe not a big deal.)

I may be blowing this issue out of proportion, not having first hand knowledge of these problems. However, I am on mailing lists for several open source projects, and it frequently occurs that even though some of these projects do use ADODB, people will report problems with MSSQL or ORACLE due to subtle syntax differences even though their abstraction library is supposed to provide 'database independence'.
Topic | Forum


2
mvandam
Re: How to use Xoops database?

  • 2004/4/19 9:36

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

About the database and XOOPS abstraction from it.
Perhaps it's now we should have the discussion about how it should be implemented?


There are several existing database abstraction libraries already existing... ADOdb, MDB, MDB2, pear DB, several others.

The trouble is, you can make it so all databases have the same 'function calls', but it is still very difficult to write a truly portable *query*. (Very simple queries can be written fairly portably, but a complex query is likely to run into db-specific things.) The problem is how to deal with this.

ADOdb is very popular and a lot of people have had success with this. Unfortunately it is somewhat 'bloated' and the loading time of the ADOdb class can be a performance hit. MDB2 to me looks very promising but it is young and doesn't have nearly the support. With ADOdb, the typical approach I believe is to write the queries in as portable a manner as possible, then wait for one of the users to report a problem, then try to fix it or have separate cases depending on the database system the user is running. Not ideal, but works for the majority of cases.

I'm not sure how the other devs plan to proceed with Xoops. $xoopsDb is kind of an abstraction library itself, but not complete.
Topic | Forum


3
mvandam
Re: Preparing Text to go in and out of a Xoops DB

  • 2004/4/17 20:10

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

I might just take a core module like the polls and improve on it using the "recommended" way. I've been looking at the various dev.xoops.org modules, maybe 2 or 3 of them are using OOP, and out of those I don't believe any of them are written in the "recommended" way (ie extending XoopsObject AND using initVar, getVar, etc). Not that they're bad, they just don't follow the core classes/modules. I don't know how important that is to the XOOPS core/module devs.


If you plan to make any significant modifications to an existing module, I would suggest signing up on dev.xoops.org if you have not already done so, so that your work may become a permanent part of the XOOPS distribution, if you wish.

We recognize that most modules do not conform to the core standards. Historically the reasons are due to porting from other major scripts and also because most were written before the core was overhauled.

There has been some discussion on updating one or some of these modules into an 'official example' to help guide others in their creation of new modules or modification of existing ones. I'm sure the module devs would greatly appreciate any contributions to this effort
Topic | Forum


4
mvandam
Re: Preparing Text to go in and out of a Xoops DB

  • 2004/4/16 17:47

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

I'm wondering what the benefit is by separating "data access mechanisms" methods into a handler class? No one seems to be doing it, but the core classes are practically all done this way.

This is basically the same argument as why you separate your logic from your design - i.e. you use templates so all design-related stuff is in a *single* place.

You separate all DB things so that if there are ever changes (e.g. supporting other databases etc) then you can make all the changes in one place.

Quote:

In addition, it'd be very useful to include the initVar, getVar, setVar, etc functions in the module developement wiki. Alot of people don't use what's supplied in the core, and it would help them tremendously to know these tools are provided to you.

Feel free to start some pages if you have the time . There has been some talk on dev.xoops.org about providing at least one module written in the 'recommended' way, i.e. using all the core features etc. Not sure what the status is on that right now.
Topic | Forum


5
mvandam
Re: Preparing Text to go in and out of a Xoops DB

  • 2004/3/29 17:05

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

Should one always use the text sanitizer when reading or writing from a table? If not, what are the guidelines on when one should or should not do so?

Depends what you mean by 'reading' or 'writing' from a table. If you are writing a *query*, you should always use $xoopsDB->quoteString($blah) on ALL variables which are 'untrusted' or unvalidated. This includes integers etc, unless you explicitly check to make sure they are integers and contain no strange characters.

The text sanitizer is used for pieces of text. If you are extending XoopsObject, then initVar, setVar, getVar all call text sanitizer automagically. If you are not extending XoopsObject, then you may need to invoke the text sanitizer. Preparing for the database is only a tiny part of what text sanitizer can do... it also 'cleans' any strings so that when you display them as HTML you deactivate any potential 'attacks'.
Topic | Forum


6
mvandam
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?

  • 2004/3/25 21:03

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

That's true, if you want the modules to be pretty much identical. My idea with creating a clone is that the module I am writing has a BUNCH of configuration options, including what fields to display, what fields to make searchable, what the module-specific categories of content are, etc. Not to mention templates, if you wanted them to be different for each instance of the module.

This is a very good point. Whatever clonability system is used later in XOOPS 2 (or in XOOPS 3), it should basically allow the flexibility as if it was a completely separate module (and maybe it will be), rather than just be an enhanced category system. This means independent config options, independent templates, independent search?, etc.

One common use may be to display different content to different groups of users and each group of users should not be aware at all of the existence of the other clone of the module. What are other uses envisioned for cloned modules? (a) Different 'look' for different categories of news etc; (b) Maybe supporting different languages... one news clone in english; one in another language; (c) Giving modules different names... i.e. have a 'News' section using the news module and have an 'Announcements' section using a clone of the news module. I'm sure there are many other reasons? Maybe identifying some of the common reasons for wanting cloneable modules will help to design such a system?
Topic | Forum


7
mvandam
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?

  • 2004/3/23 7:36

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Quote:

(Even if classes are defined globally, a page within one module should not be loading class definitions for another module, right? (blocks aside, of course, which screws eveything up.))

And this is exactly the problem. Classes and functions *are* defined globally (this is how PHP works). The problem is multiple modules get (partially) loaded to display blocks, menus, search results, etc... You really have to have unique function and class names to avoid conflicts. The alternative is writing so all clones read the *exact* same files (not just the same contents in the same relative location, but the SAME file; otherwise 'include_once' won't work), all from a SINGLE shared directory. Not sure how you would do this in a cloneable way though.

Quote:

I like this solution because the less a user has to tweak a module to make it work as a clone, the better -- this involves no code change, just a file name change, which is something a non-coder can handle.

I agree, and this is probably how I would code a new module. However, keep in mind that the code is a little more complex (e.g. $varName, $moduleDirname all over the place) and a little slower by doing things this way.
Topic | Forum


8
mvandam
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?

  • 2004/3/23 2:35

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Looking good Daigoro! You can use similar techniques also for accessing the module's database tables.

e.g. $sql = "SELECT title,body FROM " . $xoopsDB->prefix($ModuleDirname . "_articles");

where I've used '$ModuleDirname' instead of '$ModuleName' as I think it is more accurate.

However, several problems still remain... creating function and class names. Also, template files are currently named with the module-name in the filename. e.g. modules/news/templates/news_item.html. This is something you definitely could *not* generate dynamically, so cloning a module would require at minimum renaming the template files. (Possibly it will also require a search/replace in function names and class names.)

The more you can write a module dirname-independent, the easier to clone a module. We just have to watch that this doesn't have too much performance overhead. Very interesting work so far!
Topic | Forum


9
mvandam
Re: XOOPS Dev Team: Would it be hard to propagate module name in all reference to the module?

  • 2004/3/22 21:21

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


This approach with __FILE__ seems good. The trouble with SCRIPT_FILENAME and a zillion other variations is that they are not very consistent between different platforms nor versions of PHP.

To other who may use this, note the use of '$pathparts[1]' and '$pathparts[3]'.

In module/abc/xoops_version.php, realpath(__FILE__) gives the full path to the file, explode splits into an array where each subdirectory is an array element, 'reverse' reverse it, so you have array('xoops_version.php', 'abc', 'module', etc...). Then $pathparts[1] takes 'abc', which is the desired module dirname.

In modules/abc/language/english/main.php, $pathparts is array('main.php', 'english', 'language', 'abc', 'modules', etc...), so $pathparts[3] now gives you the dirname.

So you just need to keep track of where the current file is within the module directory structure and adjust the $pathparts index accordingly.

An alternative approach, maybe more intuitive? maybe not?

modules/abc/xoops_version.php:

$pathparts = array_reverse(explode('/',dirname(__FILE__));
// use $pathparts[0];

moduels/abc/language/english/main.php:

$pathparts = array_reverse(explode('/',realpath(dirname(__FILE__) . '/../..')));
// still use $pathparts[0];

Or maybe use array_shift or array_pop etc... to just take the first/last element and maybe eliminate the need for array_reverse...
Topic | Forum


10
mvandam
Re: PHP globals question. _solved

  • 2004/3/22 21:03

  • mvandam

  • Quite a regular

  • Posts: 253

  • Since: 2003/2/7 2


Just a couple of points:

Quote:

It appears that the problem is that the code for blocks is actually included by XOOPS WITHIN A FUNCTION.

Note that I have not found this in the XOOPS code yet, but it sure seems to behave that way.

You *have* found it. Your function "function b_bookstore_show()" is what generating the template data for the block. (This function is called automatically by the XOOPS core.)

Quote:

So, I have two questions.
1) If someone knows the XOOPS code better than I can tell me whather my conclusions are correct. (Or just point me to the right part of the code...)

To access global variables within PHP, you must always use 'global $var;' before using it. If you are within a function, PHP doesn't magically know you are talking about a global variable. This is a little weird, but this is how PHP works.

e.g.

global $somevar;
$somevar = 'xyz';
function dosomething() {
global $somevar;
// do something with $somevar
}

Quote:

2) Is there a way for a nested function to access the variables declared in the enclosing function? (I'm just curious, this workaround means I don't need to know).

Well, you should probably pass the variable *into* the enclosed function . Global variables are usually a bad idea.
Topic | Forum



TopTop
(1) 2 3 4 ... 21 »



[Advanced Search]

Login

Register now!  |  Lost Password?

Search

Advanced Search

Recent Posts

Who's Online

189 user(s) are online (114 user(s) are browsing Support Forums)

Members: 0

Guests: 189

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