Each technical point in the development process of the Octopus series -- make a record here, octopus --

Each technical point in the development process of the Octopus series -- make a record here, octopus --

Custom page cycle

A unique global static VelocityEngine instance is used to optimize the creation of a VelocityEngine Instance Object for each request in a small Loach blog, reducing the object overhead.

You can use UA to determine the device from which the request is sent and initialize different template directories to display different page effects through mobile phone and PC Access.

Lifecycle of a request

Parameter initialization Page_Init:

Initialize the request context object

Request object

Cookie object

Currency object

Language object

Initialize the currency to execute the business logic and write it to the client's Cookie.

 

Authenticate_User

Page pre-load Page_PreLoad: some public data will be loaded, such as: image URL address, advertising image address...; loading Language Pack data; determining the number of Form parameters triggers Post events

Page loading event Page_Load: it must be left to each subpage for implementation. It is mainly used to complete service processing and data acquisition and filling in subpages.

Page pre-end event Page_PreEnd: not processed yet

Page end event Page_End: merge template and business data

This. pcMobile [initialization when determining the request] + this. templateFile [initialization when the Page_Load event is rewritten on each subpage]

Implementation of user verification Logic

Use the virtual protected virtual void Authenticate_User () to rewrite the quilt class, so as to implement background management programs, such as pages in the member center, which can be accessed only after the user logs on.

It is determined that the user login is implemented by checking the user objects logged in the session, and the problem of anonymous user login is also solved later.

Product Price-multi-currency implementation

Multi-currency data belongs to the custom data of each visitor. Therefore, it cannot be stored in the Application. It should be stored in cookies or sessions.

Octopus is implemented using cookies.

Prevent Entity from taking on too much business logic

In the process of writing, it has been a long time for the currency Cookie problem. The product price calculation requires that the product object can be carried out only after obtaining the currency object.

At first, I read the Cookie value in Entity to obtain the currency object. Later I found that this was not good.

First, the cookie cannot be read when each product object is created.

Second, there are too many business processing logic in the ProductInfo entity

In addition, it seems that there should be no access Cookie or other code in entity,

Later improvements were made to transfer this part of code to the business layer, receive the CurrencyInfo object in the business layer, and initialize the properties of the ProductInfo object. This solved this problem.

At the same time, the cookie reading is transferred to the Page_Load of the presentation layer, and instead of directly accessing the cookie, the currency symbol is obtained in the data context container to obtain the currency object.

This is a successful code upgrade.

Multi-language paging Style

Paging styles are also an important issue. Octopus considers multiple languages, and paging styles are also diverse.

In general, the implementation is to encode and generate HTML code snippets of A pagination bar, and then implement pagination with CSS styles. I refer to the Code in DTCMS to learn more.

I still feel good, and DTCMS uses the dual-top paging algorithm, which is more efficient.

This is a way of thinking. Octopus is implemented in this way.

The second approach is to templated paging entries and there are also ready-made Code. However, I didn't use this method, which is a bit complicated, but the style's definability is very high.

The processing of paging styles is the same as the processing of infinite classification described later. Octopus uses the NV template engine, so we need to consider the NV engine in implementation.

After the idea is finished, we still need to make some improvements. The first idea above helped me implement the paging algorithm problem. This solved it.

How does one change the page entries during multi-language switching? To interact with the data defined in the Language Pack

For example: homepage [Chinese] --- First [English]

I added a params string [] langPage type parameter to the OutPageList algorithm that generates paging entries, and replaced fixed characters with passed parameters.

At the cost of some style flexibility, you need to read data such as the previous page and the last page of the defined homepage from the data context of the NV engine during the call.

Note: In the Page pre-loading event of the Page cycle, we load the data of the Language Pack. [This part still needs to be optimized and the data needs to be cached]

In this way, the problem of paging entries in multiple languages is also solved.

Unlimited Classification

Unlimited classification is the first problem to be solved. It also takes a long time,

There are two difficulties

First, how to design an infinite classification information table and how to store infinitely classified data

Second, Octopus uses the NV engine, and the display style of product categories is ever-changing. How can I write such code in the NV template?

Let's start with the first question. In table design, we all know that there is a Parentid field to identify the parent category ID of the current category, and there will be some additional fields.

ClassPath: record the category navigation path [A classification ID separated by commas] ClassLayer [node depth]. You can study the design in DTCMS.

I basically refer to it.

There is also a design scheme called the unlimited classification of left and right values, which is explained on the Internet. However, I have not studied it clearly and cannot use it. Basically, let's look at these two types. How can we choose them?

The following key question: If all categories are read and displayed on the NV engine? --- There will be

Shopping Cart implementation

Provides centralized implementation

Idea 1: implemented through the built-in OnPost custom Post Mechanism

The internal trigger mechanism is: triggered by the number of request parameters.

            if (_Request.Form.Count > 0)            {                OnPost();            }

This method is used to process the Page Submission mechanism.

Two methods are used to differentiate different types of requests initiated by the page.

1. Use the "successful control implementation"

2. determine the type of the hidden domain through "hd_action"

However, this method has a problem: when you right-click "reload", you will be prompted to submit the form again.

There are two ways to solve this problem: 1. use the $ {reload} js Code to respond to the client. Once the user triggers the post event on the page, the server responds to a js script to the client and initiates a new request on the client.

In this way, there will be no duplicate form prompts. 2. Later I found that I don't need to do this: Use Context. Response. Redirect (Request. RawUrl, true); reload the page once.

Action: update, or delete, directly allows the client to redirect to a new URL to initiate a request. With fiddler, you can find that each action is first performed with 302 http code, then 200

 

 

Both methods can solve this problem.

The js method is a little slower, because the post action executes the Page_Load cycle of the page more than once.

Advantage: You can add any number of form tags to any bucket. aspx has only one tag.

You can use the submit and image labels to submit a form, or use a custom function to call the submit () function of the form to submit the form.

The other is that it doesn't apply to the damn script. You don't need to debug it. Haha, as long as there is a form, you can simply commit it.

Disadvantage: as long as the object interacts with the server, there must be a form tag and many hidden tags are used.

Method 2: Use the foreground script

As mentioned above, the implementation of the previous method is inseparable from the form mark. If we do not need the form mark, and sometimes we need the get method to submit it, what should we do?

So we can only implement it through script.

First of all: how to store custom data, the form uses the den mark to store custom data. Method 2: Use data-* to customize the properties of the instrument

Store all the parameter data used in a request in data-* and obtain them one by one through jq and js. the serialize (); method is convenient [write a similar method later to implement data-* batch acquisition]

Now, the preparation is complete. The next step is to initiate the request. You can use the ajax request configuration package common. js and Lee auxiliary scripts.

By the way, refresh and say, "If the request succeeds, it will be executed]

Train of Thought 3: Use ajax + templates [the name has not been prepared yet. temporarily come here ];