Processstore - Search component #46

[AlexanderLichtenegger]

resolves #46

added:

• Menu
  • Entry "Process Store"
• Components/Modules
  • ProcessStoreSearchComponent (uses test data at the moment)
  • ProcessStoreSearchModule
• Routings
  • "processstore-search" -> "ProcessStoreSearchComponent"
• Models (Angular)
  • ProcessStore (based on ProcessStoreDTO from active feature branch)
• Services (Angular)
  • ProcessStoreService (preparation, not in use at the moment)
• Pipes
  • SimpleSearchPipe
• NPM Dependencies
  • angular-star-rating
  • css-star-rating
• Static Assets
  • "star-rating.icons.svg"

[amarbajric]

In general your search component looks very promising to me. However, I have to mention some minor aspects:

• Are the initially shown "cards", where one card displays a process, the processes with the best rating or just randomly shown?
• Which filters have you planned to implement? Furthermore, why haven't you already implemented a filter option like searching for the creators firstName or userName of the process?
• How is the width and especially height calculated for every single "card"? is the hight dependent on the shown image? I suggest to show equally sized cards as we might need to discard the idea with the image because we simply wont provide images from the backend.

Other than that, I like the layout and the currently implemented functionality. Like mentioned before, it looks very promising.

ToDo: Please answer my questions mentioned above. After that, we will determine if we need some adaptations to the PR or if the PR can be accepted (initially of course) as long as the services in the backend are not implemented

[tortmann]

I definitely agree with @amarbajric that it looks promising.

Please explain your logic behind the current implementation as was also stated by @amarbajric comment.

• Are the initial cards listed alphabetically or randomly etc.?
• Which filter options are planned ?
• Which sorting options are planned ?

equally sized cards

definitely a good idea even with a potential image (which would then have to be resized)

average rating

should be calculated in the backend and provided via an endpoint or added to an existing one that provides data to the search component

window object

please shortly explain why you used this approach and change it to use the respective service of the project's microservice architecture. Thank you

[AlexanderLichtenegger]

Answers to the questions: • Cards: The cards are shown in the order as they come from the backend. • Filters: Three filters were added. “Price Below, Rating Above and Created By”. • Width/Height: The width is rendered dynamically. The height of the cards next to each other always have the equal size. • Images: The images were removed. • Sorting: Is not implemented yet. “Alphabetically, Rating High/Low and Price High/Low” could be used for the sorting. • Average Rating: Should come from the endpoint.

ToDos done: • Cards next to each other always have equal size • Filters added: "Price Below", "Rating Above", "Created By" • Images removed • Removed ProcessStoreService and used GatewayProvider instead

ToDos: • Average Rating received from Endpoint. • Input Validation for filters (filterInput is a string --> http://localhost:10000/api/store/processes?filterType=ratingAboveOrEquals&filterInput=abcde --> is possible) • Example Requests: o http://localhost:10000/api/store/processes?filterType=priceBelowOrEquals&filterInput=12 o http://localhost:10000/api/store/processes?filterType=ratingAboveOrEquals&filterInput=3.5 o http://localhost:10000/api/store/processes?filterType=createdBy&filterInput=tester2

[AlexanderLichtenegger]

processstore_testdata.sql.txt SQL-Dummy-File --> remove .txt from file

[amarbajric]

Review

• Looks very promising and in general the implementation is, at least from the visual perspective, good
• I do not agree with the filters and they need refactoring
  • Filtering should also be done at client side and not server side as this scenario allows for a perfect client side filtering without the need of numerous requests for every new application of a filter

ToDo

• Refactor and rework the filters

For now it is APPROVED BUT it needs some more work.