Re: DB_DataObject and Structures_DataGrid integration

I've been watching this great thread for the past two days, and was really inspired by this convo to hop in. My thoughts below: On Friday 13 August 2004 11:37 am, Markus Wolff wrote: > Olivier Guilyardi wrote: > > Markus Wolff wrote: > >> Don't get me wrong, event handling isn't a bad thing (as mentioned > >> earlier, I'm about to propose a general package for that in the near > >> future), but in web applications, it shouldn't be used for flow > >> control. This is just plain wrong. > > > > What do you precisely mean by flow control ? Do you consider that > > responding to a user clicking an Edit button on a DG is about flow > > control ? > > Well, in a way it is - IF this happens, GO there and DO that. A bit like > the much-feared proposed GOTO-operator for PHP - okay, maybe not :-) 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. > > In the case of the DG, I agree that a whole event-handling framework > > isn't needed. I'm just interested by taking _some_ of the event/callback > > paradigm to abstract HTTP requests, and specifically forget about the GET > > hell. > > What do you mean by the GET hell? Using events will not let you get rid > of GET parameters. They must still be passed from request to request and > they must still be evaluated - otherwise, how would you know what is > supposed to happen on the page? > > IMHO, using an event-based system to determine what's gonna happen on a > page in general will result in a great loss of flexibility. Event > systems are much better suited to loosely glue components together which > otherwise wouldn't know about each other. In CEP, we use events and states (states being groupings of functionality offered by a component) to allow us to break the 'page load' paradigm and make us ready to build a system like Gmail today. The only point I am trying to make here is that let's make SDG as flexible as possible. Why should datagrid components be forced know about each other? Wouldn't it be much better to be able to use the same datagrid in different modules in my code, and simply have use an open ended callback. In general, attachment to any variable scope is just limiting. > > But, it surely is different of desktop apps. A callback function > > may not be enough. It would be nice to be able to define an event handler > > with a dsn-like sort of thing. It could be a callback function, or a > > script path+parameter, etc... > > Are you talking about page event handling in general here, or the > DataGrid component?? > > Anyway, to enable a truly event-based page handling mechanism you > usually need a real framework, like .NET. PEAR is not a framework, it's > a collection of independent libaries. If you want a tightly integrated > framework, you can look at WACT, Binarycloud, PHP.MVC or ISMO. There's > no need to reinvent the wheel. 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. - Marcus