Page 1 of 1

Testing / Critiques for an Open Source Project

Posted: Sat May 02, 2009 12:38 pm
by david64
Hi,

I have recently released an open source project called XFL - eXtensible Form Language. It is a XML transformation language designed to make creating and handling forms in PHP quicker, easier and more of an application.

Some of its features include automatic field population, automatic error reports and support for multiple-depth repeating forms.

It also has extendible functionality, which should be pretty self-explanatory.

Code: Select all

<input>
<xfl:validate type="minInt" value="10" error="Must be at least 10" />
</input>
You can find the project page here:

http://semlabs.co.uk/products/xfl
Docs: http://semlabs.co.uk/docs/xfl
Demos: http://semlabs.co.uk/docs/xfl/demos

I've done quite a lot of testing and am not having any problems, but I am sure there are some bugs to weed out. I am also interested in how easy people find it to use, how easy it is to understand, what the quality of the documentation is and any other ideas in general.

Re: Testing / Critiques for an Open Source Project

Posted: Sat May 02, 2009 2:21 pm
by kaszu
What about multiple language support? Each language would need to have its own xml file or can it be done somehow else?

Re: Testing / Critiques for an Open Source Project

Posted: Sat May 02, 2009 2:43 pm
by david64
What languages are you talking about? Server-side languages?

Re: Testing / Critiques for an Open Source Project

Posted: Sun May 03, 2009 7:34 pm
by kaszu
Like one error messages in english, other in german, etc.
Form and validation will be the same but for different languages messages will be different.

Re: Testing / Critiques for an Open Source Project

Posted: Mon May 04, 2009 8:45 am
by nwhiting
From looking around at the demos and the docs.

Looks like something that will be pretty useful....

Although your class is just simply massive, it could be broken down into smaller subclasses that perform each specific task needed, such as data methods, array methods, error, strings it would be much tidier and easier to maintain.

The class also provides no support for extendability.....a lot of your properties are set to protected and almost all of the methods are private....and from scanning the class I do not see a valid reason for this, unless you intend for anyone wanting to modify the class itself to go messing with its core functionality instead of simple extending it (very bad idea) and only modifying the methods they need.

While your whole goal is really the XML form generation the heart is the PHP parser, and a lot of people will want to extend/modify/improve upon it, this being a open-sourced project. Not proving extendability to the parser itself will hurt its popularity amongst that crowd.

My Suggestions improve the parser, break the class down into more defined classes that perform specific tasks only, allow for better extendabililty, take some time and read up on this.
http://us2.php.net/manual/en/language.o ... bility.php

Its off to a good start, but there are many areas to improve upon.
(Note)
I did not look into how you are parsing the documents or how it is handled, mainly for the reason of the class size.

Re: Testing / Critiques for an Open Source Project

Posted: Mon May 04, 2009 6:13 pm
by david64
@kaszu: Errors in different languages can be handled.

@nwhiting: Thanks for your input. Some good points.
The class also provides no support for extendability
The base class is not actually meant to be modified. There are a number of classes which can be added to that provide the extensibility. These are the Validate classes and what not. However, you are right, there are too many private and protected bits 'n bobs. I need to change this as I want to move some of the current methods in the base class into the respective classes.

What is your reasoning for saying the base class should be broken down into sub-classes? There are some methods (probably about 200 lines that need moving) but the rest I am happy to keep in one class. Are there any speed/resource benefits of using sub-classes? If I did split them down would you recommend putting each class in a separate file? Or just have them all in the same class? That is the way I have seen people who work on PHP doing it. The problem is some people don't use autoload or have different settings.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 8:53 am
by nwhiting
The class should be broken down into smaller pieces because that is the way OOP was intended to perform, each class (in theory) should perform its own operation, this allows for maintaining your project to be much easier. For instance when you want to modify how array information is handled instead of chugging through a thousand line monster file you simple go that class and modify as needed.

As far as autoloading is concerned why do you need it, there is no reason you cannot include() the other files, because distributing this to other programmers that will use it within their already existing programs that will possibly have an autoload feature already; It would be impossible to do.

You will want to seperate each class into your own file.

As for extendability, which classes are these that you can extend and built of off? Any extending done would need to be a completely rewritten classes that are not extended by the "core" parser class, that would not really be considered extending but more of an addition.

Here is a quick breakdown on the scope of methods/properties.

Private methods should be methods that you want to exist only in your parser class and will not be avaliable in any class or object reference that someone creates that extends the current one.

Protected methods should be methods that you want only to exist in your class and any subclasses that extend the current, but will not be avaliable when used with a object reference.

Same goes for the class properties.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 9:55 am
by david64
As mentioned there are about 200 lines that really should be moved into other classes. Other than that there is only a small amount of code that is not necessarily going to be used each time. As you point out there are different things that are going on in the main class. However, my main problem with making little classes for each thing that is going on is that you would have to include an extra couple of files or alternatively I could just leave them all in the main file. I don't like the idea of having to include lots of little classes.

As for autoloading. I noticed you are using Zend Framework. I am using the same autoloading as is used in Zend which is what pretty much everyone else is using.
As for extendability, which classes are these that you can extend and built of off?
Yes. You are right, the classes are only intended to be added to not extended. If you download the files. There is an XFL folder that has classes in it that are intended to be added to. For example, you might have a form input field that you need to ensure has a value that exists in a dictionary. To make this work you would need to add a method to the validate class and then you can use that whenever you need it by doing something like:

Code: Select all

 
<input>
<xfl:validate type="isInDictionary" />
</input>
 
This is the extensible nature of the project. XML is the perfect choice to power some sort of controller. For example you could do:

Code: Select all

 
<input>
<xfl:magic type="some type of magic" />
</input>
 
To create some new kind of form processing.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 10:00 am
by david64
BTW any chance of a gander at your project? Don't have time for testing, but quite interested in having a look at a plug-in system. I have pondered how I might create such a system.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 10:06 am
by nwhiting
david64 wrote:BTW any chance of a gander at your project? Don't have time for testing, but quite interested in having a look at a plug-in system. I have pondered how I might create such a system.
Event Dispatchers, the theory is quite simple.

You have a collection that holds observers that are triggered by specific events,
How you have this collection and call them by specific tasks well, that is the fun part to figure out :)

But if you have trouble the release of the project will be no later than the end of may and you can see how its done :)

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 11:40 am
by david64
I have used JavaScript-esque events in PHP before. Is that the sort of thing you are using? For example, after a comment is retrieved from the database you have to manually insert a bit of code that says there is an "onCommentRetrival" event here?

I was wondering if there might be something a little more ingenious. Someone I know worked on adding events when methods are called - said it was a bit of a mess though.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 12:26 pm
by nwhiting
dispatching events when a method is called would involve quite alot of work and require each class to use __call to dispatch events ......... this would not be a very considerable way to do this as with a most largescale applications they can call hundreds, thousands of methods a load (imagine looping through all observers thousands of times)........

All I do for events is this simple tad bit of code, it may seem simple and it is but that is the point 8)

Code: Select all

 
Unus::dispatchEvent($eventName);
 
The system handles everything else, and what it does is send it over the to event observer that tells the observer collection that something just happend, the collection then tells the event observers what is happening if any of them are waiting for this event, or have a event that matches their regex they are dispatched and run, but for a powerful plugin system you need to have everything tied into together that way you can modify any part of the system as it loads within events from object properties all the way to what is finally displayed from the view.

Remember a good programmer doesn't make a extremely complex system that no one can understand, he makes a extremely complex system anyone can understand.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 3:45 pm
by david64
I don't think he was using __call, but it must have been something like that. Think it might have been using reflection gubbins.

Code: Select all

Unus::dispatchEvent($eventName);
This is the same way I was doing events until I removed that part of things from my code base.

So if you are defining events with the above code, what are you doing to add an event?

Code: Select all

Unus::addEvent( 'eventName', 'eventMethod' array( 'args' ) )
Something like that? I was doing something along those lines.

Re: Testing / Critiques for an Open Source Project

Posted: Tue May 05, 2009 4:28 pm
by nwhiting
david64 wrote:I don't think he was using __call, but it must have been something like that. Think it might have been using reflection gubbins.

Code: Select all

Unus::dispatchEvent($eventName);
This is the same way I was doing events until I removed that part of things from my code base.

So if you are defining events with the above code, what are you doing to add an event?

Code: Select all

Unus::addEvent( 'eventName', 'eventMethod' array( 'args' ) )
Something like that? I was doing something along those lines.
There is no need to add an event anywhere only dispatch them.

Observers on the other hand are added via a built in intelligent system, depending on the current mode you have the system set in. All observers are stored in a directory which houses all of their code.

The plugin system is 2 completely separate parts the event dispatcher only interacts with the observer collection when it is telling it what is currently happening, the dispatcher has no clue what observers are waiting for the events its dispatching, as thats is not its purpose, that is the purpose of the observer collection :)

The way the system is constructed you are not limited to only having one observer called per-event, there can be an unlimited number of plugins loaded from a single dispatched event.

New Observers "or plugins" are automatically installed and added into the database once they are added into this directory and can be enabled/disabled via the administration.

If you are set in "Developer" mode any new observers are automatically installed added and set as enabled and will run on that page load if an event calls it, observers do not need any arguments called with them because of the way I have built the system.

There is only one line needed to call a plugin and that is only.

Code: Select all

 
Unus::dispatchEvent($eventName);
 
The plugin system is all automatic and requires no interaction, between the programmer and the plugin ( well expect for development of it )

Re: Testing / Critiques for an Open Source Project

Posted: Wed May 06, 2009 10:35 am
by david64
I think I understand what you mean, but it is hard to really describe this stuff in a few lines in a forum. Will take a look when Unus is out in the open.