The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The form definition is used by the Form class to control validation and population of fields. The Form class alters the form definition as it encounters invalid fields, or retrieves values to populate fields with. The form definition the becomes the output document, to be transformed using XSLT.

Populators are an attempt to make adding values to select, radio elements quickly.

If you think I've overlooked something, or if you think the design is wrong, or anything else, let me know.

Looks really cool, don't see any design flaws. Might like to look at PEAR's Quickform to get some inspiration.

Thanks! I'll look at Quickform when I have the time.

Originally Posted by Widow Maker

Nice very clean, though I use XML as well, I use it for validation only since my templates are all xHTML, and not XML - I'm assuming you use XML for your templates as well ?

Yeah, it's all XML

The form XML I posted serves two purposes, it defines the rules for validation etc. and it's also the document that is sent to the XSLT processor.

Originally Posted by Widow Maker

Not so clean though, is my current solution. Your script looks cool - like how you've used XPATH - again

I'm addicted to XPath.

Originally Posted by Widow Maker

Kind of embarrased now, looking at your post compared to mine

You shouldn't be, your solution seems alright to me. Ultimately we're validating the values the same way using a simple RegEx, it's just that I'm wrapping up the most common RegEx's in object's that can be used in a number of forms, or in other parts of the system. And I have the advantage of PHP5's great XPath support.

Off Topic:

PHP Code:

ErrorReport::Invoke( 200 );

I'm currently trying to figure out the best way to handle errors etc.

Was wondering if you could explain what your ErrorReport object does or how you handle errors in general?

Thought about this myself, though since all forms, to me anyways, have differing elements, I thought I'd be better off with the RegExp in the XML file, which by the way, serves as a pages configuration as well

As to

PHP Code:

ErrorReport::Invoke( [int] );

it isn't finished yet, either

I've a few things working together, but finding the time to glue things together is a problem

At the moment, the Integer passed over, will determine a default error to be outputted, though nothing else, such as what caused an error yes ?

A solution to this I was thinking is that, in every class I have that would require error checking, I have a basic Fetch() which would return a more descriptive message - or other object - to what caused the error.

This way, the ErrorReport class wouldn't really know, nor care about where the message - or object - came from.

It'd just use it yes ? Here is what I have at the moment though,. Thanks for your comments SleepEasy, and would be interested in seeing what you think of my ideas for ErrorReport.

Your error system looks good, but I would suggest you make ErrorReport "dumber" and only have one default error message to use when IsError() returns nothing or fails, instead of one for each error code. Because even with those few you enforce ErrorReport to know about what causes errors.

Something like "Sorry, we encountered an error fulfilling your request, please try again in x minutes." or something.

Edit:

I just remembered you said the default errors will eventually be taken from an XML file - if this is updated when you add new error producing "modules" then what I said above won't apply as much. Sorry about that.

I just think ErrorReport shouldn't know about what the error is or could be, just how bad the error is.

You could then use the error code to represent the severity of the error which would be used by ErrorReport to determine whether the error should be logged, an email sent to the admin, or both.

I have only ever written a very simple log writer class so I'm not an expert on it the subject, but I can't imagine it being to difficult, although that obviously depends on what exactly you want doing.

After skimming quickly through that, it appears you are using hard-coded form definitions: can your system cope with a form with a variable number of form fields? With some forms, you don't always know in advance exactly what the field list will be - hence you would need to define the form meta data dynamically.

If mine, then yes, you do have a point. From SleepEasy's script and the XML file - as it's actually the document (page) it's self, there may be a way of dynamically altering the INPUT being transformed dynamically I suppose.

As for me, at the moment I'm not too concerned about dynamic FORMs. For the moment

One issue I can think of at the moment is how a dynamic element would be generated yes ?

From server-side, or via client-side Javascript and the DOM.

Off the top of my head, the Form Validation that I have doesn't really (it's self) care about what constitutes a FORM, all it needs is the RegExp and Error tags on a per Form element basis.

These could be generated on the fly, what concerns me is how to generate the actual FORM then ?

After skimming quickly through that, it appears you are using hard-coded form definitions: can your system cope with a form with a variable number of form fields? With some forms, you don't always know in advance exactly what the field list will be - hence you would need to define the form meta data dynamically.

This "system" was designed for forms that don't require variable numers of inputs, but I understand the point your making.

If you needed you could dynamically create the form definition, or append new inputs to an existing one. That would work fine as long as you did this before calling the populate() and validate() Form methods.

I still have a few things to do before I'm happy with the class and I might add something to make it easy to work with the types of forms you're referring to.

This "system" was designed for forms that don't require variable numers of inputs ...[ etc ] ... I might add something to make it easy to work with the types of forms you're referring to.

Thanks for the comment.

Just to give you an example of what I was thinking about, suppose you have an "add new discussion board" form in a forum app. When you add a new board you almost certainly want to assign privileges for various user groups but there is no way for the program to know in advance how many user groups you have. Hence a part of the form meta data has to be calculated dynamically.

Also, you need to consider what happens if the data used to calculate a variable fields list is changed by someone/something else while you're busy entering data & submitting a form. With the forum example, say another admin has added or deleted a user group while you are adding a new board.

If the form meta data is defined at the time the form is processed it will be incorrect - the original form was created with different fields. Validation could produce a false positive since meta data doesn't list all the POST keys. If you check submissions for alien POST keys, they would always fail to validate.

The solution might be to define the form meta data when the form is first displayed. When the form is processed, check the definition is still valid before proceeding.

That's maybe a bit of an obscure and unlikely use-case but worth bearing in mind.