Differences

This shows you the differences between two versions of the page.

--- merkalt:business_process_of_application [2013/02/04 11:11] – dmitriy
+++ merkalt:business_process_of_application [2013/03/17 11:54] (current) – r dmitriy
@@ Line 1: / Line 1: @@
+render.js functionality
   - Load Instance setup
+    * load current 'main profile' settings Properties Review:
+        * affiliation trackers used
+        * text warnings on string length restriction.
+        * currency
+        * Cart related instance properties: enabling discounts, coupons, credit limits, email stubs.
     * load configuration for instance = profile (currency, motifs, colors, etc)  problems - Some of those properties are used inside the front-end order customizing. They are not intended to be different INSIDE one instance.   Properties Review:
-        * project identifier, color selector usage . The best solution for all properties below - re-assign properties to categories tabs instead of instance. Quick solution - reload config values on category tab change.
+        * project identifier, color selector usage.
-        * text warnings on string length restriction. Quick solution: use one property for all categories - merkalt.no root properties
+        * motifs tabs usage.
-        * Cart related instance properties: enabling discounts, coupons, credit limits, email stubs. Quick solution: use the same policy for all categories as for current instance - merkalt.no root
+        * rendering options
-        * motifs tabs usage. Quick solution - ignore this if we would use only categories with motifs tabs. Change motifs folder structure to allow usage of categories indepent categories. May be partially integrate new schema layout for this and retrieve motif settings. that is one of areas I am not very sure. We couldn't use same motifs controls for both tabs, but I need to make sure that motifs area could be generated and used with new schema. May be inclusion of motif as showing/hiding block in product area will help instead of current one motifs tab for all. What would be usability of such decision? The highest priority at the moment.
-        * rendering options - render label procedure. problem - this function is used to either render image with data or use pre-defined content (dorskilt, blekkpute). Quick solution - ignore this if we would use only categories with label generations.
     * load localization data - messages.xml
-    * load Products set. problems - we load products from the one instance at this time.** The best solution - keep Products table as global, use it as replacement of current xml. Quick solution - clone products.xml **
+    * load Products set The system load products from all used schemas at this time. Different products should have different product names
-    * load additional product options - colors, background colors, sizes used.** The best solution - assign options to products via table, use it as replacement of current xml. Quick solution - clone all needed xmls.**
+    * load additional product options - colors, background colors, sizes used.
     * load coupons / discounts schemas if they are enabled
     * setup available payments data
   - Operations with labels
-  - Order Processing
+  - Order Processing. Each order product is associated with certain instance with 'instanceId_[x]' hidden fields
-multitabs (categories) problems
-  - currently we have a list of labels for order indexed as 1, ..., n. This should be somehow saved as it is used for non - empty checkout before order process. Also this procedure should be modernized to use different profiles for checkout (solved partially)
-  - Label rendering uses currently only current profile. There should be support for multi-profiles usage (to be avoided with quick solution)
-  - products/orders to profile relations. Different instances have different setups of ordering data handling  (to be avoided with quick solution)
-  - coupons/discounts schema, Currently it only applies to the certain instance (to be avoided with quick solution)
-Suggestions
-The main problem is that current approach is instance-based. All logic is processed inside one instance. Multi-tabs process assumes that we have global setup with variations between instances. We have no such setup at this time. Global setup assumes at least such changes
-  - Linking of product to instance before the order
-  - Linking of order to instance before the order
-  - Ability to change profile "on-the-fly" with js AJAX
-  - Global schema for coupons