Re: Re: Your opinion about QuickForm2 API

Antti Holvikari wrote: >> If what you describe is exactly how Solar works, then it's not a >> cache... You will have to create the form from the ground up. There >> will be no speed benefits, quite the opposite. > > Yes, you're right. Maybe "cache" is the wrong word for it. I got > mislead by Greg's words: "only need to be created programmatically > once". What I mean is that you can "cache" the form creation logic, > which makes a lot more sense to me than caching the form output, if > that is what you mean. You can cache your HTML however you want > anyways... > > The key point is separating your logic from the actual view. > > Does this make any sense to you? :-) Hi Antti, I don't find any current implementations of forms to have a true cache. The problem here is that a form is always changing. It must respond to user input, display errors, and so on. However, the logic of how the form is constructed is completely static. Since the only thing we really need to be able to do is proper validation of form fields, and then to fill in a few placeholders (default value, error messages if any), this data can be cached as html, saving the need to construct a huge tree of objects. For high-volume sites, this could provide a large gain in requests/second, whereas building the form from an array is no different from building it with method calls - except you have the added step of parsing the array. Separating logic from view is irrelevant to my suggestion. Quickform 1.x used renderers to do this, I suppose Quickform2 will have some facility as well. Greg