I think the best approach is to use something like Flex DataGrid. See http://www.adobe.com/devnet/flex/quickstart/using_item_renderers/
Its uses some kind of data renderer concept. The table would have a default data/cell renderer. It should accept a data/cell renderer per column. For instance, the render method of CellRenderer interface could be render($data, bool $odd). The user could extend this pieces and not the table widget itself, which is the "controller". The widget could receive a creole result set, a criteria, ... (and doctrine "brothers") This approach clearly follows MVC pattern. On Dec 18, 1:54 pm, "Tristan Rivoallan" <[EMAIL PROTECTED]> wrote: > On 12/18/07, Ian P. Christian <[EMAIL PROTECTED]> wrote: > > > > > Fabien POTENCIER wrote: > > > The biggest problem of a table widget IS the separation between what > > > belongs to which layer: the View, the Model, or the Controller. This > > > separation is very important and quite difficult to achieve. This is the > > > same kind of problem I tried to solve with the new form framework. > > > Here's a really simple mockup which might provide food for thought... > > sorry to interrupt, but why not just port pear's structures_datagrid to php5 > ? > > http://pear.php.net/package/Structures_DataGrid > > it's a fairly robust component. > > ++ > tristan > > -- > Tristan Rivoallanhttp://www.clever-age.com > Clever Age - conseil en architecture technique > GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
