all data is live and searchable
|
Basic Assignments
|
Options & Settings
|
Main Time Information
|
||||||||||||||||||||||||||||||||||
|
|
|
Black
|
|
|||
|
|||
|
|
|
Notes:
|
|
This is a simple drawing of two different pieces that we use to help developers understand the servers and what they do. Part 1 - Client/Server Model This section helps show the flow of what happens as an outside client makes a web call or page request. The diagram shows clients (laptops, desktops, tablets, phones) connecting or requesting something from a normal web server through HTML (hyper text markup language). If the web server can handle it, the web server returns the request. This is called static HTML or a basic web site. If the normal web server does not know what to do, for example a ColdFusion page request, the web server hands it (the request) off to the ColdFusion server. Basically it is a please help me, I don't know what to do with this... The ColdFusion server than plays with all of its options and assets and returns the results in normal web language (html). The ColdFusion server is kinda like the brains of the process. It is very flexible and can deal with variables, conditional logic (if statements), loops, multiple sets of data coming from different sources, and even database and API connections. Very powerful. If the ColdFusion server needs database information or records, it uses an internal API (application programming interface) to get the data back to the ColdFusion server. This is the wall outlet looking piece of the diagram. ColdFusion (the brain) then talks to the database through a language called SQL or structured query language (database talk). The database responds and sends the information back to the internal API and then back to ColdFusion. The trip between ColdFusion, the internal API, and the database all happen very fast and possibly multiple times per page request. Think of those three pieces (ColdFusion, internal API, and the database) as the three musketeers. They work very well together. Most of the work in the system is done by bouncing between those three players. By the time everything is done, ColdFusion converts the values into normal web or HTML and sends it back to the normal web server that sends it back to the client. All of these connections are done in super fast, lighting quick phases so that it appears that only a single page was requested, processed, and returned. In reality, there are multiple different servers working in combination, each doing their own job, to make the whole. If you take any part of it out, the process would fail. Another fun part of the model deals with how an external API socket connection might take place. We, at adilas, allow access to backend database pieces based on settings and permissions set inside of the main secured environment. The external API is represented by the surge protector type piece that has sockets, data ports, and plug-ins. This section takes a standard piece or request and sends it to the internal API (wall socket in our diagram). The connection is made in a non native format like JSON (java script object notation) or XML (extensible markup language). This allows various 3rd party players or 3rd party solution providers to play with functions, data, and pieces of the adilas.biz business platform. Basically, they (the 3rd party players) are able to code in their native environments (other programming languages) and then request, pass, or pull data from our servers (logic and databases) using external API socket connections. See this help file for more information about the adilas.biz API. Part 2 - ColdFusion Structure & Scopes This diagram shows a large dresser with multiple predefined drawers. Think about both predefined and user-defined containers for storing values and data. We use this analogy to help new developers understand where things are stored and how to get pieces in and out of the application. The drawing has a number of predefined dresser drawers called structures (super variables with names and objects). Here is a list of the predefined structures and what are called scopes. 1. variables scope - Set on the page level. They only live on the page where they are created. This is the default scope. 2. URL scope - These values get passed in to a page via the web address field or URL. These values may be passed from page to page and allow dynamic access points from the web address or link bar. These values are often used to help speed up dynamics, templates, and quick dynamic page results. 3. FORM scope - These are values that get passed to a page from user interactions. FORM scope values often come from searches, reports, data fields, selections, filters, and other web form based options. The FORM scope is much bigger than the URL scope and should be used if size, quantity, and/or security options are needed. Technically, these values are virtually passed behind the scenes in page headers and page bodies. The normal public can't see these variable/value pairs without looking deeper into the underlying pieces. Think of the FORM scope like a giant hidden folder full of data that gets passed from page to page. The hidden folder is marked as private or don't show the values unless asked. 4. session scope - The session scope is set at the cloud or virtual memory level. This is great for storing things that need to last (timeframe) between page requests. These are things like logins, user settings, date ranges, shopping cart data, and other pieces that may be needed by one or more pages. As long as the user is interacting with the server, the session variables will continue until cleared or a preset time period (2 hours) of inactivity occur. Whichever is first. 5. application scope - These values are set when the server starts up and gets used for the first time. The application variables are at the site or server level. These variables and values can live on and on for days, weeks, months, etc. They are values and settings that are needed in multiple places in your site and/or application. 6. arguments scope - These values are used inside of methods, functions, or internal API socket connections. They must be passed in when calling and/or requesting methods or functions. Often arguments have requirements, defaults, and even data types (strings, numeric, dates, etc.). 7. attributes scope - These values are used inside of ColdFusion when making, using, and creating things called custom tags. The custom tags are usually some sort of action or routine that gets performed over and over again. The custom tags help the developers to code once and then use over and over again. 8. CGI Scope - These values are fairly techy and are created behind the scenes. This scope allows the developers to get at things like server paths, page names, IP addresses, and other http or web settings (hyper text transfer protocol). 9. Other Predefined Scopes - This entry is here to help the developers know that there are a number of other scopes that are specific to the task at hand. These include things like error scopes, cffile scopes, cfhttp scopes, and try/catch options. There are a number of other scopes that may be available. See the actual code and/or documentation for more information. |