What about using core XOOPS functions like the security tokens and field validation are they easier to implement using smarty templates or XoopsForms?

Hi McNaz,

Quote:

Even today many PHP Newbie Tutorials use that approach and xoops1 still used it. Even in xoops2...have a look at the implementation of the comment system and tell me if this is how it should be.

I think we both want the same result. Well structured code. What I criticised in your post is that you see it too dogmatic by not using the XoopsForms because it would injure the MVC principle.
First, the basic MVC Approach is originally aimed at fat clients. In Web application, you can't adopt that at 100%, you can just do "something that looks like MVC".
Second, it isn't even said that XoopsForm injures the MVC principle. Prove it to me. ;)

In ASP.NET, you have something which is calles SqlDataSource. SQL Statements directly in the HTML Code! Ugly, you would think. But: The idea is from .NET 2.0 (2005 and not 1995) and it makes code development much faster for smaller applications. Although it hurts almost every principle of structured code. No matter, it works fine.

Quote:

Ever had a look at a compiled result of a <{section}> Tag? Ever went into a function call of a runtime plugin with a debugger? Ever stepped though the instanciation process of a smarty template? The IS much overhead. Even with the compilation result.

greetings
birdseed

Another factor:

It's desirable to use consistent coding methods throughout XOOPS. This facilitates readability, maintenance and reusability.

There are inconsistencies within XOOPS, but that's not by design. It's a result of it being an open-source project with multiple authors, without any real process to ensure consistency.

Quote:

Those features are easier to implement if you use the XoopsForm classes. It's possible, but a bit more difficult, if you use XoopsForm classes combined with templates. It's still possible if you don't use the XoopsForm classes, but then it gets more difficult.

Regarding the field validation, I've had to override much of that anyway, since the checking is too generic; it only checks whether fields are present or missing. For most forms, I don't enable the validation; I just do the checking on the PHP side, which is needed anyway in case the client has Javascript disabled. For upload forms, I want Javascript validation, but then I also add checks for things such as correct file extensions.

Quote:

Hello,

As the lead developer on Formulize, I'd have to say it's very good.

Formulize is one way around some of the limitations of manually creating forms with the XoopsForm class that have been discussed here.

Like Liase and Formulaire, Formulize provides a graphical user interface that you can use to create forms. So you specify the elements that you want in the form by picking them from a list, and configuring their options (size of texboxes, options in a dropdown menu, etc) all through a form in your browser.

Formulize also adds a lot of control over how people interact with the form. So you can specify that a form should allow only one entry per user (ie: a profile form) or mulitple entries per user (ie: an activity log). There is also a detailed permission system that lets you control whether people can see entries others have made within their group, or across the whole site. And also whether they can edit or delete their own or other people's entries, among other things.

The forms are displayed by default using the standard XoopsForm class, so the appearance is limited.

However, there is a full API for Formulize that you can use to control how you want the form to appear on an element by element basis. You would create the form in the normal way using the interface described above, specifying all the elements that you want to have. And then you would write some custom PHP on the page where the form should appear. It could look something like this (to use a simple, old style table layout for multiple columns):



As for reviewing the information once users have submitted it, Formulize includes a powerful searching, sorting and calculation interface that lets you analyze the data however you choose, and save custom views of the information, publish views to other users, and export the data to .csv format.

It is very suitable for any standard data input-output situation, and with the API can be used to create custom applications, which in some cases may be easier or more appropriate than creating a new module from scratch.

The current focus of development is on providing access in the administration screens to the more advanced features currently available only through the API.

If you would like to discuss further, please visit the Formulize area on dev.xoops.org, accessible through this link:

http://www.freeformsolutions.ca/formulize

Thanks for reading,

--Julian

Quote:

Could you explain this further? I'm not sure this is correct. I think it all depends on how good the programmer is at using the class effectively.

The XoopsForm class just gives you a way of outputting HTML form elements in your page without having to manually create all the HTML necessary for the element.

This is especially useful when dealing with large option lists since adding an array of options to the element object is a lot nicer than the alternative. It's generally a lot cleaner to read too, at least if you're a programmer.

I agree that rendering the entire form as a unit through the XoopsForm class does limit your presentation options, however you are aware that each element can be rendered individually using its own render method? ie, something like this (I have not debugged this code, could be syntax errors in it, etc, but you get the idea):



I think that pretty effectively separates presentation from logic.

Yes, there are some shortcomings of the XoopsForm class, particularly validation of user input, and enforcing required fields. But that can be dealt with by custom javascript that you could write. In Formulize we are planning on adding in more such features through the module rather than changing the class.

--Julian

That does seem a very good way to do it.

There appears to be 3 main approaches to developing interfaces:
1. Use Smarty Templates
- Total control over layout, slower, less secure

2. Use XoopsForm
- Very secure, More difficult to Maintain, Less control over layout

3. Use Both
- Very secure & Good control over layout

Using option 3 as Julian has suggested seems like the best aproach for someone about to start on a new project.

Can anyone give any pointers regarding Security? What should one be trying to keep secure? How can XOOPS Core help?

Are security tokens implemented automatically using the XOOPS hidden elements?

Thanks again guys, still just getting to grips with it all.

And, 4. Use Liase or Formulaire or Formulize depending on the nature of the application you're trying to build.

What is it exactly that you're trying to create?

--Julian

Hi

Some ways to write secure code:

- turn off register_globals
- assign $_POST and $_GET Variables at the beginning of the script to the variables with whom you wanna work
- Let your objects inherit from XoopsObject (uh I'm afraid they changed it do xo something in 2.0.14.)
- use $ts->addSlashes($postVariable) before inserting the content of textboxes to sql strings (sql injection)
- praise that there is no D.O.S Attack (denial-of-service). The main weak point in XOOPS is the search function (oops, I should keep that secretly )
- use insert/update/delete SQL statements only in POST Request, this is pseudo-safe, but it works for non-professional users

greetings
MK