Skip to content. | Skip to navigation

Personal tools
Log in
You are here: Home The Chordchart Template

The Chordchart Template

Finally getting to some meat in the project.

Some of the theory portion of my self-training is complete and now it is time for the practicum. 

So now that I have the logo complete...more or is time to start working on my first actual piece of program.  I could argue to myself that setting up the webpage layout and look/feel/workflow is more important and probably the next logical step, but I'm not motivated to do so.  So, I'm going to try to get my first piece of code working that I developed over two months ago.  It is a bunch of python modules that will change the key of the chord charts (eventually with up/down arrow buttons at the bottom of the page.  I think right now I can only go up and start over after the key of G#...Also, no flats yet, but still working on that). 

Okay, with all that being said, I have some steps to getting the chord charts up and running.  The tasklist should look something like this:

1. Create a database that will store the data 
    The chordchart table will look something like this (wip):


   I'm not sure weather or not I should divide the chords and lyrics off to other tables, but I doubt I will.  It will just be a really really big table.  Every column is written to or queried every time so there is probably no reason to seperate.   Then have several tables that keep the data included in each cell on the template.  So, I'll divide the page into a table with little cells/fields that will house the chords and longer fields underneath for the lyrics.  

2. Create a form as a UI to get the variable data.  The form will look something like this:


Each chord and lyric field will have a reference number starting with 00000 and ending with ??? The other string fields will be referenced by their names (i.e. Title, author, copyright, etc)  I'm not sure how flexible I can be with the editing.  Will each page have to be created seperately, or can it all be one document?  So far, 33 cells seems to be a good number (it is what Excel called a page with 1" margins) for the table width and maybe I can have 14 or so lyric lines per page..?

So each field will be filled out with a ton of null values used only as placeholders or whitespace for between the chords.  The data will be read and each chord will be placed in a new row according to the the number corresponding to the column.  So if the is a Gdim7 chord in field 0000527, it will be placed in the chordchart table in a cell that intersects the newly created row and column 0000527. 

3. Create another simple form to query the database and retrieve a list of results.  This should be simple...I hope.

4. Create a Page Template with CSS that will display the data in a very nice format and layout.  This will be one of the most difficult parts.  A) I'm not really sure what format the retrieved data will be in B) I don't really know how I'll manipulate the data from my search query to display it on the page C) How will I map the 0000 keys to CSS styles? 

  One thing I have learned, is how to retrieve data easily using TAL, Python, and Z SQL Methods.  The code looks something like this:

     <li tal:repeat="list python:context.select_vardb()"

If ran from a Page Template in the fake_project folder, this would produce an ordered list from my SQL method that is the equivalent to:

'SELECT * FROM test'

So with that in mind, I suppose I can use some code similar to this:

  <div tal:repeat="list python:context.select_vardb(title=var_QueryFormInput)"
Pulling the title from the query form. 

It may help to always pull the data back to a table similar to the original form.  That way, the person doing the query can make some last minute notes, edits, or key changes before printing/saving/e-mailing.  Plus that will help me figure out the best way to retrieve the data and match the cells with the table columns, and then back to the cells. 

Now the cool part.  From here, there will be VIEW, UPDATE, and CANCEL buttons at the bottom.  The view button will open the form results in a new window.  The new window will be a more elegant version of the form table with CSS styling and different font elements for Title/Author/Copyright as well as nice colors that fit the webpage's colorscheme.  And no table borders!  From here the user can send the document to client's workspaces for client retrieval.

<random_thought>Uh, I suppose security will be different on those retriving documents.  i.e. they should not be allowed to edit the document themselves, only save or print.  Another way to handle that is to somehow save the document on the server and 'send' it to the client's workspace to view/print as a text document from there.</random_thought>

The Update button will update changes made and make them persistant on the database.  The cancel button takes you back to the original query form??

Document Actions
Other Things