Differences

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

--- merkalt:business_process_of_application [2013/01/30 17:58] – 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. 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 instance 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