Re: DB_DataObject and Structures_DataGrid integration
| From: | Markus Wolff | Date: | Sat, 14 Aug 2004 16:42:33 +0000 |
| Subject: | Re: DB_DataObject and Structures_DataGrid integration | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-32662@lists.php.net to get a copy of this message | ||
Olivier Guilyardi wrote:
What I dislike is having to handle raw $_GET parameters while, say, for example HTML_menu, parse them as well, sort of behind my back. I'd say : or I handle them all, or I handle none of them, in which case there must be some kind of powerful framework which does it for me. Don't get me wrong though, I like and use HTML_Menu :)I haven't used HTML_Menu until now. LiveUser for example can also handle GET/POST requests for logins automatically, but it lets you configure which of these methods is being used and what variable names it expects. If this isn't the case for HTML_Menu this should probably be added. I have no problem about packages using their own GET parameters in the background as long as it can be configured.
Actually, most of my knowledge about events comes from using GTK in C. And in this environment, your statement about "loosely glued components" is quite wrong. But for web development, and PEAR, I just don't know. I like GTK, and well : <select>, <a>, etc... Aren't these all widgets ?I'm always talking about the web context here - you're right, for desktop apps, this approach makes sense, as you have to react on user input directly and don't know what to expect next. Web applications, however, are linear (request-based). All the user interaction has already happened. You just get the results and can deal with them, from a defined script start to a defined script end. No such thing for desktop apps. It's two very, very different pairs of shoes. Regarding the widgets: In theory, you can regard each tag as a widget, yes. But to be recognized as such, you need to create it programatically. Your script has to know about each tag and its capabilities. Meaning: You need an object instance for each tag and a fairly complex hierarchy of classes. For PHP, the words "overhead" and "interpreted" come to mind yet again. It's just not what the language is meant to do.
It's not that I'm more experienced with desktop development (I know better cgi), but I just feel like the traditional widget+event+handler paradigm is powerful. So the .NET way about this attracts me.Then why not use .NET? :-)
I've never used an integrated framework. I looked thoroughly at BinaryCloud a while ago, but it did not attract me. Maybe is this a Cathedral and Bazaar issue. And, as an integrated framework, .NET for sure belongs to the former category, while PEAR is more on the Bazaar side.Which is precisely what I like about PEAR :-) Have a look at PHP.MVC, there's also an attempt to port most of the ASP.NET paradigm to a PHP framework, but I forgot the name of the project... CU Markus