Re: DB_DataObject and Structures_DataGrid integration

Marcus Whitney wrote:

I have the freedom to say that PHP is just as good a language as any other for this purpose. If I were to make a PHP binding for KDE, then I could use KPart and do just that in KDE. The whole argument of limiting what PHP can accomplish doesn't reflect real world tasks. I accomplish them everyday with PHP.

Sure. I mean, we got PHP-GTK, right? So you *can* do desktop apps in PHP. That doesn't say it was meant to do that and it doesn't say it's the best tool for the job. It may be, in certain situations - for example, if you can re-use a lot of existing code from a web app or something, but otherwise... I'd rather use something else, be it Python, Java or whatever.

In networked enterprise applications, remoting means that XUL will only be able to handle the returned data from a request. An event is a moment with a purpose during the execution of code, and that isn't limited to the 'frontend'. There are plenty of events that occur on the server side. If I am in a datagrid on my browser, and I have my sorting set to traverse an entire table, the sort widget in the interface would have to remotly call the server for the dataset respective to each sort request. That request may be to a daemon, or a framework application on the 'backend' where there is an event life cycle. Yes, there is a distinction between events and requests. No, events are not restricted to the frontend. - J2EE has multiple life cycles (Servlets have one, EJBs have one) http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Servlets4.html http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts9.html - ASP.NET / MONO has a life-cycle http://www.15seconds.com/issue/020102.htm Why shouldn't PHP on the server have events?

Who says J2EE or ASP.NET are better suited for web applications than PHP? The concepts are pretty different. Personally, I don't like the way they do it. It's overcomplicated, and unneccessarily so. I don't say that there may not be server-side events. I just say don't use them for flow control, and I say PHP is not well-suited for the "everything is a widget and you just catch the events"-approach, because this means a whole bunch of objects, an even bigger bunch of classes, all having to be parsed, instantiated, processed etc. ... it will eat up a lot more RAM and a lot more processing power than the "traditional" way - and on top of it all, it will complicate things, heighten the entry barrier and make rapid application development less rapid, because if you want to do it the widget way, you have to do *everything* the widget way, or your code will be a mess. Hence, you lose flexibility, you lose choice. Anyway, that's just my opinion (which, luckily, I'm entitled to :-)), and you're, luckily (again), not bound to agree with it :-)

I choose to use PEAR whenever it's feasible. So, if I want rapid application development with PEAR, than I need a consistent platform to begin developing. Not saying that it belongs in PEAR, but PEAR best serves enterprise application development if the components are as component like as possible. A Model would allow better interoperability between packages for programmers. You can code in your container, get new stuff done and then refactor later.

Agreed. A component should be an encapsulated entity which can do its thing and you can work with its output, whatever that might be. Does that mean everything has to be a widget? Nope, it doesn't. I don't think this discussion is getting us anywhere and regarding the subject, we've been way off topic for quite a couple of posts anyway, but there's one good thing that has come out of it - Olivier's idea for a "Glue" category in PEAR. I really like the idea, although, I'd call it "Adaptor" instead of "Glue" :-) CU Markus P.S.: I'm leaving town for a few days so don't be surprised if I don't answer the next few follow-ups.