PEAR QuickForm

[Captain Proton]

One disadvantage of what you're proposing is this..

You want to merge the QueryIterator and QueryResult into one. This has the consequence that you cannot have two iterators running over the same QueryResult simultaneously. It's an incorrect assumption that such a situation will never happen.

[voostind]

This has the consequence that you cannot have two iterators running over the same QueryResult simultaneously. It's an incorrect assumption that such a situation will never happen.

I rest my case

Client code (Sequential) => eclipse (indexed) => PHP (Sequential)

I can see your reasoning from sequenced -> indexed -> sequenced, even though it is partly incorrect. (The QueryResult classes do not use a data seek if the rows are sequential, but indeed the total number of rows is always accessed). By the way, the fact that Eclipse internally uses an index for the QueryIterator is an implementation detail and therefore not really an 'impedance'.

But then again, have you examined (in detail) the class libraries of:
- C++ (the STL)
- Java (the Collections API)
- Delphi (the VCL/CLX)

They all work more or less the same was as Eclipse. This, of course, doesn't mean I was right in doing it this way, but you'll have to make a hell of a case to make me agree with you. Because if I would agree with you, I would also have to think the various libraries mentioned above are seriously flawed. And I don't. (And I secretly think you don't either.)

Vincent

[Selkirk]

Originally posted by Captain Proton
One disadvantage of what you're proposing is this..

You want to merge the QueryIterator and QueryResult into one. This has the consequence that you cannot have two iterators running over the same QueryResult simultaneously. It's an incorrect assumption that such a situation will never happen.

Nice catch. I missed this. I assumed that because both QueryIterators used the same PHP query resource, they would share the same "real" pointer. I see how the indexing mode inefficiently overcomes this by issuing seeks before every fetch when you have this situation come up.

Of course I have to ask, how often do you actualy do this? And I don't mean how often can you imagine it happening. I mean take some real code that uses eclipse. (not example code, not test code) Count the number of times is does this:

$query = new_QueryIterator($db>query("...SQL QUERY...")); 

versus the number of times it does this:

$query_=_$db>query("...SQL QUERY...");
$Iterator1 = new_QueryIterator($query);
$Iterator2 = new_QueryIterator($query); 

Remember those two multi-hundred thousand line systems that I talked about in my earlier post? Well, at one time, I had to convert both of those systems from one database manager to another. Neither system used a database indepent library. It took me a week to write up how to make the conversion and a contract programmer 6 weeks to do it.

It turns out that there wasn't really much variation in how the databases were called, despite having been worked on by dozens of programmers and having hundreds of thousands of lines of code.

The things that were problems wouldn't have been solved by a database independence library. (This personal experience is why I agree so much with not eclipses philosophy of not trying to do this.)

Some library implementers tend to over speculate on the actual amount of variation that there is.

I happen to beleive that libraries should handle the common case well.

My impression is that eclipse has some bloat in it where it saddles the common case with overhead from the rare case.

The array iterator has this too. It makes a bunch of gyrations to allow you have two iterators going at the same time, sacrificing the common case (you don't) for the rare case (you might).

How often do you need this? count. don't speculate.

So, I was wrong about a pass through adapter for QueryIterface being able to offer 100% compatibility. This is one case where it doesn't. I doubt I am wrong about how much this is actually used.

Why not have the array iterator just work for one array in a simple manner, and then wrap or subclass it to add the extra functionality for the rare case?

Why not do this for the queryIterator, too?

I would have no problem with a QueryIterator that you were not forced to use, as long as a simpler, more efficient iterator was available that followed the sequential model.

[Selkirk]

Originally posted by HarryF
My own view these days (after having wasted alot of time on code that was extremely hard to maintain) is that anything which improves a developers performance far outweighs any associated hit in application performance.

I completely agree. However, sometimes a library has to be held to a different standard. The purpose of the library is to improve developers performance for the users of the library. Not necessarily for the implementors of the library. (although generally the interests coincide.)

Library performance IS a valid criteria to evaluating a library.

There is a story that when they were developing the macintosh, Steve Jobs told his developers to reduce the amount of time it took the computer to boot. He told them to think of the number of potential users of that computer, think of how many times they will reboot each day, and then multiply that by the number of seconds they could shave off the boot time. This was the amount of time they were saving for humanity.

It makes some sense to pay attention to performance concerns in a library.

Going back to the question of code bloat, although you may argue that Eclipses use of abstract / interface classes constitutes bloat, but if you look at any concrete classes in the library, their methods and coding is highly discrete and minimalistic. It may not provide code that executes faster but it does make it very easy for other developers to understand.

What is the purpose of eclipse? Was it mean to be an educational tool or to be a useful library? I think hit the mark dead on as an educational tool, an exercise in object oriented programming. I am trying to describe why I think it misses as a useful library.

A library should be a black box. There is a barrier between the inside of the library and the outside. (encapsulation) One reason that a library can improve performance is that the developer can just use it without necessarily knowing the internal details of how it works.

While it may be nice for the library implementor's ego to be able to say "look how elegent this is," this doesn't necessarily help the users of the library. (sorry for the harse statement)

If the library is a black box, then you look at the code that calls the library to evaluate the library, not the code inside it. This is why I keep posting alternate versions of code call calls the library in this thread.

Every choice has a cost. Every time you offer the users of your library a choice, they incur a cost of making that choice.

Sometimes there is a cost for NOT being able to make a choice.

Designing a library means picking which cases to optimize.

A good library makes the common cases easy without making the rare cases impossible.

I don't feel that eclipse is built for the right cases.

(And I am talking about what things ACTUALLY get used, not what things MIGHT get used.)

If Vincent says "I only meant eclipse as an educational excersize," then I will say "It's great for that," and continue not to use it in my production systems. I brought up my issues with eclipse when people started suggesting using it instead of PEAR, which (I think) is meant to be a production library and not an educational exercise.

P.S.
I don't really think that eclipse is as bad as this post may lead you to beleive. And I really do dislike PEAR.

[Selkirk]

Originally posted by voostind


But then again, have you examined (in detail) the class libraries of:
- C++ (the STL)
- Java (the Collections API)
- Delphi (the VCL/CLX)

Actually I have. In fact, I did a complete port of the java Collections API to Delphi. Then, I implemented a database class in Delphi that used the ported java iterator interfaces.

In fact, I am also familiar with the class libraries for Eiffel, Clipper (Visual objects), Visual Basic, and Smalltalk. Are you?

Have you familiar with iteration in LISP? I am.

I have to admit, though, that I have only been paid to program in C, C++, Clipper, Visual Basic, Java, Delphi and PHP. Which languages have you been paid to program in?

You can disagree with me, but please stop trying to say that I don't know what I am talking about.

[Selkirk]

Ok, I want to clarify one last thing.

In his book object oriented software construction, Bertrand Meyer outlines a concept called Design by Contract. A contract is an agreement between two parties. In Design by contract, a class implements a contract with the code that calls it. Meyer introduced a new language, Eiffel, which provides language support for this concept. In Eiffel, you specify a calling convention (methods, parameters, and types). You also specify what each method in terms of preconditions (what things look like before), invariants (what doesn't change), and postconditions. (what things look like after.) Eiffel has language support for this style of programming. It is a powerful way of thinking.

If we move to java, java does not have language support for preconditions, postconditions, and invariants. It does have support for a contract in the form of a set of calling conventions. They call this an interface. Bertrand Meyer says that Java is "less object oriented" because it lacks support for these features.

Just because no language support exists for pre-conditions and post-conditions in java, does not mean that the methods do not have them. They are just unspecified. It also does not mean you cannot use design by contract. It simply means that you have to rely on your own discipline to enforce the contract.

Now we move to PHP. PHP does not even have the ability to specify the calling conventions in a contract. It has no interface construct. This does not mean that you cannot use design by contract in PHP. It only means that you must rely more on your own discipline to enforce the contract.

Now lets apply this to eclipse. The problem with design by contract in PHP is that it relies on the discipline of the programmer for enforcement. This is not really a problem with eclipse. It is the large number or people using the library who rely on the discipline of the small number of people (1?) developing eclipse to support the contract. The developers of eclipse have no need to rely on the discipline of any number of anonymous developers to enforce their contracts.

The abstract class Iterator in eclipse specifies a contract. however, It doesn't specify any pre-conditions, post-conditions, or invariants. Is specifies a calling convention. However, It doesn't enforce it. Subclasses are free to change the number of parameters or types. In reality it is merely executable documentation that adds execution time.


Lets say that you had to program in a language like C that doesn't support objects? Would you give them up, or would you continue to use the concept of an object, but adapt to the limitations of the language? Perhaps with something like this:

Class_methodname(Object, Parameters...);

Instead of

Object->methodname(Parameters);

Why give up the very useful idea of interfaces and contracts just because PHP does not formally support it.


The book that I recommended "fundamentals of object oriented design in UML" covers the concepts of pre-conditions, post-conditions,and invariants pretty well, and you don't have to learn eiffel and slog through Bertrand Meyer's 1300 page book.

I need to stop wasting my time here and start racking up more billable hours.

[Selkirk]

Originally posted by voostind

indeed the total number of rows is always accessed). By the way, the fact that Eclipse internally uses an index for the QueryIterator is an implementation detail and therefore not really an 'impedance'.

The extra access of the number of rows is an inefficiency directly caused by the impedance mismatch between the implementation and the interface it implements.

C++, Java, Delphi.

Because if I would agree with you, I would also have to think the various libraries mentioned above are seriously flawed. And I don't. (And I secretly think you don't either.)

The languages you mentioned are all statically typed compiled languages. PHP isn't.

I really have to get some work done now. anyone actually want to talk about forms?

[Phil.Roberts]

All this rhetoric flying about.... Its a wonder no-one gets hurt.

[fabbricino]

OK, soooo. About QuickForm ....

[petesmc]

Originally posted by Selkirk

Is a QuickSort faster than a bubble sort? Which implementation is bigger? Which is simpler?

OT: Um, quick sort MUCH faster than bubble sort and quick sort is also much more complicated.

[dnszero]

1) Selkirk and Voostind are both right.

2) There is no "Correct" answer to these problems. There is no magic bullet. There is no one-size fits all.

3) Every problem implementation has it's own Cost/Benefit trade-off that must be analyzed in terms of both the immediate and long term consquences.

4) There are several components of re-useability which must be weighed together: it's applicability to your intended goals for the software/library, ease of use, ease of maintanence, ease of extensibility, performance, and it's applicability to goals for which you never intended/imagined.

5) It is actually possible for intelligent people with different view points to have a reasonable discussion on a public board that can benefit the community at large. (This one was really the most surprising to me.)


I've ran into problems of this general nature in just about every aspect of web application development. Even though I have yet to find a "one-size fits all" solution to any of them, I still, naively, hoped to find one by the time I got to the end of this thread. But of course, this is the real world, and not a Design Theory classroom.

I think that both Selkirk and Voostind have very valid, and correct points, for different cases. It is refreshing to see both points of view presented in such a civil manner. Thank you very much for the info, and please, get together and write a book. Really. The problem with most info in book form is that you get one point of view and it's presented as the "RIGHT" way to do it. I'm probably not the only person who wants to develop several differnet problem solving techniques for their toolbox and the knowledge/experience to know which is the best one for the job at hand. Essentially this thread is treading down that path already, just keep it up. (It's really saving me a lot of work, not having to read/buy half a dozen different authors' books just to a build varied approach.)

Sorry to ramble on.

Thanks again.

[HarryF]

Been having a deeper look at QuickForm - despite any issues mentioned previously, what QuickForm delivers is excellent. For off the shelf functionality it pretty much has it all.

It is "geared" for procedural PHP scripts right now but it's not a requirement to write procedural code to use it except for what they call "filters" which are based on the use of call back functions (though it could be modified fairly easily to use a callback object method).

Either way, it sure beats coding HTML for a living.

[HarryF]

Continuing back on the subject of QuickForm, been playing yet more. This class has alot of potential IMO. What it offers in terms of functionality is really great but some fine tuning might help. If anyone else wants to give to experiment with it, would be interested to hear your opinions on how it could be refactored.

For me, right now the main problem right now, if we're talking a Model / View seperation, is it fails to seperate the two.

The first thing that could help would be a factory method in the main class which returns an object that is used purely for presentation logic and can be manipulated by a View. For sake of further discussion, call the main class FormModel and constructed class FormView.

In FormModel you do the work of what fields you'll have (and perhaps the type of field, e.g. select, for sake of ease of use), populating with data as required then adding any validation rules and filters (filters being used to "massage" submitted data, e.g. escaping apostrophies beforing INSERT).

For the rules and filters, each has their own abstract class which come with various pre-built children (as already available in QuickForm). If you need more you simply inherit from the abstract class and basically it's a Strategy pattern for each.

Once you're done, you use a FormModel method like getView() to return an instance of FormView, prepared with the fields you've already defined. Perhaps FormView can provide a Decorator pattern to make modifying the HTML easy.

[Captain Proton]

I'd hate to rant about layers, but..:

IMHO, FormModel is part of a layer that should be below the 'View' layer. The FormModel should have no knowledge of the fact that a View is using it to render HTML. Therefore, having a method getView() on a FormModel is in my opinion a layering violation. Not only that, it also makes the code reusable because it couples a FormModel to one particular FormView.

In FormModel you do the work of what fields you'll have (and perhaps the type of field, e.g. select, for sake of ease of use)

I think I've mentioned it before, but this is also something that limits reuse and flexibility of the classes. In theory, you could use one FormModel for different types of views, a standard HTML web browser view but also for a WAP view or whatever the future may bring us. If you include information about the type of form widget in a FormModel, you cannot reuse that same model for other types of views.

Whether this is important or not totally depends on the scope the classes and the environment they are meant to be used in. If this is only the displaying and validation of HTML forms, I see no problem in coupling FormModel and FormView this way.

[HarryF]

Yeah - you're right - been pondering this some more today - think the FormModel needs to have generic data types which can be mapped to HTML form elements (e.g. FormModel has a type "ENUM" for <select /> and radio buttons and a type "BOOLEAN" for checkboxes etc.).

The rather than using a factory method to create an instance of the view object, the FormView might better accept an instance of FormModel.

[BDKR]

Ok, I want to clarify one last thing.

Lets say that you had to program in a language like C that doesn't support objects? Would you give them up, or would you continue to use the concept of an object, but adapt to the limitations of the language? Perhaps with something like this:

Class_methodname(Object, Parameters...);

Instead of

Object->methodname(Parameters);

Why give up the very useful idea of interfaces and contracts just because PHP does not formally support it.

I know everybody seems to have gotten back to the QuickForm(s) (or whatever it's called) topic, but I just had to say that I think this is the most profound statement in this thread! Perhaps it's because I'm not a purist. This relates back to what Timothy Budd says in "Intro to OO Programming". Basically, that a language that suppports Objects, Inheritance, Polymorphism, yada yada yada, isn't required to program in an object oriented fashion.

I agree!

Now flame away!

Cheers,
BDKR

[Owen]

Actually originally all C++ did was convert code into C then compile that. So you can do everything in C that you can do it C++, it's just a lot more work. Actually a few years ago in school I had to do just that--write an object oriented program in C.

On a unrelated note I really like the PEAR class Cache_Lite. It works great, is fast, doesn't include the PEAR class and does one thing and does it well. Any opinions on it?

Owen

[BDKR]

Actually originally all C++ did was convert code into C then compile that. So you can do everything in C that you can do it C++, it's just a lot more work. Actually a few years ago in school I had to do just that--write an object oriented program in C.

You can include Objective C on that list too.

However, what the compiler (or anything else) is doing isn't the point. What we're talking about is whether or not the developer can make the conceptual leap required to accomplish this. For a PHP developer that never learned about modules or structures, this may be a little difficult.

Cheers,
BDRK

[Karl Kathy]

Oh goossh...I guess I have more lot to learn about creating a website. Reading this article confuses me. But in all in all the discussion help me to understand a lot of thing need or need to used in web designing. You have have very nice site, useful and informative.

[Angello mart]

Hey, I too have some doubts about PEAR QuickForm & When I have googled, I have got this page. Thanks for sharing some good info here. Good work buddy. I hope I will get more useful threads here in this fourm.......