Dintzilla is a web site for the management of a dental clinique.
we have more projects based on the same library and architecture and working at Dintzilla Project can be the beggining of a strong collaboration.
The archive contains the library, the preliminary code generated for this application, database structure, html interface example and requirements
The code from the folder stoman is generated code, having the purpose to make the development easier.
You have to develop the application so that the interface look like the atached html files and behave as described in requirements.
Please download the arhive and take a look at the generated code. You have to modify this code and eventually add new files so that the application behave as required
The archive has the following content:
doclibdev - the documentation for our library, it's a small and fast library
lib - the library itself, including the sourcecode
stoman - the generated code for this application, including database structure
html_schema - this is how we want the interface to look like
At this point, all files from stoman excepting [url removed, login to view] are machine generated.
when writing you must follow the following rules :
# <ol start="1"> All the lines have to be limited to 80 characters long.
# Only one statement is allowed per line.
# Do not leave unnecessary blank lines.
# Do not use tab character. Convert tabs to spaces (most of editorsprovide this option).
# Align the new line with the beginning of the expression at the same level on the previous line. i.e. Do block related statements together.
# Indent 2 spaces for each block and all continuation lines have to be indented.
# Understand that at any moment, user can read only 25 or so lines of code.
So, organize that code around that fact. That means:
* Have functions that are smaller than 25 lines. Best way to create new functions is to abstract some part of the problem (domain, echnical, or linguistic) and provide a function for that. It always should be possible to get such an abstraction going.
* If the function is large, break down into blocks, where each block is doing some unique activity. Use one line comment describe that activity.
* Use appropriate formatting scheme to cut down on excessive lines. For examples, ornate commenting scheme is not good. Placing empty lines that does not indicate some semantic separation to the reader is not good. Also, use K&R scheme of indenting to maximize the information to lines ratio.
* For complex logic functions, include the algorithm before the function body and after the comment section.
# Understand that code is meant to be read and understood. That means, it
should be readable, say, over the phone. That means:
* Use meaningful names. Long names are not necessarily the most meaningful. It is ok to use i and j for indexing. If there is an abbreviation, such as num, no etc. use one unique abbreviation through out the project.
* Use verbs in naming procedures, because it indicates action. Use names for functions that return values.
* Never, ever use two names that differ only in capitalization, and punctuation.
# Comments should not repeat the code. Comments are meant provide higher-level road map. That means:
* Comments should explain the domain portion, not the code.
* Comments should tell the reader why and what you are doing it, rather than how.
* In case the code is tricky, explain the how, and tell them explicitly why it is tricky.
* Use commenting style that is easy to maintain.
the application must be skinnable, must permit translation to multiple languages whith a language file( you must create the english file) and allow selecting the language from settings.
the code must be well documented.
THE INTERFACE MUST BE COMPLETLY SEPARATED FROM THE BACKEND.
3 freelancers are bidding on average $525 for this job
Dear sir, I 've viewed the attached generated code and other files as well. I am ready to work on your project. I have more than eight years of experience in web development. Thanks. Best, Tomson