I think your assumptions are wrong in this case, Tom. The way I understand
it, Jeremy has a rather large user table, where only a few of those users
meet a specific criteria (like is_artist, could also be is_staff, is_editor
etc). If he wants to filter articles submitted by a specific user, symfony's
default is to display a dropdown with a list of all the users. This list
could easily include several thousand users. I would not consider having
many users a design problem, but rather a sign of success. It would be
useful, however, to be able to filter on only a subset of those users. A
dropdown with 20 editors is certainly manageable. Another nice feature would
be to apply filter that would only show articles by users which meet a
specific criteria (for example only articles written by editors).
I also see the same kind of problem when working with many-to-many relations
and for example admin_check_list. Instead of displaying a list of possible
thousands of users, it would be more manageable to display only editors. A
simpler use case is a newspaper/magazine where all the the staff is the same
table, but some of them are writers, some are photographers and they are
either active or not active (which maps easily to sfGuardPlugin). When
assigning a photographer to a photo, there's no need to see the writers as
well.
I think the missing feature is to be able to assign peer_methods for filters
and many-to-many lists, and that this is thus a topic which belongs to the
dev-list (at least partially).
This should at least be considered for implementation in the reworked admin
generator.
-regards, Gunnar Lium
2008/8/19 Tom Boutell <[EMAIL PROTECTED]>
>
> If your app is "crashing out" when you have a lot of users, you should
> probably address why that is happening rather than hiding some of the
> users as a stopgap measure. The admin generator provides pagination,
> there is no reason why a large number of records should crash it.
> Hiding a problem like this is not a good idea because it is bound to
> come back and bite you later. You might be able to get help with your
> crashes on the symfony-users list... as I understand it your questions
> are more appropriate for that list than this one, because they don't
> have to do with improving, debugging or adding plugins to Symfony
> itself.
>
> Now, if you want to add a custom filter that is optional - the user
> makes a selection to enable the filtering - that's no problem. For a
> simple boolean attribute like the one you mention all you have to do
> is add the attribute name to the "filters:" setting for the list view
> in generator.yml. Easy as it gets. See Chapter 14 of the Symfony book.
>
> But it sounds like you want to apply the filter ALL the time, not
> optionally. You could do that pretty easily by overriding
> addFiltersCriteria() like this in your subclass of
> autoYourUserClassActions (substitute your class name of course):
>
> protected function addFiltersCriteria($c)
> {
> $c->add(YourUserClassPeer::IS_ARTIST, true);
> // Don't forget you want the regular filters too
> return parent::addFiltersCritreia($c);
> }
>
> As I said though, you should be looking at your underlying problems
> with handling many users and not relying on band-aids like this.
>
> --
> Tom Boutell
>
> www.punkave.com
> www.boutell.com
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
