Re: DB_DataObject and Structures_DataGrid integration

Hey Markus, good questions posed. I will address below your comments. On Saturday 14 August 2004 11:52 am, Markus Wolff wrote: > > Marcus Whitney wrote: > > I think that with the oncoming demand for rich web applications, event > > handling is becoming a necessity in web applications. I say this with > > the experience of having written a pretty high use web application with > > Jackson Miller, and a couple of not so great ones on my own :) . Web > > Applications have to move from the 'page load' paradigm if they are going > > to evolve. Web programmers need to make embeddable components. That is > > when we will start to see the velocity of development that we see with > > projects like KDE (KPart). And, it is possible. > > [...] > > Possible, yes. But PHP IMHO isn't the right language for that. And is it > really needed? Let's see what you say next: 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. > > PEAR is not a framework, but the packages in PEAR should be built to be > > easily incorporated in a framework. Wouldn't that bring us all closer to > > PEAR and cause less reinventing of the wheel? I mean, that's why I work > > on CEP, because every framework I have seen does not embrace PEAR, and at > > the end of the day, PEAR is what I want to use. > > > > And just a note about desktop vs. web apps: XUL, xmlhttprequest and > > remoting in general should be a clear indicator that web programmers > > needs to start learning some desktop app concepts. Programmers typically > > have there own opinions, but as an architect who is used to crafting the > > web to be as user friendly as possible for over 500 customers who I speak > > to regularly, let me assure you, they want desktop ease of use. > > Yes, they want desktop-like web apps. Precisely what I'm thinking as > well. But XUL, which you mentioned, is the perfect example how this > should look like: Having a strong application frontend at the user's > machine. This can be XUL, which handles all real user events using > Javascript, or a Flash Remoting application (again, using Javascript > internally to handle events). > There must be a distinction between frontend and backend. A > non-request-based frontend will have to handle events. A request-based > backend will not have to do that. It handles requests. 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? > PEAR provides 95% backend components. If event systems are introduced > here, then not to handle user events, but to allow loose interactions > between components. 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. > > CU > Markus