13.2. How to create a table |
Friday, January 8, 2010
Section 13.2. How to create a table using XHTML
Chapter 1. XHTML: Giving Structure to Content
Chapter 1. XHTML: Giving Structure to Content[View full size image] Stylin' with CSS is all about designing and building Web pages that look stylish and professional, that are intuitive for visitors to use, that work across a wide variety of user agents (browsers, handhelds, cell phones, and so on) and whose content can be easily updated and distributed for other purposes. Like any artist, your ability to achieve your creative vision is governed by your technical abilities. In this book, I'm not going to wade into all the excruciating details that underpin the workings of the Web, but I will say that without a certain degree of technical knowledge, you will never achieve your Web design goals. So this book is intended to give you the core technical information you need to realize your creative vision, and hopefully to give you the confidence to "go in" further as you build your skills. But most of all, we will focus on design; by this I mean design in its broadest sense, not just aesthetics (visual appearance), but also ergonomics (logical organization) and functionality (useful capabilities). Everything in this book is based on Web standards, the rules of browser behavior defined in the recommendations of W3C (the World Wide Web Consortium), which all the major browser developers have agreed to follow. As you will see, browsers based on the Gecko enginethe current versions Mozilla/Firefox and Netscapeand those based on the Konquerer engineincluding the excellent browser Safari for Macdo a much better job delivering standards-based performance than the once-ubiquitous Microsoft Internet Explorer, which fails to implement many CSS specifications.
|
Recipe 16.11. Getting Information About a Domain Name
Recipe 16.11. Getting Information About a Domain Name16.11.1. ProblemYou 16.11.2. SolutionUse require 'Net/Whois.php'; 16.11.3. DiscussionThe Net_Whois::query( ) Registrant: For instance, if you want to parse out the names and IP addresses of the domain name servers, use this: preg_match_all('/^\s*([\S]+)\s+([\d.]+)\s*$/m', $data, $dns,You must set $server to the correct Whois server for a domain to get information about that domain. If you don't know the server to use, query whois.internic.net: require 'Net/Whois.php'; The Whois Server: line says that the correct server to ask for information about example.org is whois.networksolutions.com. 16.11.4. See AlsoPEAR's Net_Whois class at http://pear.php.net/package-info.php?package=Net_Whois. |
Section 7.2. Accessing Hashes
Hashes > Accessing Hashes
7.2. Accessing Hashes
Here's a hash that associates zip codes with the names of towns in Wyoming that start with the letter T (had to limit it somehow):
zip = { 82442 => "Ten Sleep", 83025 => "Teton Village", 83127 => "Thayne",
82443 => "Thermopolis", 82084 => "Tie Siding", 82336 => "Tipton", 82240 =>
"Torrington", 83110 => "Turnerville", 83112 => "Turnerville" }
There are tons of ways to access keys and/or values from a hash. You can pick what works for you—what works for the task at hand.
You can test to see if the hash zip has a given key with any of the following methods, which are all synonyms of each other: key?, has_key?, member?, or include?:
zip.has_key? 82442 # => true
Or you can do the flip side, and see if it has a given value with value? or has_value?:
zip.has_value? "Ten Sleep" # => true
Let's start pulling stuff out of zip. Here is a simple way of grabbing a value: the [] method. It retrieves a single hash value based on a key:
zip[82442] # => "Ten Sleep"
Then we have the methods keys and values. Return an array containing all the keys in a hash with keys:
Code View: Scroll / Show All
zip.keys # => [83110, 83127, 82336, 83112, 82084, 83025, 82442, 82443, 82240]
Get an array with all the values from a hash with values:
zip.values # => ["Turnerville", "Thayne", "Tipton",
"Turnerville", "Tie Siding", "Teton Village", "Ten Sleep", "Thermopolis",
"Torrington"]
Retrieve the values out of a hash based on one or more keys with values_at, also placing the value or values in an array:
Code View: Scroll / Show All
zip.values_at 82084 # => ["Tie Siding"]
zip.values_at 82442, 82443, 82240 # => ["Ten Sleep", "Thermopolis", "Torrington"]
Now return a value for a given key (one key only) with the index method:
zip.index "Thayne" # => 83127
The select method uses a block to return a new, multidimensional array of key-value pairs:
Code View: Scroll / Show All
zip.select { |key,val| key > 83000 } # => [[83110,
"Turnerville"], [83127, "Thayne"], [83112, "Turnerville"], [83025, "Teton Village"]]
Directing Implementation
| [ Team LiB ] |
Directing ImplementationGP 3.2 Collect Improvement InformationCollect work products, measures, measurement results, and improvement information derived from planning and performing the decision analysis and resolution process to support the future use and improvement of the organization's processes and process assets. GG 4 Institutionalize a Quantitatively Managed ProcessThe process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the ProcessEstablish and maintain quantitative objectives for the decision analysis and resolution process that address quality and process performance based on customer needs and business objectives. GP 4.2 Stabilize Subprocess PerformanceStabilize the performance of one or more subprocesses to determine the ability of the decision analysis and resolution process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing ProcessThe process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process ImprovementEnsure continuous improvement of the decision analysis and resolution process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of ProblemsIdentify and correct the root causes of defects and other problems in the decision analysis and resolution process. |
| [ Team LiB ] |
Chapter 4. C Data Structures
| [ Team LiB ] |
Chapter 4. C Data Structures
Programs work by applying algorithms on data. The internal organization of data plays an important role in how algorithms operate. You will find elements with the same type organized as a collection using a number of different mechanisms, each having different affordances regarding data storage and access. A vector, implemented as an array, offers random access to all elements, but it can be inefficient to change in size at runtime. A vector can also be used to organize groups of elements in the form of a table or stacked into two dimensions to create a matrix. Operations on a vector are sometimes restricted to occur at one end, in which case we talk about a stack, or in a first-in first-out order, treating the vector as a queue. When the order of the elements is not important, maps are used to create lookup tables and sets employed to form element collections. The ability to link data elements together using pointers gives rise to a number of other structures you will often encounter. A linked list easily grows dynamically but offers only serial access (including stack and queue operations), whereas a suitably organized tree can be used to access data elements based on a key and can also easily grow dynamically while allowing traversal in an orderly fashion. We finish our discussion of C data structures with an examination of some applications and code patterns relating to graphs�the most flexible representation of linked data structures you will encounter. Languages such as Java, C++, and C# offer abstractions for implementing these data structures as part of the language's library. In C these data structures are typically explicitly coded within the code body that uses them, however, their properties and the operations performed on them are common. The objective of this chapter is to learn how to read explicit data structure operations in terms of the underlying abstract data class. |
| [ Team LiB ] |
Section 3.2. The case Statement
Conditional Love > The case Statement
3.2. The case Statement
Ruby's case statement provides a way to express conditional logic in a succinct way. It is similar to using elsifs with colons, but you use case in place of if, and when in place of elsif.
Here is an example similar to what you saw earlier using lang with the possible symbols :en, :es, :fr, and :de:
lang = :fr
dog = case lang
when :en: "dog"
when :es: "perro"
when :fr: "chien"
when :de: "Hund"
else "dog"
end
# "chien" is assigned to dog
case/when is more convenient and terse than if/elsif/else because the logic of == is assumed—you don't have to keep retyping == or the variable name:
Ruby's case is similar to the switch statement, a familiar C construct, but case is more powerful. One of the annoying things to me about switch statements in C, C++, and Java, is that you can't switch on strings in a straightforward way (though you can in C#).
If the lang variable held a string instead of symbols, your code would look like this:
lang = "de"
dog = case lang
when "en": "dog"
when "es": "perro"
when "fr": "chien"
when "de": "Hund"
else "dog"
end
# "Hund" is assigned to dog
The next example uses several ranges to test values. A range is a range of numbers.
scale = 8
case scale
when 0: puts "lowest"
when 1..3: puts "medium-low"
when 4..5: puts "medium"
when 6..7: puts "medium-high"
when 8..9: puts "high"
when 10: puts "highest"
else puts "off scale"
end
# => high
The range 1..3 means a range of numbers from 1 to 3, inclusive. Because scale equals 8, scale matches the range 8..9 and case returns the string high. However, when you use three dots as in the range 1...5, the ending value 5 is excluded. The sets of dots, .. and ..., are called range operators; two dots includes all the numbers in the range, and three dots excludes the last value in the range. Underneath the hood, case uses the === operator from Range to test whether a value is a member of or included in a range.
WormChase as an Applet
WormChase as an AppletFigure 3-1 shows the WormChase game as an applet and as an application. It has the same GUI interface as the windowed version: a large canvas with two text fields at the bottom used to report the number of boxes added to the scene, and the time. Class diagrams showing the public methods are given in Figure 3-10. A comparison with the diagrams for the windowed version in Figure 3-2 show the classes stay mainly the same. The only substantial change is to replace JFrame by JApplet at the top level. Figure 3-10. Class diagrams for the WormChase applet
The Worm class is unchanged from the windowed version. The Obstacles class now calls setBoxNumber( ) in WormChaseApplet rather than WormChase. WormPanel reports its termination statistics in a different way, but the animation loop and statistics gathering are unchanged. WormChaseApplet handles pausing, resumption, and termination by tying them to events in the applet life cycle. By comparison, WormChase utilizes Window events. The applet's web page passes the requested frame rate to it as a parameter:
The WormChaseApplet ClassFigure 3-11 shows the class diagram for WormChaseApplet with all its variables and methods. Figure 3-11. WormChaseApplet in detailThe applet's init( ) method reads the FPS value from the web page, sets up the GUI, and starts the game:
makeGUI( ) is the same as the one in the JFrame version. The call to startGame( ) replaces the use of addNotify( ) in the JPanel. The applet life-cycle methodsstart( ), stop( ), and destroy( )contain calls to WormPanel to resume, pause, and terminate the game:
A browser calls destroy( ) prior to deleting the web page (and its applet) or perhaps as the browser itself is closed. The browser will wait for the destroy( ) call to return before exiting. The WormPanel ClassThe only major change to WormPanel is how printStats( ) is called. The stopGame( ) method is modified to call finishOff( ), which calls printStats( ):
finishOff( ) checks a global finishedOff Boolean to decide whether to report the statistics. finishedOff starts with the value false. finishOff( ) is called at the end of run( ) as the animation loop finishes. The first call to finishOff( ) will pass the if test, set the finishedOff flag to true, and print the data. The flag will then prevent a second call from repeating the output.
In the windowed application, stopGame( ) only sets running to false before returning, with no call to finishOff( ). The threaded animation loop may then execute for a short time before checking the flag, stopping, and calling printStats( ). This approach is fine in an application where the animation thread will be allowed to finish before the application terminates. Unfortunately, as soon as an applet's destroy( ) method returns, then the applet or the browser can exit. In this case, the animation thread may not have time to reach its printStats( ) call. To ensure the statistics are printed, finishOff( ) is called in the applet's stopGame( ) method. The other call to finishOff( ) at the end of run( ) is a catch-all in case I modify the game so it can terminate the animation loop without passing through stopGame( ). Timing ResultsThe timing results are given in Table 3-3.
The poor showing for the frame rate on the Windows 2000 machine is expected, but the applet performs well on more modern hardware. |
Study Results
Study Results
Sample
A total of 293 articles were used in the analysis. Among the articles reviewed, 41 originated in MIS Quarterly, 38 in Information Systems Research, 119 in Information & Management, 78 in Journal of Management Information Systems, and 17 in Management Science. Whereas most (68%) were field studies, coded works also included laboratory experiments (22%), case studies (5%), and field experiments (5%). In only 23% of the sampled articles, students (undergraduate or graduate) filled out the instrument. In the remainder of the articles, workers (sometimes in conjunction with students) were the ones to whom the instrument was administered. As far as the different techniques for data collection, it is worth mentioning that the majority (85%) of our sampled studies have collected data through the use of surveys (questionnaires). The conduct of an interview was the second most used technique, with 17% of the sampled articles using it. The use of more than one technique to capture data occurred in 31% of the studies.
Validation of Coding
Inter-rater was assessed to verify that our coding was reliable (Miles & Huberman, 1994). A second, independent coder thus coded a subset of the sampled articles. For the 11 coded attributes, the following percentages of agreement were obtained: type of research—77%; research method—85%; pretest—82%; pilot test—95%; content validity—90%; construct validity—85%; reliability—85%; manipulation check—95%; nature of the instrument—82%; instrument validation section—92%; and use of second-generation statistical technique—95%.
Cohen's (1960) kappa coefficient was also calculated. This coefficient is known to be a more stringent measure than simple percentages of agreement. For all criteria, the average kappa was 0.76, which is above the recommended 0.70 inter-rater minimum reliability (Bowers & Courtright, 1984; Landis & Koch, 1977; Miles & Huberman, 1994). As usual, disagreements between coders were reconciled before further analysis was performed.
Overview of Findings
Table 1 clearly shows that, over the past 13 years, instrument validation has improved in all the categories we have assessed. In addition, in two specific categories (pretest/pilot and reliability), the proportion of published studies validating their instruments is now greater than the proportion of published studies not validating their instruments. When comparing with Boudreau et al. (2001), the most important improvement is for construct validity, which was then assessed in 37% of the studies compared to 45% of the studies today. Improvement up to an additional 5% is noticeable in all other categories. Overall, although improvement in instrument validation is modest when comparing Boudreau et al.'s results to the current study's results, it is still comforting to observe a consistent increase in the use of all validation techniques.
|
|
|
|
|---|---|---|---|
Pretest | 13% | 26% | 31% |
Pilot | 6% | 31% | 31% |
Pretest or Pilot [i] | 19% | 47% | 51% |
Previous Instr. Utilized | 17% | 42% | 43% |
Content Validity | 4% | 23% | 26% |
Construct Validity | 14% | 37% | 45% |
Reliability | 17% | 63% | 68% |
| |||
Reliability is the validation criterion that was the most frequently assessed, when compared to all other validation criteria taken singly, in both previous studies as well as this one. As was the case in Boudreau et al. (2001), a majority of studies assessing reliability of their instruments have done so through the standard coefficient of internal consistency, i.e., Cronbach's α (84%). The second most popular technique to assess reliability was inter-coder tests, which was reported by 15% of the studies that appraised the reliability of their instrument. Moreover, the use of more than one reliability method is still rare, as it was done by only 10% of the studies assessing reliability.
A closer look at the studies that assessed construct validity reveals that diverse approaches were used for that purpose. More specifically, convergent, discriminant, and nomological validity were determined, respectively, in 50%, 58%, and 6% of these studies. As to predictive and concurrent validity, they were reported in 7% and 1.5% of these studies. Construct validity, in itself (and not in one of its five components), was recounted in 80% of the studies that assessed this kind of validity.
Table 1 shows that the utilization of previously existing instruments has more than doubled over the last 13 years. Also, as detailed in Table 2, it appears that studies using existing instruments were sometimes more inclined to validate their instrument than studies developing their own instrument from scratch. Indeed, construct validity and reliability were more frequently assessed in studies using a previously utilized instrument than those that did not (50% vs. 42%; 74% vs. 63%). However, with regard to the use of pretest or pilot studies and content validity, these validities were assessed more often within studies creating a new instrument than within studies using an existing instrument (55% vs. 46%; 28% vs. 24%). This table reveals another interesting fact: Over the past two years, research articles that created their own instrument improved their validation practices to a greater extent than research articles that used a previously utilized instrument.
| � |
|
| ||
|---|---|---|---|---|
|
|
|
|
|
Pretest or Pilot | 43% | 46% | 50% | 55% |
Content Validity | 20% | 24% | 25% | 28% |
Construct Validity | 44% | 50% | 32% | 42% |
Reliability | 74% | 74% | 54% | 63% |
It is interesting to observe how confirmatory studies (133 articles, or 45% of total) compare to exploratory studies (160 articles, or 55% of total). The present survey indicates that, for all criteria except for the use of pretest or pilot studies, exploratory studies showed less interest in validating their instruments than confirmatory studies (see Table 3). Indeed, the extent to which content validity, construct validity, and reliability were assessed was more frequent among confirmatory studies than among exploratory studies. This represents the same trend that was observed in Boudreau et al. (2001).
| � |
|
| ||
|---|---|---|---|---|
|
|
|
|
|
Pretest or Pilot | 47% | 49% | 47% | 53% |
Content Validity | 35% | 35% | 17% | 19% |
Construct Validity | 53% | 61% | 29% | 33% |
Reliability | 69% | 75% | 60% | 62% |
The extent to which a research method has bearing on instrument validation constitutes an interesting observation. In Straub's (1989) original study, it was argued that experimental and case researchers were less likely to validate their instruments than field study researchers. Boudreau et al.'s (2001) study showed a similar trend when comparing field studies to experimental studies, but not to case studies. The additional data used in the present study demonstrates that Straub's initial inference still holds true today on all of the previously introduced validity criteria (see Table 4). Indeed, field study researchers from our sample were more inclined to validate their instrument than experimental and case researchers. The most notable difference was for the use of construct validity, where a gap of 31% existed between experimental and field study research.
|
|
|
|
|---|---|---|---|
Pretest or Pilot | 59% | 36% | 31% |
Previous Inst. Utilized | 47% | 38% | 23% |
Content Validity | 32% | 15% | 15% |
Construct Validity | 55% | 24% | 38% |
Reliability | 69% | 65% | 62% |
The inclusion of an Instrument Validation section, as originally suggested in Straub (1989), was tallied as frequently in the current study as it was in Boudreau et al.'s (2001) study. Indeed, only 24% of the surveyed articles included such a section. For this minority of articles, there was a greater extent of reporting a pilot or pretest study (80% vs. 42%), content validity (52% vs. 18%), construct validity (82% vs. 34%), and reliability (88% vs. 61%). These percentages are hardly surprising since if one feels compelled to include a specific section on instrument validation, it is because efforts have been done in this area. However, it is disappointing not to observe an increase in the percentage of studies that included a special section reporting their endeavor in instrument validation.
Noticeable improvement has occurred in the use of manipulation check in the past few years. As indicated in Table 5, among the field and laboratory experiments in our sample, 30% performed one or several manipulation checks of the treatments, compared to 22% in Boudreau's et al.'s (2001) study. Moreover, percentages have particularly increased in two journals, that is, MIS Quarterly (increase of 21%) and Information Systems Research (increase of 12%). The absence of manipulation checks in the experimental studies of Management Science may be due to the tendency for articles of this journal to use directly observable measurements, such as time, rather then latent constructs.
|
|
|
|---|---|---|
| 24% | 25% |
| 38% | 50% |
| 29% | 50% |
| 17% | 19% |
| 0% | 0% |
All Five Journals | 22% | 30% |
A greater percentage of studies from our sample used second-generation statistical techniques (e.g., structural equation modeling) rather than first-generation statistical techniques (regression, ANOVA, LOGIT, etc.). From 15% in Boudreau et al. (2001), this percentage increased to 19% in the present study (see Table 6). However, the extent of instrument validation did not change much when comparing first-to second-generation techniques in the two studies. As was the case in Boudreau et al., studies making use of SEM techniques scored higher in all categories, particularly for construct validity and reliability. Among the studies using second-generation statistical techniques, the most commonly used tools were PLS (42%), LISREL (21%), and EQS (18%).
| � |
|
| ||
|---|---|---|---|---|
|
|
|
|
|
Pretest or Pilot | 44% | 64% | 48% | 63% |
Previous Inst. Utilized | 42% | 46% | 43% | 46% |
Content Validity | 19% | 43% | 23% | 39% |
Construct Validity | 29% | 82% | 36% | 86% |
Reliability | 57% | 96% | 61% | 93% |
A possible reason for this difference is that SEM analyzes both the structural model (the assumed causation) and the measurement model (the loadings of observed items). As a result, validity assessment is an integral part of SEM. The validity statistics appear explicitly in the output, and the degree of statistical validity directly affects the overall model fit indexes. In first-generation statistical techniques, on the other hand, validity and reliability are performed in separate analyses that are not related to the actual hypothesis testing and, thus, do not determine the overall fit indexes.
Summary of Key Points
It should be considered good news that, in the short period of two years since the last study assessing instrument validation practices, IS researchers have improved the validation of their instrument. Granted, such an improvement is certainly not as significant as what had been observed when using Straub's (1989) study as the baseline, but this is understandable given that the time period was then much longer. Although better, the current validation practices are far from perfect, and it is still necessary to state that IS researchers need to achieve greater rigor in the validation of their instruments and their research. More particularly, the following nine key findings should engage further reflection and action:
Over the past two years, instrument validation practices have steadily improved.
In two specific categories (pretest/pilot and reliability), the proportion of published studies validating their instruments is now greater than the proportion of published studies not validating their instruments.
The assessment of construct validity has improved the most over the past two years.
Published studies are increasingly using preexisting instruments; while doing so, reliability and construct validity are being more frequently assessed.
Confirmatory studies are more likely to assess reliability, content validity, and construct validity than exploratory studies.
Laboratory experiments, field experiments, and case studies lag behind field studies with respect to all validation criteria.
Although the inclusion of an Instrument Validation subsection warrants greater reporting of validation practices, it appears infrequently in empirical studies.
There has been a noticeable improvement in the use of manipulation check in the past few years; however, in some publications outlets, manipulation check is only done by a minority of IS experimenters.
Published studies making use of second-generation statistical techniques (SEM) are much more likely to validate their instruments than published studies making use of first-generation statistical techniques.
Improving Performance with Persistent JobStores
Improving Performance with Persistent JobStoresPerformance is one topic that receives the most attention when there's the least amount of time to do anything about it. As experienced developers, we know that it should be a consideration from the onset of the project. When using Quartz with persistent JobStores, the biggest area of concern has to be the interaction with the relational database. Database I/O (just like file I/O) is usually not very fast. You can improve performance by doing things such as tuning the SQL, adding indexes, and manipulating tables and columns. Because performance concerns were already taken into account in the writing of Quartz, you don't want to dive right into doing these things to Quartz without having an actual performance problem, trying to solve it through a configuration setting, and trying everything possible not to manipulate source code. The good news is that Quartz is open source and you have complete insight into what it's doing and how it's doing it. If you don't like how it queries the database, it's your prerogative to fix it. Before you take this route, however, be sure to check with the users and developers on the Quartz forum to see if others have had the problem and explore the recommended suggestions. One very easy (and very effective) way to improve performance is to make sure the tables have indexes created on all the appropriate columns. Some of the database-creation scripts that ship with Quartz already have the commands for creating indexes. If yours does not, you can simply refer to those defined at the bottom of tables_oracle.sql and translate any syntax changes that are necessary for your RDBMs. Whatever you do, if you make changes that improve performance, be sure to offer them back to the community and the Quartz project. |
Directing Implementation
| [ Team LiB ] |
Directing ImplementationGP 2.6 Manage ConfigurationsPlace designated work products of the process and product quality assurance process under appropriate levels of configuration management. Elaboration
GP 2.7 Identify and Involve Relevant StakeholdersIdentify and involve the relevant stakeholders of the process and product quality assurance process as planned. Elaboration
GP 2.8 Monitor and Control the ProcessMonitor and control the process and product quality assurance process against the plan for performing the process and take appropriate corrective action. Elaboration
|
| [ Team LiB ] |
Job Storage in Quartz
Job Storage in QuartzQuartz supports several different types of storage mechanisms for Scheduler information. Two types of Job storage are available in Quartz:
By default, we've been using the memory storage mechanism in the examples from the past several chapters. Both types are designed to serve the same purpose: to store job information. How they each go about it, however, and what functionality they provide the Scheduler is very different. The JobStore InterfaceQuartz provides an interface for all types of job storage. The interface located in the org.quartz.spi package is called JobStore. All job storage mechanisms, regardless of where or how they store their information, must implement this interface. The JobStore interface has too many methods to list here, but the API for the JobStore interface can be generalized into the following categories:
Quartz users almost never access or see concrete classes that implement the JobStore interface; they are used internally by the Quartz Scheduler to retrieve job and trigger information during runtime. It is a worthwhile exercise, however, to familiarize yourself with each type so that you better understand the facilities these provide on your behalf and to choose the right one for your Quartz application. |
Section A.1. #1 More Selectors
A.1. #1 More SelectorsWhile you've already learned the most common selectors A.1.1. Pseudo-elementsYou know all about pseudo-classes, and pseudo-elements are similar. Pseudoelements can be used to select parts of an element that you can't conveniently wrap in a <div> or a <span> or select in other ways. For example, the first-letter pseudo-element
A.1.2. Attribute selectorsAttribute selectors are not currently well supported in current browsers; however, they could be more widely supported in the future. Attribute selectors are exactly what they sound like: selectors that allow you to select elements based on attribute
A.1.3. Selecting by SiblingsYou can also select elements based on their preceding sibling. For example, say you want to select only paragraphs that have an <h1> element preceding them, then you'd use this selector:
A.1.4. Combining SelectorsYou've already seen examples of how selectors can be combined in this book. For instance, you can take a class selector and use it as part of a descendant selector, like this:
There's a pattern here that you can use to construct quite complex selectors. Let's step through how this pattern works:
That's a quite complex selector! Feel free to construct your own selectors using this same method. |
11.5 Stored Functions in DML Statements
< Day Day Up > |
11.5 Stored Functions in DML StatementsStored functions Like queries, DML statements may call stored functions where
Any subqueries called from a DML statement may also call stored Often, sets of complementary stored functions are called from both UPDATE cust_order where :1 and :2 are Stored functions may also be used in the WHERE clause in place of UPDATE cust_order co After having written many subqueries against the FUNCTION get_part_count(ordno IN NUMBER, The function may be used for multiple purposes, including:
The UPDATE statement may now use the function to locate open orders UPDATE cust_order co |
< Day Day Up > |
D.7 OpenCL
| [ Team LiB ] |
D.7 OpenCLThe source code contained in the OpenCL directory is copyrighted by the OpenCL Project and, unless otherwise noted, is distributed under the following license.
|
| [ Team LiB ] |
Section 4.7. Summary
4.7. SummaryIn this chapter, we set aside the Sarbanes-Oxley discussion for a moment to investigate the entire open source phenomenon and the fundamental differences between it and nonfree software. After an examination of closed source development, we examined the open source methodology in some detail and articulated the tangible and intangible reasons why open source software can save you money and give you freedom of choice. Because of the rapid development cycle and the "release early, release often" mentality, the bar of quality and security is raised owing to massively parallel peer review of the source code. When a bug is identified by an end user, often he or she is a hacker who also supplies the fix, or at least a directed report on how to reliably reproduce the bug for the developer to test. Linux Torvalds' "Given enough eyeballs, all bugs are shallow" theorem essentially states that someone, somewhere, will know the fix to a bug no matter how difficult it may seem to the original developer. We continued by examining the use of open source in your environment. We learned that there are many opportunities for the use of OSS software, even if you are currently on a primarily Windows-based infrastructure, as most prominent open source software runs on diverse architectures, including Windows. This investigation was further refined by discussing the two main ways in which open source software fits into the SOX compliance equation, both as elements of your IT infrastructure and as support systems such as document control, system monitoring, workflow, and approval management. We also discussed some of the items you should consider if your environment is in a state of transition. One must be diligent to document and subject any changes to the same approval and testing mechanisms as those identified for internal controls procedures. When evaluating your IT infrastructure, your internal controls universally fall into the categories of prevention and detection; however, all controls share some common characteristics and constraints. All controls must be testable; a well-defined test must be in place to validate the control. All control tests must be repeatable; the same test should yield the same result every time. All control tests should be sustainable; that is, they should enable you to maintain your controls and certification processes over time. In conclusion, we introduced the sample companies that will be used as case studies for the remainder of the book to illustrate concrete examples of open source software deployment as the subject of certification, and the use of open source software in the compliance process. The sample companies demonstrate two completely different architectures; BuiltRight Construction is a small public company with an infrastructure based entirely on Microsoft Windows and other closed source technologies, and NuStuff Electronics is a medium-sized global organization with a mixed platform environment. |
Section 8.6. Property-Oriented Criteria Factories
8.6. Property-Oriented Criteria Factories
We've already seen that there is often more than one way to
express what you want using the criteria API,
depending on your stylistic preferences, or the way you think about
things. The Property class offers another bunch of
alternatives of which you should be aware. We will not explore this class
in depth because it is just another way of setting up criteria, but it is
important to explain how it works, so you won't be confused if you run
across examples, or feel baffled while scanning Hibernate's dense JavaDoc.
(And, frankly, after one or two examples, you'll undoubtedly get the idea
well enough that you may decide to adopt this approach yourself.)
Property is another factory for
criteria, much like Restrictions, which we've
been using in this chapter (and Order and
Projection, for that matter). You can create
essentially all the query refinements available with those other factories
by using Property instead. Rather than starting
with the kind of constraint in which you're interested, and then naming
the property to which you want to apply it, you instead start with the
property and pick a constraint.
NOTE
Enough abstraction! Show some examples!
As before, you start by creating Criteria on
the object you want to query. But instead of saying, for example:
criteria.add(Restrictions.le("playTime", length));you can say:
criteria.add(Property.forName("playTime").le(length));It's really very similar—just a slightly different emphasis—as when
you have more than one way to phrase the same concept in English. There
are a bunch of methods in Property that give you
criteria, orderings, and projections. You can't construct a Property instance using
new( )—you need to either start with
the forName( ) static factory, or
use an existing Property instance and call
getProperty( ) on it to traverse to one of its
component properties.
Here are a few more examples to show how this approach fits in.
Where we had used statements like:
criteria.addOrder(Order.asc("name").ignoreCase());we could instead have used:
criteria.addOrder(Property.forName("name").asc().ignoreCase());And with projections, the approach we'd followed, such as:
criteria.setProjection(Projections.max("playTime"));could equally well have been expressed as:
criteria.setProjection(Property.forName("playTime").max());NOTE
This is almost an embarrassment of riches!
So, take your pick. Sometimes the kind of problem you're solving, or
the thrust of the rest of the code, will evoke one style or the other. Or
perhaps you'll just like one better and stick with it. But at least you're
now aware you might run into both, and should be able to understand any
criteria expression. These factory methods are all summarized in Appendix B.
Overwhelmed with options yet? No? Well, when criteria queries don't
quite do the job, or you want an even more extreme alternative to all the
choices you've seen in this chapter—especially if you're comfortable with
the concision of SQL—you can turn to the full power of
HQL. We investigate that in the next chapter.
8.6.1. What about…
…sneaking a little SQL in with your other
criteria to take advantage of database-specific features or your mad
DBA skillz? Using subqueries, or detached criteria
that can be set up before you have a Hibernate session? Plugging in your
own Java code to filter the results as the query is performed? All of
these things and more are possible, but beyond the scope of this book.
If you're ready for them, the Advanced query
options chapter in Java
Persistence with Hibernate is a good overview,
and the Hibernate JavaDoc and source code are the definitive
references.
Subscribe to:
Posts (Atom)