The Phrasebook pattern
Posted: Sun Jul 27, 2003 2:35 pm
I've been thinking a lot about the Phrasebook pattern a lot since Jason mentioned it here -- primarily for pulling my sql queries out of the code, not so much for xhtml blocks.
I've read the document that defines the purpose and use of the phrasebook pattern, but still have a few questions.
1. "Good" formats for the phrase fill:
One of the main reasons I would like to use the PB pattern is to get my long (5-10 line HEREDOC) queries out of the code stream. PHP-mode in Emacs doesn't handle HEREDOC's very nicely so it breaks a lot of the syntax highlighting amd indenting. Regular double-quoting doesn't work nicely for very long queries, neither does single-quoteing. So putting the queries elsewhere would be nice. However if I put the queries else where I'ld want to be able to use SQL-mode on that file for its syntax highlighting. This rules out the use of an XML format for the phrase file as I think Jason was suggesting. (Besides the purpose of PB is to seperate the job of writing different languages, possibly to different developers... why make the SQL guy learn XML...)
However this means that the labelling of phrases with their handle would have to be done via comments, ala phpdoc/javadoc style. I'm not sure I really like this idea, but its what I've come up with so far.
2. How much "introspection" into the phrases is needed? How much meta data should be stored?
Is it safe to expect the PHP developer (PB user) to know the number, order of attributes returned in each tuple generated by the query? Or should the PB pattern include the meta-data needed by the developer to "unpack" the returned data?
It seems like in the case of SQL PB's, there is a need for a standard documentation model
Function name-->query handel
Function arguments -->query parameters
Return structure -->relation header
Most PB's I've seen only have support for the first item explicity and a way to "compile" arguements in, but often without a safe namespace, ie it requires the developer to read the pattern to see the names of the variables and then sets up those variables in advance. (Some are safer and have the develop pass in an array, thus created a new/safe namespace.)
So it seems like ideally we should have two levels of abstraction?
Some sort of database class/library that wraps the individual PB phrases and handles the namespace issues. This also gives a logical place for the required developer documentation.
The PB fiile whose contents are only reached through the database class/library, thereby avoiding the need for increased meta-data. The SQL coder and the library developer might need to coordination when the SQL guy optimizies, rearranges queries, but ideally the library interface remains constant to the application programmers.
However, in doing so it seems like I've written away a lot of the benefits of the PB pattern and am only using it to hide queries.... Or is this the normal way its used?
I've read the document that defines the purpose and use of the phrasebook pattern, but still have a few questions.
1. "Good" formats for the phrase fill:
One of the main reasons I would like to use the PB pattern is to get my long (5-10 line HEREDOC) queries out of the code stream. PHP-mode in Emacs doesn't handle HEREDOC's very nicely so it breaks a lot of the syntax highlighting amd indenting. Regular double-quoting doesn't work nicely for very long queries, neither does single-quoteing. So putting the queries elsewhere would be nice. However if I put the queries else where I'ld want to be able to use SQL-mode on that file for its syntax highlighting. This rules out the use of an XML format for the phrase file as I think Jason was suggesting. (Besides the purpose of PB is to seperate the job of writing different languages, possibly to different developers... why make the SQL guy learn XML...)
However this means that the labelling of phrases with their handle would have to be done via comments, ala phpdoc/javadoc style. I'm not sure I really like this idea, but its what I've come up with so far.
2. How much "introspection" into the phrases is needed? How much meta data should be stored?
Is it safe to expect the PHP developer (PB user) to know the number, order of attributes returned in each tuple generated by the query? Or should the PB pattern include the meta-data needed by the developer to "unpack" the returned data?
It seems like in the case of SQL PB's, there is a need for a standard documentation model
Function name-->query handel
Function arguments -->query parameters
Return structure -->relation header
Most PB's I've seen only have support for the first item explicity and a way to "compile" arguements in, but often without a safe namespace, ie it requires the developer to read the pattern to see the names of the variables and then sets up those variables in advance. (Some are safer and have the develop pass in an array, thus created a new/safe namespace.)
So it seems like ideally we should have two levels of abstraction?
Some sort of database class/library that wraps the individual PB phrases and handles the namespace issues. This also gives a logical place for the required developer documentation.
The PB fiile whose contents are only reached through the database class/library, thereby avoiding the need for increased meta-data. The SQL coder and the library developer might need to coordination when the SQL guy optimizies, rearranges queries, but ideally the library interface remains constant to the application programmers.
However, in doing so it seems like I've written away a lot of the benefits of the PB pattern and am only using it to hide queries.... Or is this the normal way its used?