Hi Matthias, First of all, thanks for all the feedback. I really appreciate it.
On Tue, Feb 10, 2009 at 8:59 PM, Matthias N. <[email protected]> wrote: > I think it would be a good thing to have support for multi sort with > sfGrid. And I have a suggestion how this could work and look like > without Javascript: Your solution could work, but sounds kind of complicated. I don't have a problem with complicated solutions per se, but I think you can easily fall into the invest-lots-of-time-into-features-noone-will-ever-use-trap. That is why I want to program the really essential features first and make them as stable as possible before the release of symfony 1.3 in November. Once there is a beta version of the grid, we will see which features are missing and are really important - maybe the interactive multi-column-sort is one of them. What I _do_ think is possible though is a multi-column sort through the API, without user interaction. > I think you should definately introduce an sfGridRoute class for > simplifying all your link stuff, for example the makeUri() should be > refactored to use a route rather than hacking it.. ;-) That is a possibility, but until now it just wasn't necessary. We'll see whether it proves to be in the future. On Tue, Feb 10, 2009 at 9:07 PM, Matthias N. <[email protected]> wrote: > There should be a way to enable a dynamic / automatically built filter > form and place each filter widget right below the column head. So that > you have form fields at each column to filter records which makes > filtering pretty intuitive to use. I can remember you already mentioned this feature in the discussion about the new admin generator. As with the multi-column-sort, this is a very specific feature and I do not know whether it will be built in right from the start. Now, after crushing all your hopes ;-) some more positive news. As you may have seen by looking at the source and the extensive source documentation, the grid plugin is pretty well decoupled and extendable. Even _if_ the above features won't be provided in the core, it will be fairly easy to program them yourselves. The grid subframework follows a strict MVC architecture. The model consists of sfDataSourceInterface and implementing classes, the view of sfGridFormatterInterface and implementing classes, and the controller of sfGrid and sfDataSourcePager (which may be renamed and replace the old sfPager class). The big benefit of this architecture is that you can use a wide variety of data sources (Doctrine, Propel, CSV, XML, REST, custom formats) and display each of them with a wide selection of formatters (HTML, plain text, AJAX, custom formatters). The sources and the formatters are connected through sfGrid and its descendants. The second big benefit is that you can use single components of the architecture stand-alone, without the grid. This especially makes sense for the data sources and the pager, which are not only mightier than the old sfPager, but also much easier to use. After all, you will be able to modify and extend the grids fairly easily. Those features that are not bundled with the core will be fairly easy to implement and plug in. For all those who still follow me and are interested nonetheless, I can recommend to look at the source of sfGridPlugin. Most files contain really extensive documentation - those that don't, will do in the future. http://trac.symfony-project.org/browser/plugins/sfGridPlugin/trunk http://www.symfony-project.org/plugins/sfGridPlugin As soon as the plugin is in beta phase, I will publish tutorials and articles on our blog. Bernhard --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
