A New Look

From the beginning, my coding was geared modularly by entirely separating out design from javascript function. CSS integrates nicely with HTML to accomplish that. This inordinately facilitates maintenance and modification over the course of time. The files too are therefore in separate directories.

Here I switched to a new look. Mainly two colors. Not much user-entry required; Only a few basic parameters and options, as the range to search through, or the limit that sets the maximum number of finds in the Results page, and the user's single input field.

Toraware.com hopes it achieved its desired clean, intuitive interface to let users explore Torah using ancient methodology - easily. Anything to simplify the mechanism, either with choice few words or icons, my functional motto always has been “the simpler the better”. (Look how simple Google is - 1 field of input!) E.g., two-word title.

This website is an engine. Under its hood the engine's rpm's rummage through its database, the Pentateuch (and other of the 24 holy books, as they are little by little appended to the end).

The user can choose to search any range of the database the parameters allows for. For example, the user can change the default settings and specify a strictly Tehilim-only search.

This site only serves up 3 pages: Home page, Options & Input page; and Results page. It sports only two buttons.

The Home page collects some parameters and waits for a search method to be invoked; The Options Page provides options apt for that search method, and accepts user input. The Results Page then displays the list of “hits”.

The “hovering” feature over anchor (that highlights the search method a cursor hovers overs) tags that CSS so simply implements, provides enormous, unexpected user-friendliness, with only a few extra bytes of code; The selection of search methods immediately becomes more intuitive. This same code also has the same unexpected but most welcome feature of highlighting any single result te user was to selectively inspect. This shows up on the Results page hit list. The user can easily eyeball exactly the row of data he wants to look at, without other nearby legibility interference.

Most search methods, all but the “embedded text” method - to be specific, are rather speedy and momentary in execution. The lone exception is the “embedded” method. I therein post a warning in red for users to know this, because it’s not usual for browsers to delay as much as this time it will, This method suffers from relatively slow response times, especially with lengthy user strings. But at least a 50-count skip factor can be ranged through fast enough to provide at least a slow response if not a fast one.

New logo was designed by TA Productions. They're relatively cheap, efficient, reliable and on-time.

A Few Bytes of CSS Load a Mighty Punch

CSS is turning out to be a very powerful tool in that so little code is required to make elaborate changes that remarkably enhance the site at so little effort.

Earlier a CSS "hover" technique enhanced my Home and Result pages. Literally a few bytes of extra CSS code and voila, eye-opening, exciting new function, enhancing user-friendliness with more intuitive features.

Now I discovered a simple "border-effect" (courtesy of css-tricks.com) that was as easy as pie to code. So today the site got its new facelift.

Factors in Possuk Gematria

Boruch Hashem, implemented another search method.

Suppose you search a gematria and cannot find it ("No Finds "). But perhaps a possuk exists whose gematria is a fraction, or MULTIPLE, of that gematria. For example, in Torah no possuk has a gematria value of 770. However, there happen to be 11 possukim in Torah that have 770 as a multiple of this value (from 3 to 8 times that).

If you use this engine and find something interesting, won't you please report it. Thanks .

Embedded-Text Search Method Now Renders Quicker

For the nitty-gritty-minded:


A significant increase in processing speed I gained by eliminating repetitive code that was only needed to avoid an error during the end-of-file encounter. Instead of continually end-checking for an “overflow” event, to know I reached the end, using the following AND logic:

... && ... !== undefined ...

(embedded in so many IF statements!), I simply added a few bytes to the end of my database array, an “EOF” record, setting its indexing parameter beyond the record above it (i.e., "one chapter ahead").

This component of many IF statements can now be eliminated because only the greater-than comparison - by itself - is needed, even at the end-of-file situation.

Although this did improve processing speed, it’s still not fast enough to combine the 0-50 and 51-100 skip options into one (“0 - 100”) (and to an another option, eg, 101-200).

Different Methods Yield the Same Result

... as demonstrated here: