You can run the tests included with the sfDoctrinePlugin in the test folder.
- Jon On Tue, Jan 13, 2009 at 1:45 PM, jukea <[email protected]> wrote: > > Also , if I patch the admin code templates, is there any test I should > code, before submitting a patch ? I found none for the generated > admins > > Julien > > On Jan 13, 2:29 pm, jukea <[email protected]> wrote: > > Jon, > > > > I think the filter forms should get passed the table_method with a > > setTableMethod, if any, in the same way the pager does. > > > > eg : > > > > $filterForm->setTableMethod(....) > > > > if there's no filter, then we'd still need to do it before the sorting > > criteria is added: > > > > $query=Doctrine::getTable('<?php echo $this->getModelClass() ?>')-> > > $table_method($query); > > > > So in generated admins, the pager would not be passed the > > table_method anymore, since it would always be applied to the query > > before it receives it. > > > > To sum it up : > > > > 1) add a setTableMethod to sfDoctrinFilterForm > > 2) change the action template to use it as described above > > > > What's the best way I can help ? Submit a patch ? > > > > Julien > > > > On Jan 13, 2:11 pm, Jonathan Wage <[email protected]> wrote: > > > > > 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 & > Evangelisthttp://www.jwage.comhttp://www.doctrine-project.orghttp://www.symfony... > > > -- 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 -~----------~----~----~----~------~----~------~--~---
