I’ve found many of my tables are structured in pairs consisting of a
primary_table whose entries are classified against a corresponding
table of table_types.
I have structured table_type to be hierarchically with a self-
referential parent_id so that the top is ALL (0), whose children form
the second level are GROUPS under which all categories are referenced.
For example if I have a table of contacts who are grouped as, TRADES,
SERVICES, APARTMENT, etc..
Then the children under APARTMENT may be ‘tenants’, ‘owners’,
‘managers’, ‘operators’ etc..
Is there a dynamic way to list the entries of the primary_table with
respect to ‘ALL’ or any of their associated ‘GROUPs’?
> I've found many of my tables are structured in pairs consisting of a > primary_table whose entries are classified against a corresponding > table of table_types. > I have structured table_type to be hierarchically with a self- > referential parent_id so that the top is ALL (0), whose children form > the second level are GROUPS under which all categories are referenced. > For example if I have a table of contacts who are grouped as, TRADES, > SERVICES, APARTMENT, etc.. > Then the children under APARTMENT may be 'tenants', 'owners', > 'managers', 'operators' etc..
> Is there a dynamic way to list the entries of the primary_table with > respect to 'ALL' or any of their associated 'GROUPs'?
Thanks Gerald for the pointers. I’ve never been a great fan of these
frameworks. I’ve tried a few, hobo, streamlined, etc.. in the past but
have always been frustrated with the code bloat and there’s always
variations that seem impossible to implement. I would prefer to code
these filters manually.
If I broke the problem into 2 stages,
1. if I created a constant array of link_to fields, ‘ALL, TRADES,
SERVICES, APARTMENT, etc..’, which would be used in a:
contacts = Contact.find (:all, conditions => [“contact_type, LIKE ?”
@contact+’%’])
Then I need filter only those contacts whose contact_types are
children of the selected link_to field?
Haven’t worked out all the details, copied this from a RailsSpace
example.
Thanks in advance
Gerhard
On Dec 20, 7:32 pm, "Gerald Bauer" <ger...@vanbeta.com> wrote:
> > I've found many of my tables are structured in pairs consisting of a
> > primary_table whose entries are classified against a corresponding
> > table of table_types.
> > I have structured table_type to be hierarchically with a self-
> > referential parent_id so that the top is ALL (0), whose children form
> > the second level are GROUPS under which all categories are referenced.
> > For example if I have a table of contacts who are grouped as, TRADES,
> > SERVICES, APARTMENT, etc..
> > Then the children under APARTMENT may be 'tenants', 'owners',
> > 'managers', 'operators' etc..
> > Is there a dynamic way to list the entries of the primary_table with
> > respect to 'ALL' or any of their associated 'GROUPs'?
> Thanks Gerald for the pointers. I've never been a great fan of these > frameworks. I've tried a few, hobo, streamlined, etc.. in the past but > have always been frustrated with the code bloat and there's always > variations that seem impossible to implement. I would prefer to code > these filters manually.
> If I broke the problem into 2 stages, > 1. if I created a constant array of link_to fields, 'ALL, TRADES, > SERVICES, APARTMENT, etc..', which would be used in a: > contacts = Contact.find (:all, conditions => ["contact_type, LIKE ?" > @contact+'%'])
> Then I need filter only those contacts whose contact_types are > children of the selected link_to field? > Haven't worked out all the details, copied this from a RailsSpace > example.
I see your point about ActiveScaffold. I'd say creating a filter is pretty much like adding search just w/ pre-defined search terms. To get started or inspired you might follow along the free Railscasts by Ryan Bates on search @ http://railscasts.com/episodes/111 or http://railscasts.com/episodes/37
Otherwise if you search (google) for Rails search you should find plenty of examples.
I'd suggest trying to simplify your type tables. If you know that you
aren't going to exceed a certain depth of categorization - and in your case,
I'm seeing a depth of two, my experience with SQL suggests you'll have an
easier time writing DB queries with something like the following:
*contact_types
*group_name string
category string
id
and
*contacts*
contact_type_id integer
contact_name string
other contact data
(one might even normalize further and add a table for groups, altering
contact_types to use a group_id instead.)
You would lose the ability to nicely assign someone to a ALL group - but
perhaps you can get around the constraint with naming of the contact_types
and groups.
Then, your list of contacts would either be:
Contact.find( :all )
If I've misunderstood, and you just need to alter the contacts shown
in-page, I've used css selectors in the past with success. For example,
each contact would be tr, and I'd give the row a css class for the groups
and contact-types the row is part of, like:
'<tr class='manager apartment'></tr>
<tr class='apartment electrician'></tr>
Then, a script to show or hide the data would be:
<script>
function hideByClassName( className )
{
$$('#containg-table-id tr.' + className).each( function(row){ row.hide();
On Sat, Dec 20, 2008 at 5:53 PM, schmii <schmi...@gmail.com> wrote:
> I've found many of my tables are structured in pairs consisting of a
> primary_table whose entries are classified against a corresponding
> table of table_types.
> I have structured table_type to be hierarchically with a self-
> referential parent_id so that the top is ALL (0), whose children form
> the second level are GROUPS under which all categories are referenced.
> For example if I have a table of contacts who are grouped as, TRADES,
> SERVICES, APARTMENT, etc..
> Then the children under APARTMENT may be 'tenants', 'owners',
> 'managers', 'operators' etc..
> Is there a dynamic way to list the entries of the primary_table with
> respect to 'ALL' or any of their associated 'GROUPs'?
Thanks Adam and Gerald for your suggestions.
Breaking it into separate tables would certainly make the SQL al lot
simpler.
I stole the original category hierarchy idea from the ‘photo album’
example in ‘Ruby on Rails: Up and Running’
I will have a look at the railscast and experiment with the code.
Thanks and a merry Christmas
Schmii
On Dec 22, 3:30 pm, "Adam Palmblad" <apalmb...@gmail.com> wrote:
> I'd suggest trying to simplify your type tables. If you know that you
> aren't going to exceed a certain depth of categorization - and in your case,
> I'm seeing a depth of two, my experience with SQL suggests you'll have an
> easier time writing DB queries with something like the following:
> *contact_types
> *group_name string
> category string
> id
> and
> *contacts*
> contact_type_id integer
> contact_name string
> other contact data
> (one might even normalize further and add a table for groups, altering
> contact_types to use a group_id instead.)
> You would lose the ability to nicely assign someone to a ALL group - but
> perhaps you can get around the constraint with naming of the contact_types
> and groups.
> Then, your list of contacts would either be:
> Contact.find( :all )
> If I've misunderstood, and you just need to alter the contacts shown
> in-page, I've used css selectors in the past with success. For example,
> each contact would be tr, and I'd give the row a css class for the groups
> and contact-types the row is part of, like:
> '<tr class='manager apartment'></tr>
> <tr class='apartment electrician'></tr>
> Then, a script to show or hide the data would be:
> <script>
> function hideByClassName( className )
> {
> $$('#containg-table-id tr.' + className).each( function(row){ row.hide();} );
> }
> On Sat, Dec 20, 2008 at 5:53 PM, schmii <schmi...@gmail.com> wrote:
> > I've found many of my tables are structured in pairs consisting of a
> > primary_table whose entries are classified against a corresponding
> > table of table_types.
> > I have structured table_type to be hierarchically with a self-
> > referential parent_id so that the top is ALL (0), whose children form
> > the second level are GROUPS under which all categories are referenced.
> > For example if I have a table of contacts who are grouped as, TRADES,
> > SERVICES, APARTMENT, etc..
> > Then the children under APARTMENT may be 'tenants', 'owners',
> > 'managers', 'operators' etc..
> > Is there a dynamic way to list the entries of the primary_table with
> > respect to 'ALL' or any of their associated 'GROUPs'?
|
