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