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!
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
