AnsweredAssumed Answered

Hierarchical portal sorting with product assemblies

Question asked by golife on Dec 29, 2015
Latest reply on Dec 30, 2015 by golife

I am referring to a previous question I had put some time ago - with very nice answers - and worked a lot on the solution. But at the moment, I would like to ask if there is any more experience with hierarchical sorting in portals where also the sorting order can be changed.

 

See also:

Re: Portal sorting problem moving detail records up or down

 

The problem is a bit more complex.

 

In portal the user should see different levels of products with calculated dimensions and prices for each product. One product can contain a number of other products. This makes a product assembly or Bill of Materials.

 

Products are configured in table PRODUCT, some without, some with items creating a Bill of Material (BOM). PRODUCT therefore can form an assembly of parts (products). The relationship is between PRODUCT -< BOM where in the BOM one id points to the parent PRODUCT, the other id points to the child product (called PART in my case).

 

Now, when the customer orders products, we want to not only show the PARENT product, but the whole list of subsequent depending parts. In ORDERDETAIL we can see the parent product on level 1 (or you could also define it as level 0) and dependent parts (level 2...n).


So far so good. Using a filtered portal, it is possible to show the full expanded version of all products with all their parts, or any hierarchy the user likes to see.

 

I start to have problems figuring out how to best sort products in portal sorting order while allowing to move products to any position.

 

If there was no portal sorting, products and parts would just appear as copied into the ORDERDETAIL. But since we want the user to also move products (at least products on the highest level) up and down (if not also parts within their level), it becomes not an easy task.

 

Using just the highest level 1, it is easy. But moving a product up or down requires to also move all it's dependent parts. Inserting or deleting a product on the highest level also means inserting and deleting all dependent parts. Showing or hiding levels of hierarchy also means renumbering not just the product on the highest level, but also dependent parts.

 

Parts are indented to also give a visual clue on the level of hierarchy.

 

Row numbers are simply 1...n. They do not reflect hierarchy. Ideally there is a hierarchical numbering such as 1.1, 1.1.1, 1.2, 1.2.1, etc. This would truly reflect a hierarchy of products and parts.

 

To illustrate using a simple example:

 

ORDERDETAIL EXAMPLE IN ORDER FORM

Row#  Hier.#  Name                   Level

--------------------------------------------------------

                                                          (Total price = Sum of 1 ... 2)

(1)      1        - Product A              1  (Price = Sum of 1.1 ... 1.3)

(2)      1.1     - Part A-A                  2

(3)      1.2     - Part A-B                  2

(4)      1.3     - Part A-C                  2

(5)      2        - Product B              1 (Price = Sum of 2.1 ... 2.3)

(6)      2.1     - Part B-A                  2

(7)      2.2     - Part B-B                  2

(8)      2.3     - Part B-C                  2 (Price = Sum of 2.3.1 ... 2.3.1)

(9)      2.3.1  - Part B-C-A              3

 

/* Now try to move Product B within the portal to position 1. It means, moving the rows 5-9 to become 1-5, and 1-4 to become 6-9 keeping the order between the product and its parts. Also the hierarchical numbering will just reverse. My solution idea so far is to hide all other levels > 1 and there will be only level 1 rows. I can move product B from then row 2 to row 1, and product A in row 1 to row 2. Then I must make sure to renumber all other row numbers and hierarchical numbers in ORDERDETAIL itself, and then I can expand the levels in the portals again. */

 

I am using even two "number" fields, one which reflects the current position (1...N) of each row, the other one reflecting a hierarchical order. But making sure both fields are updated correctly depending on whatever event may occur, and especially also keeping products and their parts together always, is a complicated scripting experience.

 

USE CASES

- User wants to move a product with all dependent parts to another position up or down (not lower than 1, not higher than max rows)

- User wants to delete a product (deleting all dependent parts)

- User wants to insert a product (inserting all dependent parts)

- User wants to add a part on any level of an existing product

- User wants to edit a part on any level of an existing product

- User wants to delete a part on any level of an existing product

- User wants to change an existing product (possibly changing parts, adding parts, removing parts)

- User wants to reorder parts within a product not breaking the boundaries of the level

- User wants to freely move any part to any product to any level

- User wants to move a selected group of products / parts to any position in the portal moving all grouped products and parts

 

The absolute dream would be to allow also drag-and-drop moving where solutions exist, but maybe such situation is less complex.


My question therefore: Is there any elegant way I am overlooking?

Any experiences?

Any more samples?

 

And I think this is not such an uncommon situation to present products in order detail forms in hierarchical order, one level containing another level, but allowing to move such groups from one to another position dynamically updating the sorting order within the hierarchies.

Outcomes