Securing Enterprise Information Systems Applications
In EIS applications, components request a connection to an EIS resource. As part of this connection, the EIS can require a sign-on for the requester to access the resource. The application component provider has two choices for the design of the EIS sign-on:
Container-managed sign-on: The application component lets the container take the responsibility of configuring and managing the EIS sign-on. The container determines the user name and password for establishing a connection to an EIS instance. For more information, see Container-Managed Sign-On.
Component-managed sign-on: The application component code manages EIS sign-on by including code that performs the sign-on process to an EIS. For more information, see Component-Managed Sign-On.
You can also configure security for resource adapters. See Configuring Resource Adapter Security for more information.
Container-Managed Sign-On
In container-managed sign-on, an application component does not have to pass any sign-on security information to the getConnection() method. The security information is supplied by the container, as shown in the following example:
// Business method in an application component Context initctx = new InitialContext(); // Perform JNDI lookup to obtain a connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory)initctx.lookup( "java:comp/env/eis/MainframeCxFactory"); // Invoke factory to obtain a connection. The security // information is not passed in the getConnection method javax.resource.cci.Connection cx = cxf.getConnection(); ...
Component-Managed Sign-On
In component-managed sign-on, an application component is responsible for passing the needed sign-on security information to the resource to the getConnection method. For example, security information might be a user name and password, as shown here:
// Method in an application component Context initctx = new InitialContext(); // Perform JNDI lookup to obtain a connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory)initctx.lookup( "java:comp/env/eis/MainframeCxFactory"); // Get a new ConnectionSpec com.myeis.ConnectionSpecImpl properties = //.. // Invoke factory to obtain a connection properties.setUserName("..."); properties.setPassword("..."); javax.resource.cci.Connection cx = cxf.getConnection(properties); ...
Configuring Resource Adapter Security
A resource adapter is a system-level software component that typically implements network connectivity to an external resource manager. A resource adapter can extend the functionality of the Java EE platform either by implementing one of the Java EE standard service APIs, such as a JDBC driver, or by defining and implementing a resource adapter for a connector to an external application system. Resource adapters can also provide services that are entirely local, perhaps interacting with native resources. Resource adapters interface with the Java EE platform through the Java EE service provider interfaces (Java EE SPI). A resource adapter that uses the Java EE SPIs to attach to the Java EE platform will be able to work with all Java EE products.
To configure the security settings for a resource adapter, you need to edit the resource adapter descriptor file, ra.xml. Here is an example of the part of an ra.xml file that configures the following security properties for a resource adapter:
<authentication-mechanism> <authentication-mechanism-type> BasicPassword </authentication-mechanism-type> <credential-interface> javax.resource.spi.security.PasswordCredential </credential-interface> </authentication-mechanism> <reauthentication-support>false</reauthentication-support>
You can find out more about the options for configuring resource adapter security by reviewing as-install/lib/dtds/connector_1_0.dtd. You can configure the following elements in the resource adapter deployment descriptor file:
Authentication mechanisms: Use the authentication-mechanism element to specify an authentication mechanism supported by the resource adapter. This support is for the resource adapter, not for the underlying EIS instance.
There are two supported mechanism types:
BasicPassword, which supports the following interface:
javax.resource.spi.security.PasswordCredential
Kerbv5, which supports the following interface:
javax.resource.spi.security.GenericCredential
The GlassFish Server does not currently support this mechanism type.
Reauthentication support: Use the reauthentication-support element to specify whether the resource adapter implementation supports reauthentication of existing Managed-Connection instances. Options are true or false.
Security permissions: Use the security-permission element to specify a security permission that is required by the resource adapter code. Support for security permissions is optional and is not supported in the current release of the GlassFish Server. You can, however, manually update the server.policy file to add the relevant permissions for the resource adapter.
The security permissions listed in the deployment descriptor are different from those required by the default permission set as specified in the connector specification.
For more information on the implementation of the security permission specification, visit http://docs.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax.
In addition to specifying resource adapter security in the ra.xml file, you can create a security map for a connector connection pool to map an application principal or a user group to a back-end EIS principal. The security map is usually used if one or more EIS back-end principals are used to execute operations (on the EIS) initiated by various principals or user groups in the application.
To Map an Application Principal to EIS Principals
When using the GlassFish Server, you can use security maps to map the caller identity of the application (principal or user group) to a suitable EIS principal in container-managed transaction-based scenarios. When an application principal initiates a request to an EIS, the GlassFish Server first checks for an exact principal by using the security map defined for the connector connection pool to determine the mapped back-end EIS principal. If there is no exact match, the GlassFish Server uses the wildcard character specification, if any, to determine the mapped back-end EIS principal. Security maps are used when an application user needs to execute EIS operations that require to be executed as a specific identity in the EIS.
To work with security maps, use the Administration Console. From the Administration Console, follow these steps to get to the security maps page.
- In the navigation tree, expand the Resources node.
- Expand the Connectors node.
- Select the Connector Connection Pools node.
- On the Connector Connection Pools page, click the name of the connection pool for which you want to create a security map.
- Click the Security Maps tab.
- Click New to create a new security map for the connection pool.
- Type a name by which you will refer to the security map,
as well as the other required information.
Click the Help button for more information on the individual options.


Air is the gaseous substance around us. It’s made of 78% nitrogen, 21% oxygen, and 1% other substances. Everyone talks about how oxygen is important because it helps transport blood throughout our body, but nitrogen is just as important because our body parts need nitrogen to stay healthy. The 1% of substances in the air are called aerosols, which are solid or liquid particles that are in the air. Moreover, air also contains water. This is because the air around us can lose heat, causing water to condense into its liquid form. This is described as humidity; we would say the air is more humid when there are more water particles in them.
Wind, a moving air, surrounds us every day. The direction that the wind is coming in, or the strength of the wind, depends on its pressure. According to LeChatelier’s principle, a set of principles that scientists use to predict change based on certain stress on a chemical system, air molecules will move from areas of high pressure to areas of low pressure because the system wants to maintain equilibrium. For example, let's say you are sitting on a bench, and you feel a wind coming at you from your right. This means that the air pressure on your right is greater than the air pressure on your left. The power of the wind depends on the difference in pressure between the 2 points. Comparing the wind moving around you outside of your house, to the wind that’s gushing out of a balloon, and we can easily see that the difference in pressure determines the strength of the wind.
The change in air pressure can be caused by temperature, altitude, and moisture. Since air molecules in cold air are more compacted, cold air becomes denser than hot air. This means that cold air is higher in pressure and therefore moves toward hotter areas. Altitude also affects pressure because higher altitudes have fewer molecules, meaning it has less pressure. Moisture makes the molecules in the air less dense because water has less mass than oxygen and nitrogen molecules, which lowers the pressure as well.
Different types of atoms also affect the direction of the air. Some balloons can float up because the atoms of the gas inside the balloon are lighter than the atoms of the air outside of the balloon. Since the density of the gas inside of the balloon is greater than the density of the air outside of the balloon, the balloon will float up. The opposite happens when the atoms inside of the balloon are denser than the atoms outside of the balloon, making the balloon fall instead of float.


Information Flow Control Model for OSN
Add Data Manually
Change Parameters
TF
AUA
MF
FD
AUA
MF
FD
Upload JSON File
OSN Graph
Choose Presentation:


Sexting scandal MP quits election as wife stands against him
A former British government minister who resigned after sending lewd messages to two women has withdrawn from next month's election after his estranged wife was chosen to replace him.
Andrew Griffiths' wife Kate, who is divorcing him, was on Tuesday night chosen instead of him to fight the seat of Burton and Uttoxeter in central England for Prime Minister Boris Johnson's Conservatives, local party officials confirmed to AFP.
Griffiths on Tuesday apologised for his conduct adding that he had "sadly come to the decision that it is time for me to leave frontline politics", a report in the Guardian quoted him as saying.
Griffiths quit as minister for small businesses in July 2018 after the media revealed he had bombarded the two women with the unwanted messages.
He had wanted to stand again as Burton's MP in the December 12 election, but faced significant local opposition.
In a statement to the BBC on Wednesday, Kate Griffiths denied any collaboration with her husband over the seat, which the Conservatives held with 58 percent of the vote in the 2017 election.
"I left Andrew on the day that he told me about the behaviour that was published in the press," she said.
"I want to make it clear that I have not sought, nor do I accept Andrew's offer of political support."


Content Management System v1 Guide
DOCUMENT HISTORY
In conjunction with any changes made to this document during the life of this project, update the history log below to reflect its current status:
|
Version: |
Date: |
Changes Made: |
Last Updated By: |
|
1.0 |
2/3/2005 |
Initial Version |
R. Horn |
|
1.1 |
2/16/2005 |
Added Database Diagrams |
R. Horn |
TRADEMARKS
Other product names mentioned or acknowledged in this document, might be trademarks or registered trademarks of the respective companies.
TABLE OF CONTENTS
Purpose........................................................................................................................................... 7
Introduction..................................................................................................................................... 7
Scope............................................................................................................................................... 7
Overview......................................................................................................................................... 7
System Architecture....................................................................................................................... 8
Folder Structure.......................................................................................................................... 8
Subsystem Architecture.............................................................................................................. 9
Code Reuse Mechanism............................................................................................................ 9
User Authentication.................................................................................................................. 9
Subsystem Security................................................................................................................ 9
Functional Security............................................................................................................. 10
Content Security.................................................................................................................. 10
User Roles............................................................................................................................ 10
<IP_ADDRESS>.1 Admin Role...................................................................................................... 10
<IP_ADDRESS>.1.1 Serialization of the Admin Role................................................................... 11
<IP_ADDRESS>.1.2 Serialization of the Menu Editor.................................................................. 11
<IP_ADDRESS>.2 Release Manager Role..................................................................................... 11
<IP_ADDRESS>.2.1 Serialization of the Release Manager Role.................................................. 11
<IP_ADDRESS>.3 Security Manager Role..................................................................................... 12
<IP_ADDRESS>.3.1 Serialization of the Security Manager Role.................................................. 12
Database Architecture.............................................................................................................. 12
Development Database........................................................................................................... 12
Duplicate Parallel Database Tables.................................................................................... 12
ColdFusion’s view of the Duplicate Parallel Database Tables........................................... 13
Production Database.............................................................................................................. 13
Database Tables..................................................................................................................... 13
Development Database Tables............................................................................................... 14
Production Database Tables.................................................................................................. 14
T-SQL Scripts.......................................................................................................................... 15
T-SQL Error Handling......................................................................................................... 15
<IP_ADDRESS>.4 SBC Coding Guidelines Concerning Error Handling.......................................... 15
<IP_ADDRESS>.5 Adherence to SBC Coding Guidelines Concerning Error Handling..................... 16
Database Connections............................................................................................................ 16
<IP_ADDRESS>.6 Adherence to SBC Coding Guidelines Concerning Database Connections......... 16
<IP_ADDRESS>.7 Typical ColdFusion Apps and Database Connections....................................... 17
<IP_ADDRESS>.7.1 Cost/Benefit Analysis of Ignoring this SBC Coding Guideline...................... 17
<IP_ADDRESS>.8 Programmatically Violating SBC Coding Guidelines.......................................... 17
<IP_ADDRESS>.8.1 One Possible Scenario............................................................................... 18
<IP_ADDRESS>.8.2 How-To Programmatically Violate SBC Coding Guidelines........................ 18
<IP_ADDRESS>.8.3 How-To Programmatically Bypass SBC Coding Guidelines........................ 19
GUI Architecture....................................................................................................................... 19
The Menu Editor..................................................................................................................... 20
The Better Solution................................................................................................................. 20
Traditional Client-Server Architecture ?............................................................................ 20
<IP_ADDRESS>.9 Adherence to SBC Coding Guidelines ?........................................................... 20
<IP_ADDRESS>.10 Client-Server Performance Cost..................................................................... 21
Traditional Non-Client-Server Architecture ?.................................................................... 21
<IP_ADDRESS>.11 Design Trade-Offs......................................................................................... 21
System Extensibility.................................................................................................................. 22
Database Extensibility............................................................................................................ 22
Redundant Database Tables................................................................................................ 22
Brief word about Query of Queries..................................................................................... 23
<IP_ADDRESS>.12 Adherence to SBC Coding Guidelines............................................................ 23
System Design.............................................................................................................................. 24
Hierarchical System Chart....................................................................................................... 24
Client-Server JavaScript........................................................................................................ 24
Client-Server JavaScript Described.................................................................................... 25
SBC Coding Guidelines....................................................................................................... 25
Performance Considerations............................................................................................... 25
Complexity of Code............................................................................................................. 25
Self-Monitoring and Self-Tuning......................................................................................... 26
Benefits of Client-Server JavaScript................................................................................... 26
Client-Server JavaScript Code Library............................................................................... 26
Global Variables........................................................................................................................ 27
ColdFusion Global Variables................................................................................................. 27
ColdFusion Global Variables Defined................................................................................ 27
ColdFusion Global Variables Exceptions........................................................................... 27
JavaScript Global Variables................................................................................................... 27
JavaScript Global Variables Defined.................................................................................. 28
JavaScript Global Variables Exceptions............................................................................. 28
Global Variables and JavaScript Client-Server Programming Techniques........................... 28
Database Design....................................................................................................................... 29
Database Relationship Diagram............................................................................................. 29
Database Relationship Diagram Notes............................................................................... 29
<IP_ADDRESS>.13 Database Relationship Notes.......................................................................... 29
<IP_ADDRESS>.14 Central Table Notes....................................................................................... 29
<IP_ADDRESS>.15 Primary_Key Notes....................................................................................... 29
<IP_ADDRESS>.16 Foreign_Key Notes for releaseNumber.......................................................... 30
<IP_ADDRESS>.17 Foreign_Key Notes for uid............................................................................. 30
<IP_ADDRESS>.18 Foreign_Key Notes for pid............................................................................ 30
<IP_ADDRESS>.19 Foreign_Key Notes for sid............................................................................. 30
<IP_ADDRESS>.20 MarqueeScrollerData Table Notes................................................................. 30
<IP_ADDRESS>.21 DynamicLayoutSpecification Table Notes....................................................... 31
<IP_ADDRESS>.22 Redundant Content Table Notes..................................................................... 31
Figure 1 Database Table-Relationship Diagram................................................................. 32
<IP_ADDRESS>.23 Future Design for the DynamicHTMLTable.................................................... 32
<IP_ADDRESS>.23.1 Single-table Bill-Of-Materials Menu Data Model...................................... 32
Define and document the technology and products to used in implementing the PMProfessionalism Content Management System.
PMProfessionalism Content Management System provides the technical means to develop and deploy Intranet based web sites such as the PMProfessionalism site in a timely manner with little overhead and minimal programming expertise. Some aspects of the System Guide may resemble some aspects of the User Guide in terms of describing how the system works; this was unintentional as it is a requirement for those who work on the system’s code to understand how the system works.
This document identifies and describes the software system upon which the PMProfessionalism Content Management System was based.
Requirements driving this project were communicated verbally at a fairly high-level. The primary requirement was that non-technical people be able to manage their web content with minimal programmer or I.T. support in accordance with the SCM Policies and Procedures for SBC.
|
This is the folder structure for the Content Management System as it would typically be deployed for a single site configuration. This same code could be packaged to be deployed in a manner that would lend itself to being maintained at a lower cost in terms of how updates are distributed. One way to deploy this code and reduce the maintenance cost would be to deploy the code to a shared folder with the necessary “hooks” to allow the code to be executed in this manner and then the code would only need to be updated in a single location rather than many locations.
The root for the site is, in this case, is “pmprofessionalism” however the root folder could be any folder name and is identified to the system in the typical manner depending on which web server is being used.
There are four (4) subsystems for this system and they are, using no particular order, as follows: (a) Admin, (b) Layout, (c) Release and (d) Security.
There are three additional folders worth mentioning and they are as follows: (a) components, (b) images and (c) uploaded-images. The uploaded-images folder is created dynamically at run-time as-needed whenever an image file is uploaded to the server. The images folder contains all the static image content for the site. The components folder tree contains all the components for the site and support the functioning of the site at run-time.
The remaining folders are not part of the system and can be largely ignored for the purposes of understanding how the system is architected. The prodbackup folder was intended to be used as a backup in case the database was offline or otherwise unavailable however this folder could be removed with no loss of functionality. |
All of the subsystems, which includes 100% of the GUI, uses the same base ColdFusion code to maximize the reuse of code and minimize the coding maintenance effort. Maximizing code reuse however does tend to require slightly more code complexity than if reuse were not a consideration.
Code reuse is achieved by utilizing one central ColdFusion file from the root folder called “index.cfm”. Each of the subsystems then in-turn create their own contexts prior to performing a <cfinclude> that references the root index.cfm file. This technique allows each subsystem to be handled differently in terms of user authentication, this was a requirement, thus allowing a shared set of code to drive the site in a state-driven manner. Had this reuse technique not been used it would have become necessary to create no less than three nearly identical views of the site content (Live Site, Admin and Staging) which would then have been delivered through a reusable <cfinclude> file or via a .CFC (component) or some other technique that could have resulted in even more code complexity than is apparent at this time.
Users are authenticated at run-time through the use of LDAP. LDAP is an SBC provided system that requires a user to enter a username and password whenever a user attempts to access a web page located in an LDAP protected folder. LDAP provides two data elements to the ColdFusion code, one of which is the username and the other is the password; the password is ignored at run-time. The ColdFusion code make the assumption that the user must be authenticated IFF the username is provided and contains a series of non-whitespace characters. The username provided is then used to determine which subsystems the user is allowed to use other than the Security subsystem which uses only LDAP as a means of controlling access; there is no other way to deny access to the Security subsystem other than to deny access via LDAP whereas the other subsystems are controlled via LDAP in addition to settings stored via the Security subsystem.
In addition to subsystem security there is also the need to grant or deny access to certain functions such as the ability to Add New Pages of Content which also grants access to the Menu Editor among others.
In addition to subsystem security and functional security there is also the need to grant or deny access to individual pages of content such as those that are provided by the system and those that are provided by end-users in the form of editable HTML content. No distinction is made between system provided content pages and end-user provided content pages in terms of determining which users may access either when it comes to editing rights. From the Content Management System’s perspective all pages of content that are editable are subject to security settings as established by the Security subsystem.
User Roles are established by the functionality (which subsystems can a user use), the functional security settings and the content page security settings. There is no other formalization of “Roles” and therefore no formalized way to determine what “Role” a user plays at run-time. It was simply faster to develop this system without the formalization of roles and in the final analysis any formalization of roles would have been redundant in actual use and may have required a common GUI through which all users would play their role which might have given rise to far more code complexity than may have been desired. This informal determination of user roles also provides for greater end-user security because end-users are not faced with knowing about subsystems or functions that cannot access; inaccessible subsystems or inaccessible functions are not shown to the end-user at run-time.
The Admin Role is also known as the Content Management Role and is used to maintain content for the site. Any user who has been granted access to the Admin subsystem via the Security subsystem and has access via LDAP can play the role of Content Manager. A Content Manager can typically edit pages of content but not add new pages of content unless that same user has been granted the specific access to the function that allows new pages of content to be added which also includes the ability to edit the menu. Any pages of content that are added using the appropriate function will automatically inherit the security settings of the user who added the page. In other words, all pages added by Sam are automatically made accessible to Sam without the need for any other actions to be taken by the Security Manager.
One or more users can play the role of Content Manager as long as they are not all being granted the ability to edit the same pages of content at the same time. The system takes no actions to serialize access to editable pages of content which means if more than one user edits the same page of content at the same time the user who last hit the save button will overwrite the user who first hit the save button and in the extreme case the page of content could become corrupt. Additionally the database makes no attempt to utilize transaction processing nor does it serialize access to database tables which typically poses no problems for the database unless more than one user attempts to edit the same page of content at the same time.
Access to the menu editor is serialized and marshaled by the database in order to avoid as possibility of data becoming corrupt by more than one user editing the menu at the same time.
The Release Manager Role is responsible for controlling the “state” of a Release through the lifecycle of a Release. Any user who has been granted access to the Release subsystem via the Security subsystem and has access via LDAP can play the role of Release Manager.
Only one user can play the role of Release Manager at a time. The system takes absolutely no actions to serialize access to a Release which means if more than one user attempts to change the “state” of the same Release at the same time the user who last hit the commit button will overwrite the user who first hit the commit button and in the extreme case the “state” of the Release could become corrupt and unusable. Additionally the database makes no attempt to utilize transaction processing nor does it serialize access to database tables which typically poses no problems for the database unless more than one user attempts to change the “state” of a Release at the same time.
The Security Manager Role is responsible for controlling the “accessibility” of content within a Draft Release. Any user who has been granted access to the Security subsystem via LDAP can play the role of Security Manager.
Only one user can play the role of Security Manager at a time. The system takes absolutely no actions to serialize access to the Security Settings for a Draft Release which means if more than one user attempts to change security settings for the same Draft Release at the same time the user who last hit the save button will overwrite the user who first hit the save button and in the extreme case the security settings of the Release could become corrupt and unusable. Additionally the database makes no attempt to utilize transaction processing nor does it serialize access to database tables which typically poses no problems for the database unless more than one user attempts to change security settings of a Draft Release at the same time.
Discussions about the database need to be split between the Development database and the Production database.
The Development database that was used for this project was originally hosted on a SQL Server that was shared between Development and Staging. During the development cycle of this project however the need arose to allow the Staging server to be used for parallel testing efforts while the development database was being used for development efforts. This requirement gave rise to a set of problems that would have required the development SQL Server to be hosted separate from the staging SQL Server because had both efforts used the same database both efforts would have been changing “state” in the database for the same data objects and this would have caused an unacceptable level of chaos for both efforts.
Because both development and staging had to be useful at the same time it became necessary to create a duplicate set of database tables (one for one) because it was not possible to get a separate SQL Server database for staging testing efforts. Each of the database tables that was owned by “dbo” was duplicated and owned by “[ITSERVICES\ps6473]” and post-ended with the number “2”, for lack of a better mechanism. The naming convention used for the duplicate set could have taken on any usable form however the one used seemed to be easier to discern than merely looking for a slight different between table names during development.
Because this duplicate set of database tables had to exist in parallel with each other the need arose within the ColdFusion code to somehow allow one set to be used for development and the other set to be used for staging testing. The way this was handled and managed grew out of the fact that SBC sets a ColdFusion variable to define which environment the code in running in such that it was possible to use one set of tables during development and the other set during staging testing. This meant there would be no Stored Procedures for this project and all SQL statements (T-SQL Scripts) would be dynamically created at run-time by the ColdFusion server but the problem was solved and all parties were happy.
The production database contains only one set of database tables which are owned by “dbo”.
You may notice in the following diagram that there is a table missing in Production from the list of tables in Development and this is because the missing table was never published to Production. At one point work was being done on a Layout subsystem that provided a GUI interface until it was determined the effort would take far too long and that work was abandoned in favor of a faster and easier to develop albeit less easy to use for end-users Layout subsystem as it exists at the time of this writing.
Development Database Tables
|
Production Database Tables
|
T-SQL also known as Transact SQL is the language of SQL Server 2000. T-SQL Scripts for this project were designed to be monolithic T-SQL Script in order to reduce the number of <CFQUERY> invocations to a minimum rather than the more typical case in which rather small SQL Statements are used with no regard to the number of <CFQUERY> invocations used. The former requires a fair amount of programmatic logic to support the processing that runs in the database engine while the latter allows for a more forgiving architecture in which database problems are handled programmatically in a much more graceful manner than might be allowed within a T-SQL Script.
SQL Server 2000 does not provide the means to trap and handle errors that occur while a T-SQL Script is being executed at run-time. It is possible to determine error codes however errors such as syntax errors will simply cause the whole script to cease execution with no way to recover from the problem other than to blindly assume the T-SQL Script works once it reaches a workable state during development and testing.
SBC Coding Guidelines states the following:
|
Using CTRY/CFCATCH to capture exceptions can be useful, however, it also hides errors from the ColdFusion Application log. This creates a situation in which the server administrators have NO means of determining where a problem may lie.
For instance, say that a particular database server is down. If a the ColdFusion templates that connect to this database has the cfquery statements wrapped within a CFTRY/CFCATCH, the server admin will have no way of knowing that this particular database is down. As requests come in to the server to use this application the cfquery statements will attempt to connect to the database. Each cfquery statement will wait up to its maximum time to obtain a connection. ColdFusion application server has a finite number of active running threads as well as a finite number of requests that can be queued. Say that the maximum number of running requests is set to 40. Every user who attempts to access this particular application will take away one of those threads. Normally the threads (hopefully) execute in few hundred milliseconds or less; freeing a thread for another process (or one in the queue). If requests executing for this application with the database that is down take at least 30 seconds for their cfquery ODBC connections to timeout; requests will not start and finish as quickly. This means that requests for this application as well as others on the server will start to accumulate the queue. Once the queue is filled users will begin to receive “Server Busy” errors. The web administrator should know about the condition at this point due to monitoring of ColdFusion, client complaints about speed, or the ColdFusion process actually crashing and requiring a restart. Although the web administrator will be able to acknowledge that there is a problem, he/she will not be able to pinpoint which site is causing the problem due to the masking of errors facilitated by CFTRY/CFCATCH. If the errors were logged in the Application.log where they should be, the web administrator would be able to contact the siteowners and alert the DBA of the problem.
If you are currently using CFTRY/CFCATCH to display custom error messages rather than the more cryptic default ColdFusion error messages, you can use CFERROR to obtain similar results. In fact using CFERROR to obtain these results requires far less development time. Rather than having to add CFTRY/CFCATCH clauses to each page; you can add a single CFERROR statement to your Application.cfm. |
The reason for this SBC Guideline is fairly straight-forward within the context of the typical ColdFusion application that must be Administered by the I.T. folks who have certain requirements.
The problem with this guideline is that a more complex application such as this Content Management System needs to be more robust that the typical end-user coded application and therefore there is a need to perform programmatic error handling in order to ensure the state of the database is consistent with the functions being performed by the end-user.
In a worse-case scenario it might become possible for the T-SQL Script(s) to fail to execute in a silent manner (other than the typical entries in the ColdFusion Server Logs) with almost no way to determine why a T-SQL Script failed if the failure was caused by a syntax error in which case SQL Server would simply cease the execution of the offending script which could lead to the loss of data or the loss of “state” within the database.
The SBC Guidelines concerning database connections and ColdFusion is as follows:
12) Avoid CFQUERY within a loop (CFLOOP or CFOUTPUT with the query attribute)
While this guideline doesn’t specifically state one should try to avoid using many <CFQUERY> invocations it does suggest one should try to code monolithic SQL Statements. This guideline does however suggest one should not code <CFQUERY> invocations within a loop however there are times when it is necessary to code this type of logic in order to achieve the desired results.
Strict adherence to the SBC Coding Guidelines concerning the use of <CFQUERY> invocations may result in rather large unwieldy T-SQL Script that are less efficient than the alternative methods for achieving the same goals.
The intent of this SBC Coding Guideline is to prompt casual programmers to give some thought to how they code their logic in relation to SQL Server queries however in actual practice there is little reason to red-flag every instance of a <CFQUERY> tag within a loop.
The typical way to handle this in a ColdFusion application is to code rather small SQL Statements that are executed using <CFQUERY> invocations while allowing the ColdFusion server to handle the programmatic logic required to manipulate the result sets.
Sometimes it is necessary to code <CFQUERY> tags within loops however when this is required it must be done otherwise alternate code would be created to attain better performance.
Even when a ColdFusion application is making many connections to a SQL Server via <CFQUERY> tags it is still possible to adjust a ColdFusion server to provide a longer time-out to a database connection which results in the connection remaining open to allow many calls to <CFQUERY> to execute without the need to create many actual database connections.
The cost of strict adherence to this SBC Coding Guideline might be huge monolithic T-SQL Scripts that hide some programmatic logic within the T-SQL Scripts that are then subject to the rules of execution for T-SQL Script as previously stated in this Guide.
The benefits of ignoring this SBC Coding Guideline might be more granular use of SQL Statements with little use of T-SQL logic and a greater ability to handle database errors such as syntax errors that might creek into the system during the post-production period when the code is being used by real end-users. Obviously it takes a certain amount of programming skill to use <CFQUERY> tags in this manner but when it works it works well and the results can be a robust application that can roll-with-the-punches more gracefully than allowed by SBC Coding Guidelines.
By now the casual reader is probably “crying foul” at the thought of doing this however there are times when it is necessary to produce ColdFusion code that can violate the SBC Coding Guidelines such as the following scenario:
Consider a database table that has a Primary Key Constraint. The application must insert records into this table. What happens when a user attempts to insert a record that attempts to violate the Primary Key Constraint by attempting to insert a duplicate record. The Primary Key Constraint causes the database to enforce uniqueness within a database table by disallowing duplicate records for those columns that have the Primary Key Constraint.
According to the SBC Coding Guidelines it is not permissible to code ColdFusion logic that can do anything about the SQL Error that is produced when a user attempts to violate a Primary Key Constraint by attempting to insert a duplicate record. So the typical SBC user, one assumes, would be faced with some kind of generic error page handler that might send an email to someone however the end-user would be unable to proceed to work with the system and might conclude the application is broken. In any case, this is not the type of SQL Error the I.T. folks need be concerned about because this is not in effect a real SQL Error it is however programmatic feedback to the end-user that indicates the data needs to be changed before it can be saved to the database.
It makes very little sense to code an application that fails to handle a simple Primary Key Constraint violation attempt and it can be quite frustrating for end-users to have to get help from someone just to find out their data needed to be changed in order for them to proceed with their work. The typical novice user might not even know they can hit the browser’s back button to get back to the page that caused the error and some browsers might fail to show the page that caused the error with the originally entered data intact. Additionally the ColdFusion code might be using Meta Tags that inhibit the caching of pages that are being generated dynamically which means the browser might not be able to show the previous page from the browser’s history.
The current, as of this writing, SiteMover CodeScanner does not look for forbidden tags that are coded within <CFSCRIPT> code blocks which can be placed within .CFC files or elsewhere.
One can code a <CFTRY> tag which is forbidden if one uses the variant of this tag that can reside within a <CFSCRIPT> code block. The actual details about “how” this is done can be found in numerous sources on the Internet via a Google Search or the like.
It is a fairly trivial matter to produce a code scanner that can look for a tag that looks like <CFTRY> but it is another matter entirely to produce a code scanner that can correctly detect the <CFSCRIPT> variation of this forbidden tag. Even if such a code scanner could be produced it would always be possible to create ColdFusion code that is created dynamically at run-time which is executed at run-time without code scanner’s ability to detect forbidden code constructs.
The typical ColdFusion programmer might not know how to write code that can effectively bypass the SBC code scanner and this document does not specifically state how to do so other than the abstract declaration that it can be done.
Nonetheless there are times when it is not only desirable to bypass some SBC Coding Guidelines but not doing so might allow code to be produced that fails to allow users to actually use the system without the need to seek help from someone who will simply tell them to try to save data that is not already in the database.
The other way to bypass SBC Coding Guidelines would be to produce far more complex code that would cost more to produce and test that would perform a sanity check on data in the database prior to performing a INSERT such as in the case of the Primary Key Constraint Violation.
Yes, it is possible to code a T-SQL Script that can check to see if the record with the Primary Key Constraint already exists in the table and then to not perform the INSERT which means no SQL Error condition is created and the problem can be handled silently in a graceful manner. It might only take NN extra minutes to produce the code every time this functionality is needed and ColdFusion code could be created to facilitate the process of having to programmatically check for the Primary Key Constraint Violation attempts whenever this logic might be needed. The Better Solution that takes very little programming effort by comparison is the one that uses the <CFTRY> logic to detect and handle the error condition.
There are many more non-fatal SQL Error conditions that should be handled without bothering the end-user or the I.T. Support Staff other than the Primary Key Constraint Violation condition. Foreign Key Constraints can behave in a similar manner if one attempts to delete data from tables out of sequence, granted this is a programming logic error unless the point of the application is to grant this level of control over the database contents to the end-user.
The GUI was originally produced from an HTML template of the PMProfessionalism site and consisted of traditional ColdFusion code without any JavaScript at all. There were few requirements other than “make the site’s content editable” and “give us an SCM process”. When the requirements drove the design down the path of requiring more than traditional means could provide the design took a sharp right-turn towards JavaScript because this was the only way available to provide the level of functionality the design team seemed to want.
One case in point is the Menu Editor which began life as a clumsy non-JavaScript interface that just could not provide the required functionality.
The Better Solution for the design might have been to code the system from the other side of the coin, to ignore the content and work from the desired solution back to the original content however doing so would have taken longer and cost more to produce with possibly better results.
Along the way additional tricks and techniques became apparent there just wasn’t sufficient time to roll into the system. Tricks that would allow JavaScript to access the database directly using a more traditional client-server architecture. This would allow for a more granular approach to the GUI that could have allowed for a more multi-user system rather than the requirement to serialize access to certain functions and subsystems. If JavaScript were able to access the database to determine the “state” of objects such as the Site Menu, the Menu could have been turned into a series of database objects that could have been edited directly which could have allowed multiple people to share in the process of editing the Menu with real-time live updates as each action was performed on the Menu objects in the database.
According to SBC Coding Guidelines, <CFQUERY> tags are not allowed within loops. A traditional client-server application requires the use of what is in essence <CFQUERY> tags within loops in order to simulate the binding of GUI elements to database objects such as is achievable when coding traditional Visual Basic applications.
Typically web applications exist in a “connectionless” world in which a connection to a database cannot be maintained over time. ColdFusion can mitigate this by providing what can appear to be “persistent” connections to the database. JavaScript can provide the means to maintain a connection to the database. When one user clicks on a button on a web page that causes an object in the database to change another user would then see the “state” of that object change and the GUI is updated to either disable a button or show the results of the “state” change in the database which could be an updated Menu.
What would be the performance cost of a bunch of users all constantly hitting the ColdFusion server in what appears to be the background from the end-users perspective ? Yes, there would be more network traffic using a client-server model along with more web server traffic and more database traffic and more activity going on behind the scenes. But, the application would also be more robust and easier to use and appear to be a more traditional client-server application that could allow more users to interact with data objects than would otherwise be possible.
Let’s consider the problem of allowing users to Edit the Site Menu for a typical web site using the traditional web based approach.
Every time any user wanted to change something in the Menu they would have to make a round-trip to the server and refresh their web page. This would be simply unacceptable to the typical end-user. Click on something then wait. Click on something else then wait. Click on another something then wait. Then click on the save button and wait.
The trade-off to all this clicking and waiting was to produce a traditional JavaScript interface that requires serialization of Menu Editor access but allows end-users to have a smoother Menu editing experience. This is how the Menu Editor was designed for this Content Management System. The client-server model being discussed in this Guide might have been a little less smooth than the free-flowing Menu Editor we have today but it would have been more multi-user friendly. Sending and receiving packets with a frequency of say 2 seconds per round-trip might have provided a sufficiently smooth user experience. Even with 1000 users all using the Menu Editor the traffic load would have been no more than 1000 connections to the database, no more than 500 transactions per second to the database and no more than 500 hits per second to the ColdFusion server. This amounts to the same level of traffic as a site that gets 1,800,000 hits per hour. Sounds like large numbers but well within the operational limits of most busy web servers and certainly within the operational limits of most busy database servers. How many minutes would 1000 users spend all editing their menus each day ? Probably not that many minutes and certainly not even close to an hour each. If performance became an issue the system could be coded to respond by increasing the delay between packet round trips however this could have been coded as part of the design to automatically adjust the delay based on server response times. The longer the delay became the longer the delay would be made until the expected delay was equal to the requested delay. It would be a trivial matter to create JavaScript code that could automatically adjust itself based on actual system performance such that the resulting code would tune itself to avoid flooding the server with too much traffic during peak load times.
The software and database for this CMS were not designed to be easily extended without the talents of a sufficiently skilled ColdFusion programmer and/or DBA. The code and the database, as delivered to Production on/about 02-14-2005, was hastily created without any real thought as to “how” either would be easily extended. On the other hand, a sufficiently skilled ColdFusion programmer who has in-depth knowledge of JavaScript 1.2 should have no real problems extending the current system to do anything that can be done. This is how the system was designed and implemented; constantly extending the base system to include new features using updated methods and techniques. The same can be said about the database; a sufficiently skilled DBA should have no problems extending the database to include newer features and functionality.
The current database needs to be reworked, somewhat, to remove some of the tables that became redundant over the life-cycle of the development of this system.
The table named “DynamicHTMLContent” could be made to handle the functionality of the following tables: DynamicHTMLsepg_section, DynamicHTMLsepg_links, DynamicHTMLright_side, DynamicHTMLmenu, DynamicHTMLfooter and DynamicHTMLpad.
Each of these tables performs the same identical functionality within the database for the system. At the time, however, it was easier to simply create another table and effectively “firewall” the code that used the other tables and move the development process along than to combine all the tables into a single table. Additionally, at the time, the goal was to try to limit the number of <CFQUERY> tag uses to as small a number as possible however doing so proved to be unwise.
The process of removing the redundant tables in favor of the DynamicHTMLContent table would be quite simple. A ColdFusion programmer who knows how to recode T-SQL Scripts could easily modify the T-SQL Scripts that use each of the redundant tables to use the DynamicHTMLContent table instead. A DBA would be needed to add a column to the DynamicHTMLContent table along the lines of a column named “contentType”. Because it is necessary to extract data for a typical site layout from all of these redundant tables a column named “contentType” would make this a bit easier but the same thing could be accomplished using only the pageId column from the DynamicHTMLContent table and the PageName column from the DynamicPageManagement table. An IN clause would then be needed to extract content from all the required content types from the one DynamicHTMLContent table however it might be easier to code a query that would extract all the data for a Release using the rid column and then use Query of Queries to extract the individual content elements from the bulk query.
In ColdFusion 6.1 MX it is possible to code a <CFQUERY> that uses a previously created Query data object in place of a Table name with the result being a no-performance-cost sub-query. Consider a query that returns a large result set that contains 20,000 rows of data. A <CFLOOP> could be coded in ColdFusion to process this huge result set however doing so might result in a performance problem. A Query of Queries could be coded to produce a smaller more precise result set that is based on the larger result set that contains 20,000 rows without the need to hit the database server. In fact, it would be possible to issue almost any number of Query of Queries against that same 20,000 row result set with nearly no cost in performance, within certain guidelines. The typical way to handle this in ColdFusion 6.1 MX would be to issue a cached <CFQUERY> to extract a fairly large result set using a fairly simple SQL Statement and then issue Query of Queries to extract more precise result sets from the large cached query all without the need to code cumbersome T-SQL Scripts thus providing the means to handle database errors within the application code with the benefit being a more robust system that is actually easier to maintain.
At the time the current SBC Coding Guidelines were written ColdFusion 6.1 MX was not in-use. The CodeScanner used by SiteMover cannot discern between the more typical but slower <CFQUERY> within a <CFLOOP> and the faster Query of Queries with a <CFLOOP> as both appear to be identical at the tag level; the only difference being the source table name for both queries. Therefore, gratuitous use of Query of Queries would appear to be a performance problem based solely on the SiteMover’s Report that might indicate problems with uses of <CFQUERY> within a <CFLOOP>. This is the case with this system.
The SBC Coding Guidelines should be brought up to date with current ColdFusion 6.1 MX techniques and the CodeScanner should be updated or ignored.
ColdFusion <=> Database
HTML
JavaScript <=> HTML
DHTML
DOM
Using the Hierarchical System Chart above you may notice (reading from top to bottom) that ColdFusion interacts with the Database to produce HTML content and JavaScript content; JavaScript content sometimes creates HTML content dynamically and there is some use of DHTML and DOM (Document Object Model).
The typical flow of control goes something like this: ColdFusion file named index.cfm is executed which then creates a mixture of HTML/JavaScript/DHTML with database queries mixed in during the execution of the ColdFusion code. After ColdFusion finishes the HTML/JavaScript/DHTML and DOM takes over and allows for user interaction until the user clicks a button or a link that fires off the ColdFusion server once again to save data and retrieve data from the database. DOM is typically used to directly manipulate HTML objects from JavaScript such as when a drop-down list box is being updated. DHTML is typically used to perform functions such as displaying the site menu which at this time is largely a DHTML object controlled entirely by the browser using a set of CSS definitions.
When this development effort originally began, the notion of being able to manipulate database objects directly using JavaScript was a pie-in-the-sky idea. It would have been a nice technique to use that could have possibly resolved some multi-user technical issues. However the realization of this concept was not understood until this effort was too near the end of the allowed time.
In short, Client-Server JavaScript provides the means for a static GUI to remain visible at all times meanwhile database accesses occur in the background with no break in the user experience to refresh the web page or otherwise post data to the server, or so it seems. JavaScript and DOM are used to create HTML content and otherwise control the user experience. HTML code can be downloaded from the server when doing so becomes appropriate. DHTML is used to create HTML content when downloading said content from the server poses technical problems or when doing so seems more advantageous.
Client-Server JavaScript might not be a violation of the working of the SBC Coding Guidelines but implementing this technique would require a relaxation of the Guideline that mentions how often or how many <CFQUERY> tags might be used.
Client-Server JavaScript might result in more traffic to the ColdFusion server farm and likewise it may result in more traffic to the database server farm but the benefits out-weigh the apparent cost in performance. In real terms, there are relatively few times when the JavaScript Client would be required to appear to go into a loop looking for updates from the Server. It might only be necessary to request the status of certain GUI objects from the server such as when a GUI object receives focus prior to the user being allowed to click on a GUI object to determine if the user-click is a valid action at the moment based on the state of that object in the database.
That sure does sound rather involved. But what if we wanted to design a Menu Editor, for instance, that a group of users could all use at the same time to share in the experience of editing the site menu? All the users who are viewing the Menu Editor would be able to see the same menu objects in the database. When User-A clicks on a menu prompt to begin editing the JavaScript Client would send a request to the server to attempt to flag that object as being in-use. If the object was already in-use User-A would be shown a change in the state of that object such as the object becomes disabled with some indication as to which user is using that object. If that object was not in-use then User-A is flagged as using it and all other users who attempt to request access will be shown the change in state for that object. This Client-Server architecture would require very little additional network traffic at run-time however it is not as dynamic as the architecture that allows for more traffic and greater feedback.
The Client-Server Model could be self-tuning in terms of how often each Client polls for data. As more Clients poll for data each Client could be made to sense this and increase the polling interval based on user feedback. If User-A wanted to have a more dynamic experience the polling interval might be reduced to cause the Client to show changes more rapidly. The Client could display a network activity indicator to show how many users are polling the servers in order to help the users have a smoother user experience without bogging down the servers too much.
Coding this type of self-monitoring and self-tuning Client-Server User Experience might require some additional development time but much of this effort would only need to be coded once. One of the artifacts the process of coding this application model would be a set of sub-programs and routines that could be used to create additional applications with less effort and the first effort.
The benefit of having this type of dynamic self-monitoring and self-tuning Client-Server User Experience would be more multi-user functionality than is possible without this type of application framework.
Many times during the development of a web application a programmer is called upon to create code that could have come from a Corporate Code Library. A Corporate Code Library might contain code that knows how to populate the GUI with a menu of buttons. This menu of buttons might have some known behaviors such as how the buttons are enabled and disabled. The actual logic a button click fires-off could be supplied at run-time but the core functionality would only need to be coded once and then reused many times.
The next logical step beyond making a Corporate Code Library would be to create a Corporate Code Generator which is also known as an Application Generator.
There are two distinct types of Global Variables that are defined by this system. ColdFusion Global Variables and JavaScript Global Variables.
ColdFusion Global Variables are primarily created in the application.cfm file however in real terms ColdFusion Global Variables can be created almost anywhere within any ColdFusion template.
ColdFusion Global Variables are defined as being any variable that is defined or created within a scope that allows the variable in question to exists as a Global with visibility from any ColdFusion template.
The exception to the rule in terms of how and when Global Variables are defined or created in ColdFusion where this system is concerned is the ColdFusion Component (.CFC) file which is named “CommonCode.CFC”. At the time of this writing, it was understood that variables that are created within the scope of a ColdFusion Component remain with this scope and are not visible outside this scope. This is how ColdFusion Component(s) are used within this system however whether or not variables that are created or defined within a given ColdFusion Component are visible outside the scope of the ColdFusion Component has not been verified and no effort has been expected to determine if this is the case or not. Likewise, variables created or defined within any ColdFusion Components are not typically used outside the scope in which they were created.
JavaScript Global Variables are primarily created or defined within certain JavaScript Modules that are used all subsystems via the code reuse techniques employed by this system.
JavaScript Global Variables are defined as those variables that are defined or created outside the scope of any functions or procedures such as those that are created or defined at the top of the typical JavaScript Module file or those variables that are created or defined inline such as those that provide behaviors for HTML Events such as the “onclick” event or the like.
The exception to the rule for JavaScript Global Variables are those variables that typically exist as ColdFusion Global Variables that are also defined as JavaScript Global Variables.
If JavaScript Client-Server programming techniques had been used for this system it would not have been necessary to create a bridge between ColdFusion and JavaScript in terms of creating Global Variables that exist in two places. JavaScript Client-Server programming techniques provides the means to directly manipulate data objects from a database directly in JavaScript through a ColdFusion Gateway Process.
JavaScript Client-Server programming techniques provide the means for directly manipulating data objects from a database directly within JavaScript without the need to manipulate or store those data objects in ColdFusion variables.
ColdFusion is used as a Gateway or conduit through which the data objects are transmitted directly to JavaScript for direct manipulation and processing.
JavaScript Client-Server programming techniques provides for a faster smoother user experience than the traditional ColdFusion programming techniques can offer. For instance, there is no need to perform a “post” from an HTML Form to the ColdFusion server whenever it becomes necessary for users to interact with the database. This means the user’s experience is not interrupted by having to wait for their browser page to refresh at the conclusion of the typical “post” operation.
JavaScript Client-Server programming techniques provides the means to maintain a much cleaner run-time environment because Global JavaScript Variables need only be defined in one .JS file which is loaded only once, when the page is refreshed.
There are a few simple rules used throughout the design process for the database for this system.
1). There are no relationships specified within the database itself. The typical method employed for conveying the notion of “Relationships” in a Relational Database is to use a series of Primary_Keys[1] and/or Foreign_Key[2] Relationships however the development cycle for this system was quite short so time was of the essence and it was determined because of this as little time as possible was spent on each aspect of the system and the database was no exception. Had the timeframe for the development phase been known in advance sufficient time could have been invested in performing a reasonable analysis to determine the database design however this was not the case and the database reflects this, for better or worse.
2). There is one central Table around which almost every other table has been anchored, namely the ReleaseManagement Table. As you can see in the diagram below, there are only three groups of tables in this database. Two groups have intra-group relationships and one inter-group relationship. One group of tables have no relationships to the other two groups and this was done by-design.
3). The releaseNumber column in the ReleaseManagement table is a Primary_Key however this was done to enforce uniqueness for the releaseNumber column because the releaseNumber needs to be a unique value in the database in order to maintain the meaning of this data entity. In every single case where there is a stated Primary_Key attribute the goal was to cause the database engine to enforce uniqueness for that specific data entity.
4). The id column in the ReleaseManagement table is used as a Foreign_Key where the column name rid is used. The columns named rid may be thought of as being the Release ID for a specific Release that has a humanly readable releaseNumber.
5). The id column in the UserSecurity table is used as a Foreign_Key where the column name uid is used. The columns named uid may be thought of as being the User ID for each instance of this data entity.
6). The id column in the ContentList table is used as a Foreign_Key where the column name pid is used. The columns named pid may be thought of as being the Page ID for each instance of this data entity.
7). The id column in the SecurityList table is used as a Foreign_Key where the column name sid is used. The columns named sid may be thought of as being the System ID for each instance of this data entity.
8). The MarqueeScrollerData table is not directly associated with any other tables because there was insufficient time to fully develop the GUI for the Marquee Announcements Editor to allow for the need to be able to gather Marquee data from other Releases while working with a Draft Release.
9). The DynamicLayoutSpecification table is an unused table using the current implementation of the system; this table was to be used with the GUI based Layout Subsystem before it was determined that this subsystem’s design as a GUI based component would take far too long to develop in favor of the easier to code Layout Spec Editor.
10). The following tables could have been combined into a single database table had sufficient development time been allocated for this task: DynamicHTMLContent, DynamicHTMLfooter, DynamicHTMLpad, DynamicHTMLright_side, DynamicHTMLsepg_links and DynamicHTMLsepg_section. The choice was made to “firewall” the process of coding each of the content types in order to reduce the chance that previously written code might be broken by code written later on during the development process.
11). The DynamicHTMLmenu table should have been split apart into a Bill-Of-Materials database table architecture to allow the Menu to be described as follows:
As you can see this table schema is far more elegant than the one employed in the current implementation of the CMS. All Menu data entities have some things in common such as a “prompt” that is displayed to the end-user. Some Menu data entities have a URL in the form of the “href” data element however sometimes this “href” is an external URL in the form of http://sitename.com/page-name/something or an internal reference to a Page of Content stored in the database. When a Menu data entity describes a parent menu node there will be no real value for the pid (parent id) however when a Menu data entity describes a child menu node there will be a value for the pid (parent id) that references the id of the parent’s node. When a Menu data entity describes a parent menu node there will be a real value for the cid (child id) that is the id of the child’s node. The rid references the Release’s ID from the ReleaseManagement table. The pageId references the Page of Content for the Menu and “yes” every content type such as the Menu is associated with a specific Page of Content in the DynamicPageManagement table. That’s all there is to a complete Bill-Of-Materials data model contained in a single table.
[1] Primary_Key relationships have been used to enforce uniqueness for those data entities that have this Relationship attribute.
[2] Foreign_Key relationships tend to cause the database engine to want certain data entities to be acted upon in certain orders when adding or removing data during development and this time could better be spent working on the code moreover than fighting with the database engine.


Why JavaScript?
The time, where JavaScript was a dangerous fiddle which can make live and browsing really hard is long gone. Today it has became a valuable Tool, which improves the usability of a webpage considerably.
This blog is completely realised with JavaScript. Only static content is provided by the server and JavaScript magically generates all the known interactivity of it – in your browser! This causes less stress on my server and your internet connection.
You can investigate the code of this page on Github. Everyone who knows a little of JavaScript can quickly find out that there is nothing "bad" on it. And even if there is something, nobody needs to be afraid in a modern Browser – as I already said: The time is long gone.


Currently in beta. Get VIP access!
- Craft collective tales from inspiring story prompts.
- Explore alternate endings. You control the story!
- Connect with other writers & avid fiction readers.
- Receive feedback to help hone & elevate your craft!
@MyFolktale:


BROKEN ARROW A film review by James Berardinelli Copyright 1996 James Berardinelli
RATING (0 TO 10): 7.5 Alternative Scale: *** out of ****
United States, 1996 U.S. Release Date: 2/9/96 (wide) Running Length: 1:48 MPAA Classification: R (Violence, profanity) Theatrical Aspect Ratio: 2.35:1
Cast: John Travolta, Christian Slater, Samantha Mathis, Delroy Lindo, Frank Whaley, Bob Gunton, Howie Long, Vondie Curtis-Hall, Kurtwood Smith Director: John Woo Producers: Bill Badalato, Mark Gordon, and Terence Chang Screenplay: Graham Yost Cinematography: Peter Levy Music: Hans Zimmer U.S. Distributor: Twentieth-Century Fox
By another name, BROKEN ARROW is SPEED gone nuclear. Yet, despite all the explosions, violence, special effects, and other choreographed excesses, this film doesn't have quite the same impact. It's fun, to be sure, and the wild ride doesn't let up for a moment, but the level of tension isn't quite as high. It probably has something to do with the premise -- after all, the threat of a nuclear holocaust isn't quite as unique an idea as a bus that will blow up if it decelerates below 50 mph.
According to the movie, a "broken arrow" is the military term for a lost nuclear weapon. Here, there are two, but they aren't really lost. Rather, they have been stolen by Air Force Major Vic Deakins (John Travolta at his most nasty). Vic thinks the military has done him a grave injustice by repeatedly passing him over for promotion, and he's out to get revenge. His demands are simple: $250 million or one major American city will be atomized.
The only two standing between Vic and a luxurious retirement are his ex-partner, Captain Riley Hale (Christian Slater), and a Utah park ranger, Terry Carmichael (Samantha Mathis). They hook up when Terry finds Riley after Vic ejects him from a stealth bomber. The rest of the film is a cat-and-mouse game, with Riley and Terry chasing Vic, or the other way around, depending on who has the missiles. There are all the requisite close calls and narrow escapes, but nothing quite as nerve- wracking as watching a bus thunder towards a gap in a freeway-under- construction.
The writer of BROKEN ARROW, Graham Yost, also wrote SPEED, which accounts for many of the similarities. Director John Woo, best known for Hong Kong action flicks like THE KILLER and HARD BOILED, is in his second Hollywood outing (his previous American film, HARD TARGET, was a Van Damme vehicle). Woo, whose inimitable style has earned him legions of fans across the world, seems very much at home in this high-tech arena. His characteristic trademarks, such as someone leaping through the air with guns blazing in both hands, are all in evidence. As always, Woo choreographs action like a ballet, creating some of the most artistic violence to be found anywhere.
After playing the protagonist in three straight films (PULP FICTION, GET SHORTY, WHITE MAN'S BURDEN), John Travolta finally gets a chance to try his hand at a despicable-to-the-core villain. And, boy, is he *cool*. Vic Deakins is one of the most delicious bad guys since Alan Rickman put on a fake German accent for DIE HARD. Vic, who loves "having the power of God at [his] fingertips," is smooth, heartless, and very dangerous.
Christian Slater, who plays a radically different role here than in his other current film, BED OF ROSES, is an adequate hero. His Riley doesn't have Vic's twisted charisma, but Slater musters enough screen presence to get us on his side. And, while it's nice to see him teamed up again with Samantha Mathis (the two previously joined forces in PUMP UP THE VOLUME), the two never really click. Mathis, who seems better suited to movies like LITTLE WOMEN, isn't an especially effective action star.
The preposterous thrills in BROKEN ARROW take the characters from a fight aboard a stealth bomber to a car chase across the flats of Utah to the bowels of a disused copper mine to a speeding train. The pace is relentless; Woo never allows the excitement to flag. In the end, BROKEN ARROW is an exhilarating, if empty, experience.  It won't be quite as satisfying as a SPEED or DIE HARD, but there's still enough here to leave anyone exhausted.
- James Berardinelli e-mail<EMAIL_ADDRESS><EMAIL_ADDRESS>web: http://www2.cybernex.net/~berardin
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


MURDER AT 1600 A film review by Walter Frith Copyright 1997 Walter Frith
Another conspiracy movie? Maybe. Plausible story? Yes. Entertaining? Definitely. For all the complaining people do about government (and a lot of it is justified), it's refreshing to see a movie that keeps those who think they are above the law within its boundaries. Maybe this only happens in the movies but it is a nice thought.
A murder has occurred at 1600 Pennsylvania Avenue (The White House, Washington, D.C.) and a homicide detective (Wesley Snipes) is assigned to investigate the crime and runs into stiff opposition from the head of White House Secret Service (Daniel Benzali) and is aided in his search for the truth by a conscience-stricken female Secret Service agent (Diane Lane). The President's national security advisor (Alan Alda) is also part of the intrigue as he resists any attempt to link the first family with the crime. Snipes is forced to investigate certain venues in secret which puts his life in danger and the movie takes many different turns before arriving at its conclusion which unfortunately isn't disguised too well and many film buffs will have the story figured out before the climax arrives.
That is about the only flaw keeping 'Murder at 1600' on the money at all times and is a taut and suspenseful thriller detailing not only the murder investigation but it also contains a sub plot which involves the White House dealing with a crisis of military hostages held overseas in Asia. It's also too bad that in every film dealing with suspicions at the highest levels of government, that those central figures remain as caricatures to the plotline and we never really get to know them as part of the film's central focus. It's true in this case with the President being portrayed by Ronnie Cox ('Deliverance', 'Beverly Hills Cop', 'Robocop', 'Total Recall') and was also the case in 1994's 'Clear and Present Danger' in which that film's President (Donald Moffat) was secondary to the story and 'Independence Day' which portrayed its President (Bill Pullman) rather poorly. Even the recent 'Absolute Power' failed to show its President (Gene Hackman) as anything more than a second rate characterization.
Wesley Snipes gives his best performance since 'White Men Can't Jump' (1992) in this picture which makes his character not only intelligent but determined to get at the truth. Its a deep portrayal from Snipes who has been so good and so focused on the characters he's played. 'Murder at 1600' is a step in the right direction for his career. It's also a film in which the entire cast figures prominently and delivers the goods.
OUT OF 5> * * * 1/2
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Easily copy roms you want, or remove roms you don't want, based on a CSV file listing the games you want to copy or remove. Copying from a romset assumes it matches your MAME version and is non-merged.


The Aims of The Club
The aims of TTC are as follows:
- To encourage the students at NCI witness and experience the beauty of playing Table Tennis.
- To develop NCI as the best College producing profesional and Amateur players in Ireland.
- Due to our experience as profesional table tennis players, we intend to pass on the knowledge to willing and promising to be players.
- To make participants realise that table tennis is a sport that accomodate every gender, sex and no age limit.
- To make it as a forum whereby all NCI students from different faculties can meet and interact.


Event Ideas
There are a ton of different types of events you can do in your Study Group. The most popular tend to be code-alongs, but don't be shy to add some variety with other, more open ended events, like the ones below - or come up with something completely new and different! The only rule is to try and include as many people as possible.
Work-Along
A hands-on guided tour of a piece of code, tool, or other skill.
Suggested length: 1 hour.Work-alongs are perhaps the most popular Study Group activities, where a demo leader plugs their laptop into a projector and shows how they use a particular piece of code, tool or other skill in their research, while everyone else follows along on their own machines. These are great opportunities to help your community discover new tools and see novel solutions to common problems, and a chance for the demo leader to practice teaching and presenting in a participatory, hands on class. A few tips for a good work-along:
- Keep it short. An hour is plenty long enough; more than this, and it becomes too much to absorb all at once.
- Keep it simple. That hour will go by really fast for the demo leader - sixty minutes is really only enough time to cover a few introductory ideas. Remember, there's no final exam; if people walk away with a successful first couple of steps on the topic, that's all they need to get started and learn more in future.
- Keep beginners on board. This means explicitly illustrating every step, and going slow enough for participants to copy down everything you're doing - so that everyone can follow along.
- No slides. Slides are boring. The presenter should live-demo all their examples, while everyone else follows along on their own machines.
- Give people challenge problems. If you're the presenter, don't talk the whole time - take a couple of breaks to let your students try their new skills on a challenge problem or mini-project. This also gives you the chance to answer questions, and make sure no one gets lost.
- Keep it real. Try and illustrate how you actually use the tool in your research; this way, everyone will understand not only how to use it, but why it's valuable in real practice.
- Encourage non-experts to lead. It is absolutely not required to know everything about a package or skill to lead a demo on it. Always invite participants to lead a future session, and remind them that it's more interesting and more authentic to see how they use the tool in question, than to see a more esoteric perspective.
- Post the lesson notes. It takes some work to prepare the notes for a lesson - instead of letting them disappear afterwards, put them in a GitHub repository and share them back with the community. See this example - lesson notes in a README.md file and extra data or examples alongside it in the repo is all that's needed. Once those are up, include a link from your Study Group's '/lessons' directory (like this), and let the Science Lab know so we can point to them from our collection of Study Group Lessons. If you're not comfortable with Markdown or GitHub, feel free to ask the Science Lab for help!
WIth that in mind, if you're thinking of running a code-along for your Study Group, open an issue in their repository descibing what you want to teach, and the organzers will help you book rooms & schedule the event.
Coworking Session
An open session to work on projects and ask each other questions.
Suggested length: 2 hours.Co-working sessions are a great way to get stuff done and discover new coding techniques. Get your Study Group together for a couple of hours to all sit down and work on their latest coding projects - and encourage everyone to ask each other questions when they get stuck, show off their work and talk to each other about what they're doing. To have a great co-working session, try these tips:
- Welcome beginners. Make sure everyone knows new coders are very welcome, and that it's okay to ask any question you like. Also, make sure the more experienced coders in the group know how to make newcomers feel welcome; treating anything like it's trivial is offputting for people just starting out. There is no such thing as a 'stupid question' in a Study Group.
- Do lightning intros. At the start of the session, go around the room and have everyone call out tweet-length descriptions of what sort of tools and language they're working in that day - and encourage people using similar tools to chat and work together.
- Have a demo party. At the end of the session, give people a chance to show off what they're working on to the group - these should be really quick demos, meant to give people just a flavor of what people are doing - and start conversations afterwards.
A variant on the coworking session is the strategy circle - invite people to describe a problem they're having, and then open the floor for suggestions on what kind of packages, tools or strategies they could try out to solve their problem. After everyone has had a turn to describe their problem and get some suggestions, open the time up to experiment with those new ideas and get help in open conversations with the group.
Hacky Hour
A pub night or cafe meeting for researchers who code.
Suggested length: flexible.A Hacky Hour is a great, informal way to open things up and encourage community members to meet one another, discuss new ideas, and build the social ties that help strengthen any community. They're also some of the easiest events to organize, since all that's required is an open cafe or pub! A few ideas on making a great Hacky Hour:
- Encourage lots of connections. Any time someone wants to meet to chat about a code project, needs help with a bug, or wants to find out more about what's happening in your community, invite them to Hacky Hour, so they can meet the community and find out first hand. Keep an eye out for people who might have some projects or interests in common, and help make connections.
- Choose the right venue. A pub or cafe at or near your institution, a little before the busy hours is best (3 or 4 PM Friday). This makes it convenient for everyone to get there and get a seat, and when it's a bit quieter, it's easier for people to have conversations and maybe even hack on a bug or two! When the weather is good, patios are great for this.
- Get together at a different time than your usual meetings. Hacky Hour's main purpose is to make your group available to newcomers who want to ask questions and meet people casually before coming to a more organized session; having a hacky hour outside your usual times will give new and differnent people the chance to come say hi.
- Make it obvious. Make sure it's easy for newcomers to identify who the Hacky Hour group is at the venue; funny hats can go a long way.
Coding Lightning Demos
An open house of short tool demos.
Suggested length: 1.5 hours for party-style, 1 hour for talk-style.A lightning demo is a short demo of a tool or piece of code, meant to make a quick introduction to an audience so they can decide if they're interested in learning more. Get a whole bunch of these together, and you have a Lightning Demo Party or Lightning Demo Series! Try these tips for your first round of lightning demos:
Demo Party
In a lightning demo party, lots of people get together in a science-fair type setting to mingle and get a glimpse of new tools and techniques they might like to dig into more in future.
- Aim for 8-10 demos. This is enough for there to be some substantial variety at the party, but small enough that it won't take hours for people to check out all the demos.
- 5 minutes max. Ask presenters to keep the demos short; there's plenty to see, and if there's lots of interest in one area, invite the presenter to lead a code-along at a future meetup.
- Include some research context. Getting the presenters to add a quick comment on how they use their demo in their research will help motivate the tools, and communicate to everyone what their research applications are.
- It's a party! Set your presenters up in a big horseshoe pattern so people can circulate, and consider serving snacks or drinks if feasible. Setting the scene this way will help encourage people to talk amongst themselves and brainstorm about how they're going to use all these cool new ideas.
 This is a great opportunity for new speakers to give presenting at Study Group a try; like the party format, encourage speakers to always add some research context so people know where and how the ideas presented are being used.
- Aim for about 4 demos. Switching between potentially wildly different ideas in a lecture format can get exhausting for the audience after more than an hour, so keep it tight - if you have more presenters than that, consider party-style, above!
- 15 minutes max. These lightning demos can be a bit longer, since the audience will be seated in this format.


{{site.social.github}}'s dev blog
{{site.social.github}}
{{site.profile.description}}Copyright © 2020 khyun-kim. Powered by Jekyll
{{ content }}
{% include head.html %}
Copyright © 2020 khyun-kim. Powered by Jekyll


CHAPTER 328K
SMOKING
REPEALED. L 2006, c 295, §3.
Cross References
For present provisions, see chapter 328J.


{% extends "base.html" %} {% block content %}
This page will allow an admin to search the Lore Entries database, the Clues database, and the Crisis Actions database for a single search term. Results will be presented on a single page. (That part might eventually need a redesign.)


Chapter 18. Multithreaded Programming
In this section, we will explore the different ways you can achieve more parallelism in your code by using the multithreaded (MT) programming features found in Python. We will begin by differentiating between processes and threads in the first few of sections of this chapter. We will then introduce the notion of multithreaded programming. (Those of you already familiar with MT programming can skip directly to Section 18.3.5.) The final sections of this chapter present some examples of how to use the threading and Queue modules to accomplish MT programming with Python. |


{{ site.title }} is a project to get a Linux shell environment running locally on your iOS device, using a usermode x86 emulator.
{{ site.title }} also runs on iPad, bringing a terminal to larger displays as well.
You can edit files with sed and cat, move them around, and more!
{{ site.title }}'s keyboard addition makes navigation easier.
Of course, let's get started!
You can become a patron if you would like support {{ site.title }}. Donations are very much appreciated, but will never be required; the app will always be completely free.
{{ site.github.latest_release.body }}
Latest pre-release: {{ prerelease.name }}
{{ post.date | date: "%Y-%m-%d" }} {{ post.title }}
{% endfor %}


Module forma.automata
Pattern manipulation with Cellular Automata.
Cellular Automata are defined here by a ruleset (a table of individual
CA rules). Each rule consists of two parts. Firstly a neighbourhood that
the rule acts on. Secondly a rule signature
specifying the conditions
under which cells are Born (B) or Survive (S). These rule signatures are
initialised with a string in the "Golly" format. i.e a rule which activates
cells with one neighbour and deactivates cells with two would have the rule
string "B1/S2". The neighbourhood is specified by an instance of the
forma.neighbourhood class as usual.
Once a ruleset is specified, there are two provided implementations of a CA. Firstly the standard synchronous CA is implemented in automata.iterate whereby all cells are updated simultaneously. Secondly an asynchronous update is provided in automata.async_iterate in which each iteration updates only one cell at random.
When a ruleset consists of only one rule, the CA is unambiguous and is applied in the conventional manner. When multiple rules are provided, rule conflicts are resolved in favour of cell deactivation. For example, if there are two rules in the set, cell activation requires that the candidate cell passes the 'birth' criterion of both rules. Cell deactivation requires only that one 'survive' criterion fails.
All CA updates here are only possible on a finite domain of cells. That domain must be specified as a pattern in the iteration call.
Both the synchronous and asynchronous iterations return the result of one CA iteration and a bool specifying whether or not the iteration has converged to a stable pattern.
Relevant examples
Ruleset Generation
| rule (neighbourhood, rule_string) | Define a cellular automata rule. |
CA Iteration
| iterate (prevp, domain, ruleset) | Synchronous cellular automata iteration. |
| async_iterate (prevp, domain, ruleset, rng) | Asynchronous cellular automata iteration. |
Ruleset Generation
- rule (neighbourhood, rule_string)
-
Define a cellular automata rule.
CA rules in forma are defined by a neighbourhood in the usual CA sense and
a string signature in the 'Golly' format (BXX/SXX). This function
initialises a rule, and performs a few consistency checks.
Parameters:
- neighbourhood specifying the neighbourhood the rule is to be applied in.
- rule_string string specifying the ruleset (i.e B23/S1).
Returns:
-
A verified rule for use with the CA methods.
Usage:
-- Initialise a rule corresponding to Conway's Game of Life local gol_rule = automata.rule(neighbourhood.moore(), "B3/S23")
CA Iteration
- iterate (prevp, domain, ruleset)
-
Synchronous cellular automata iteration.
Performs one standard synchronous CA update on pattern prevp in the specified domain.
Parameters:
- prevp the previous iteration of the pattern
- domain the cells in which the CA operates
- ruleset a table of forma.rules defining the CA
Returns:
- The result of the CA iteration [pattern].
- Convergence flag [bool: true if converged, false otherwise].
Usage:
-- Domain and initial state (500 seed points) for the CA local domain = primitives.square(100) local ca_pat = subpattern.random(domain, 500) -- Repeat iteration until convergence is reached local converged = false repeat ca_pat, converged = automata.iterate(ca_pat, domain, {gol_rule}) until converged == true
- async_iterate (prevp, domain, ruleset, rng)
-
Asynchronous cellular automata iteration.
Performs a CA update on one cell (chosen randomly) in the specified domain.
This corresponds to a 'random independent scheme' update.
Parameters:
- prevp the previous iteration of the pattern
- domain the cells in which the CA operates
- ruleset a table of forma.rules defining the CA
- rng a (optional) random number generator (syntax as per math.random).
Returns:
- The result of the CA iteration [pattern].
- Convergence flag [bool: true if converged, false otherwise].
Usage:
-- Domain and initial state (10 seed points) for the CA local domain = primitives.square(10) local ca_pat = subpattern.random(domain, 10) local rng = math.random -- Repeat iteration until convergence is reached local converged = false repeat ca_pat, converged = automata.async_iterate(ca_pat, domain, {gol_rule}, rng) until converged == true


Given the following hash table, use hash function hashFunction and handle collisions using Quadratic Probing with probe function p(K, i) = i*i.
In which slot should the record with key value probeCommon.currentKey be inserted?
First use the hash function to computer the home slot.
If there is a collision, then the i
'th place
to look is i*i
steps from the home slot.
Remember that offsets are always with respect to the home slot, not from the last slot probed to.
If we reach the end of the array while stepping, then cycle around to the beginning.