Today I have submitted an implementation of sfDataSourceImap, which is capable of connecting to an imap server and sort,filter and iterates over all messages in a folder.
Of course since the sfDataSource-interface is used you can provide this dataSourceImap to the sfGrid object et voila: you can now interact with your e-mails in a grid, capable of sorting, paginating and using widgets for markup. This way you can get an idea about the capabilities of the sfGrid with the sfDataSourceInterface. Currently connectors for propel, doctrine, arrays and imap have been written. The Propel implementation accepts class-names (which makes it perform automatic joins when required), or Custom criteria (which allows you to optimise queries without hydration (although still possible if you specialise the implementation), For Doctrine something similiar counts, but this is written by Bernhard. Everything can be customised by extending the base datasources. I will now try to add new formatters for the grid, to make it return extjs-grids, instead of the current HTML-grids. On Mar 11, 11:53 am, Leon van der Ree <[email protected]> wrote: > See > alsohttp://propel.tigris.org/ds/viewMessage.do?dsForumId=1097&dsMessageId... > > On 6 mrt, 15:03, Leon van der Ree <[email protected]> wrote: > > > I've updated the sfDataSourcePropel implementation last days and I am > > getting pretty happy about it. > > > In short the idea: > > > we want to have a grid, with widgets in order to generate a sortable- > > paginated-table-view, from many different datasources (SOAP/XML/CSV/ > > Database (Propel/Doctrine)/Array) > > > This rendering of the grid and table is done with thesfGridclass, > > however we need to feed this a standardised interface for the > > datasource: sfDataSourceInterface. > > > This can be implemented for all your dataSources. I have now defined > > it for Propel, Bernhard had already written it for Doctrine and Arrays > > (I might have broken this implementation during my latest improvements > > for the sfDataSourcePropel, this will of course be restored). > > > sfDataSourcePropel uses a new helper for Propel that I have defined: > > sfPropelPropertyPathHelper, in order to simplify the customisation of > > joining and hydrating related objects. > > > Two examples of this helper: > > Example 1: > > > $criteria = new Criteria(); > > $objectPaths = array('Foto', 'Foto.Album'); > > > $criteria = addJoinsAndSelectColumns($criteria, $objectPaths); > > $fotos = hydrate($criteria, $objectPaths, $connection = null); > > > foreach ($fotos as $foto) > > { > > echo $foto->getAlbum()->getTitle(); > > > } > > > Example 2: > > > $criteria = new Criteria(); > > $objectPaths = array('Album.Foto'); // no need to provide Album first, > > this can be deducted (similar in the first example) > > > $criteria = addJoinsAndSelectColumns($criteria, $objectPaths); > > $albums = hydrate($criteria, $objectPaths, $connection = null); > > > foreach ($albums as $album) > > { > > foreach ($album->getFotos() as $foto) > > { > > echo $foto->getTitle(); > > } > > > } > > > The DataSourcePropel-implementation is making use of this helper > > (although you can extend the DataSourcePropel implementation to your > > like and use default doSelectJoin and doCountJoin methods from your > > peer-class). Currently it makes it possible to join and hydrate easily > > and also allows you to automatically sort on related-columns. Support > > for custom-columns is already partly available and only needs some > > minor improvements. > > > An example of using the sfDataSourcePropel with sfGrids is: > > > $source = new sfDataSourcePropel('Foto'); > > > $this->grid = new sfWebGrid($source); > > $this->grid->bind($request); > > > $this->grid->setSortable(sfGrid::ALL); > > $this->grid->setColumns(array( > > 'Title', > > 'Album.Title' > > )); > > > echo $grid; > > > The album table will automatically be joined after it has been > > requested by the grid. > > > There currently is support for the following relations > > // - directly > > related: > > RelatedTableName > > // - related by multiple pk/fk > > pairs: RelatedTableName (pk/fk- > > pairs are automatically resolved) > > // - directly related, but multiple relations from base to > > parent exist: RelatedTableNameRelatedByForeignKeyName > > // - reversely related (one-to- > > many): RelatedTableNames (with the > > s) > > > // - NOT tested are self referencing relations (the issue with > > this is there depth is unknown) > > // - NOT implemented is joining i18n related tables automatically. > > > The definition of these relations is being generated by an extension > > of the propel builders and can be fully modified in your peer classes > > > Feedback is (again) appreciated! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" 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-devs?hl=en -~----------~----~----~----~------~----~------~--~---
