Could we just change it so table_method is done first? - Jon
On Tue, Jan 13, 2009 at 12:48 PM, jukea <[email protected]> wrote: > > Just to add more information on that matter : > > For the sorting feature to work, what I did was move the use of the > table_method just before the sorting part is added (directly in the > actions code template) > > protected function addSortQuery($query) > { > if (array(null, null) == ($sort = $this->getSort())) > { > return; > } > $table_method=$this->configuration->getTableMethod(); > $query=Doctrine::getTable('<?php echo $this->getModelClass() ?>')-> > $table_method($query); > > $query->addOrderBy($sort[0] . ' ' . $sort[1]); > } > > and then comment the setTableMethod to the pager, since it's already > been applied to the query. > > This means requiring to fork the admin theme just to make these > changes, which is really not the best design. > > > > On Jan 13, 1:42 pm, jukea <[email protected]> wrote: > > Hi, > > > > I'm building a plugin to make fields of foreign tables available to > > lists (in doctrine generated admins) as any other parameter, so that > > sorting (this is > > working) & filtering on them is possible. > > > > Here's an example of an "extended" generator.yml my plugin would make > > possible : (for a schema as > > such : [User] 1....1 [Profile] 1.....n [Phonenumbers] ) > > > > config: > > fields: > > p.name: {label: name, path: Profile} > > n.number {label: phone number, path: Profile.PhoneNumbers} > > > > list: > > table_method: someMethodThatJoinsProfileAndPhoneNumbers > > display : field1, field2, p.name > > filter: > > display: field1, field2, n.number > > > > So the requirements are that > > > > 1) you have to name the foreign fields prefixed by their table alias > > > > 2) you have to specify the path to the table they're located into. > > e.g : enumeration of tables along the path except the root table, > > separated by a dot > > > > In the actual implementation of symfony/doctrine admin lists , the > > query is built like this : > > > > 1) the filter form initiates the query and adds filtering parts > > 2) back into the controller, the sorting part is added > > 3) the pager gets passed the query > > 4) the pager applies table_method > > > > As the title suggests, the problem is that the code adding the sorting > > and the filtering part is done before table_method is used, so they're > > not given access to the joined table fields > > > > I created the following ticket that describes the problem : > http://trac.symfony-project.org/ticket/5586 > > > > Also, table_method is local to the list context, which is a problem, > > because the filter would need it too. > > > > My solution is : I developped a new theme for the filter form > > generator in which BaseFormFilterDoctrine overrides buildQuery so that > > it gets passed the table_method, if any, and applies it right after > > creating the query, so tables are joind from at the beginning. > > > > I feel all this might be hacky, so my question is : in the long term, > > what would be the right way of doing that ? > > > > * Bonus question : how can I make my new form filter theme active for > > the admin generation ? > > > > thanks for your help! > > > -- Jonathan H. Wage Open Source Software Developer & Evangelist http://www.jwage.com http://www.doctrine-project.org http://www.symfony-project.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
