RE: [PEAR-DEV] Performance question + new packages?

Hi, No that is not at all what I am proposing. I am proposing a more general approach towards building application in a HTML_QuickForm kind of fashion. But using the same approach to build Tables and Reports. But is can be the base for building any kind of gui object. The objects self are not pruned towards HTML. Instead a renderer converts the object to output. Any QuickBuild object, which can be a form, table, header, input field, etc may be plugged with a renderer, (it uses that of its parent by default). This allows to render as normal HTML, frozen HTML, but also PDF or a RIA or a voiceXML app or ... Each class specifies an renderer interface which has to be implemented by the renderer. If not, an equivalent is found. This makes it really easy to create custom elements as well as customer renderers. You may also create or extend a render for a non-QuickBuild objects. Meaning you may add a Image_Graph object to a report (using its own methods to create HTML, but letting a PDF renderer grab the data and custom create a graph) You can also plug converters into a number of QuickBuild classes, which allows you to create a QuickBuild object from a dataset and also update the dataset from values of the QuickBuild object. This allows quickly transferring from database to content and from post back to db, but may also be used for other conversions. A converter holds no base class, only an interface. Combining converters and renderers might allow you to quickly web-enable an application build with an other GUI builder (like PHP-GTK) and combining it with parts not build with that GUI builder. Last you may plug so called modifiers. A modifier has no predefined function, but can be used to add something extra to a QuickBuild object. A implementation of modifiers can be a validator, a formatter (formatting the data), a modifier adding extra content, an action, an event, etc. All modifiers implementing a certain interface or extending a certain class may be requested. The modifier doesn't act itself, but can be may be used by the QuickBuild object, the renderer, the convertor, the parent object or whatever. Because a modifier is bound to its object, it may be used out of context. Modifiers may be grouped under a single name, so adding 'date', might case to add a format, add a validatior and noting a calendar should be added. (A PDF renderer will only format the date, while an HTML renderer will also add the calander) All QuickBuild objects, Renderers, Converters and modifiers are stored by class name in extendable factories. QuickBuild uses these object by reference and not by class name. This lets you extend QuickBuild with your own simply overwrite a class with another. For instance, you may overwrite the HTML entry in the renderer factory changing how HTML is generated, but not how frozen HTML is rendered. Also the factories should make sure that only classes are loaded that are needed, though this doesn't work correctly yet (I hope I might save a little processing time their) I didn't use HTML_QuickForm, simply because it doesn't meet my needs. The structure and code did not lend to reuse or extend, so I created it new. It does supersedes HTML_QuickForm. The API is a bit the same, but not quite, meaning it isn't possible to quickly step from HTML_QuickForm to QuickBuild. Though I believe it is a somewhat simpler API, though the packet itself is a bit more difficult. You do most of the configuring statically, and only define differences for an object. You may configure and store objects in the factory and use them throughout the application. This and other thing (not discussed here) reduces the actual code you have to write and with that the developing time drastically. At least it writs you from writing 'the same thing' again and again :). I could imagine others are also interested in a package like this, but I've written it because I need it myself. Making it public might also inspire people to write some extensions for it, but if nobody is interested, that's fine. Performance is always important and I do not want the application to feel much slower than when you would have a KISS implementation. I am aiming for a maximum overhead of 100ms + 25% (max 500ms overhead). In the example, the 250ms page should load in max 400ms. A 2.0 second page, should load in 2.5 seconds. The execution of the code itself only seems to take about 80ms (of which 20ms spend in the factory), which is acceptable. The rest of the time I believe (if I've interpreted Zend optimizer correctly), is used by including files and parsing the classes and interfaces. Ian Eure has graciously offered to take a critical look at the code. So, I hope he might give me a view pointers about performance in PHP. I was formally a Microsoft programmer (don't shoot), so I do not exactly know all pro's and prons. Arnold -----Original Message----- From: Luca Mariano [mailto:luca.mariano@gmail.com] Sent: vrijdag 15 juli 2005 9:46 To: php@adaniels.nl Cc: PEAR developer mailinglist Subject: Re: [PEAR-DEV] Performance question + new packages? On 7/15/05, Arnold Daniels <arnold@bean-it.nl> wrote: > HI all, > > I've got some performance issues some of you might recognize. I've build > a number of classes (I will make a pear package and propose it when it > is all finished) which are loaded on each page. Including all these > files takes up quite some time, about 250ms, without executing any code, > accept declaring classes of course. When a page normally loads in 250ms > and now become 500ms, it feels sluggy instead of fast. > > I can imagine a project build with a lot of pear packages should run > into the same issues. I was thinking about perhaps using ACP or some > other cacher. But does anyone have some other ideas. > > [...] Hi Arnold, speaking about HTML_QuickForm: when using such packages you usually aims to quickly developing, without so much care for performaces & layout customizations. Typical usages are backoffice, admin interfaces, etc. So I can't understand what are you proposing: another form generation package, with a focus on speed instead vs. versatility (as Cache_Lite vs Cache)? Or a different implementation with all the features of html_quickform but better optimization? In the second case you might want to collaborate with html_quickform mantainers to improve the existing (html_quickform2 ?), istead of committing a new package - just to avoid overlap. Regards, Luca -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php