|
Wednesday 30 August 2006 2:41:01 pm
Hi OOzy I had a similar problem earlier on and could not find a really good solution. But there are the ideas I came up with:
1)Fetch all nodes sorting them both by client_type and name(or whatever you secondary sort option is). So the sort parameter would look somehow like this:
'sort_by', array( array( 'attribute', true(), 'clients/client_type ),
array( 'name', true())
Then you just need to display a heading each time the client_type changes and start your numbering of the listed clients again.
Advantage: easy to do
Disadvantage:
- does not work if you need custom sorting of the client_type,
- is problematic if you don't want to iterate though the entire array all at once
2) Fetch all nodes, push them in a multidimensional array which has the client_type as first key, e.g
$arr[$client_type][]=$node1
$arr[$client_type][]=$node2
Sort the array according to the order of your listing of the client types and iterate through it to display your nodes.
Problem: If you have lots of nodes, this will slow you system down considerably. This can be partially alleviated by not not storing the entire node but just the necessary data (often only the name and the url_alias). Still, this is suitable only for rather small sites.
3) Change the type of the client_type attribute to product category.
Advantage: You can fetch the product categories using a simple fetch ('shop', 'product_category_list'). Once you have the categories you can fetch the nodes for each category using an attribute filter.
Advantage: easy to do
Disadvantages:
- clients cannot have arbitrary client type, you have to add each client type to the product category before you can add the client object
- problems possible when changing or removing a client type 4) Make the client type an ezselection - which is roughly the same as 3)
5) Create a separate folder which will hold a dummy article for each client type.
Add a object relation to your client class and relate to the dummy article.
To display the listing, fetch all dummy articles and fetch the reverse_related_objects.
Advantage: still easy to do, no big problems when changing or removing a client_type
Disadvantage:
- not very intuitive
- still need to create client_type article before creating object
- no idea how much work it is for EZ to get the reverse related objects - might be slow Greetings from Luxembourg Claudia
|