Page 1 of 1

Application-Scope solutions?

Posted: Thu Jul 21, 2005 10:09 am
by nielsene
I've been playing around with my old PhraseBook pattern implementation. Going though a long internal debate on how many phrases to place in a file/versus how many files to have etc.

For a quick recap:
A PhraseBook is a pattern used to consolidate "phrases" of some second languange that are needed by a host langunage. For instance, all the SQL queries that most PHP applications need.

Typically the PhraseBook is given a filename in its constructor; it then creates a Dictionary of Label->Phrase pairs. Normally the Phrases are allowed to contain place-holder variables that will be provided when the query is asked for.

This allows all the queries for an application to be consolidated making it easier for the DBA to update queries when the schema changes or to work on increasing preformence, etc.

I've taken a slightly unusual approach in that I have a custom phrasebook syntax/format for each included language (SQL,LaTeX,XHTML). I wanted each phrasebook's source file to be readable in the appropriate syntax highlighting mode. Therefore each phrasebook uses its languange's comment syntax to delimit sections. For instance

Code: Select all

-- @Query Label: GET_FOO
-- @Query Var: foo_id INT identifies the foo to get
-- @Query Column: 1 name TEXT the name of the foo
-- @Query String
SELECT name FROM foos WHERE foo_id=їїfoo_id]];
-- @End Query String
Would be a given phrase in my PhraseBook. I'm working on a PhraseBookDoc tool (as you can probably guess by the Var/Column sections (optional)). If the Vars are list howeverm it does do the appropriate type checking (and can thus avoid casting things to quoted text). If I ever finish my SQLDOc module, then the two will cross link (ie auto detect table names and link to that tables definiation, include list of phrases using a table on the table's page, etc)

Now the loading process is lots of strpos,preg_match, etc string processing. I'll typically consolidate all the Phreases for a given section of the application to one phrase file, so I don't need to load every single possible query on every single page. So far it hasn't caused too much of a preformence drain, but I can see it getting to the point. Of course having multiple phrase files starts to heighten the chance of missing one on a schema change...

This is one of the classic places, in my mind at least, where it would be nice to have application scoped variables. Have people found good workarounds? I suppose I could "compile" the phrases to a binary file in some sense that would need less string parsing, but its still needed to open a file, read it, populate an internal structure, etc on every page.