Subject:*
<
Name/Email:*
<
Message Icon:*
<
Select*
<
Message:*
<



Click the Preview to see the content in action.
Options:*
<
Confirmation Code*
<
2 - 0 = ?  
Input the result from the expression
Maximum attempts you can try: 10
*
<
     

Re: Preparing Text to go in and out of a Xoops DB
by mvandam on 2004/4/17 20:10:14

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
Re: Preparing Text to go in and out of a Xoops DB
by jackt on 2004/4/16 18:59:53

Quote:
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.


That's what I had figured. Most classes done this way in the core seem to have a constructor and 1 or 2 methods, and then a huge handler for all the DB stuff. It didn't look necessary to separate out the 2 when the actualy object class has so few methods generally, but I understand the reasoning. Is this part of the "recommended" method?

Quote:
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.


You know I actually would if I was confident what I've been doing was correct. 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.
Re: Preparing Text to go in and out of a Xoops DB
by mvandam on 2004/4/16 17:47:03

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.
Re: Preparing Text to go in and out of a Xoops DB
by jackt on 2004/4/16 6:55:15

I've noticed that extending the XoopsObject class conveniently formats text for you assuming you initVar to set the data types, and then getVar and setVar will "sanitize" the text for database entry or display. I've also seen kernel and some OO based core modules also include a corresponding Handler class to handle database manipulation. Howvever, there exists very very few modules that actually take this route. The few modules that are OO either create a renderer class for display (I don't even quite understand why you'd throw in an extra layer between the calling page and smarty, why would you even need another class to render output for you.) or throw in database manipulation methods into the that very class.

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.

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.
Re: Preparing Text to go in and out of a Xoops DB
by mvandam on 2004/3/29 17:05:34

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'.

Who's Online

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


Members: 0


Guests: 176


more...

Donat-O-Meter

Stats
Goal: $15.00
Due Date: Jul 31
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $15.00
Make donations with PayPal!

Latest GitHub Commits