Writing code for {config_load} is turning out to be harder than I thought. Parsing and caching a {config_load} file is somewhat easy, but coming up with a calling scheme is not.
Basically, I want the compiled file to call a function which sets the config session variables: session("t_tpl_config")("variable_name")="value"
Coming up with a way to create that function, the function name, and the filename is difficult. The generated filename must be unique, and the generated function name must be unique.
Wednesday, December 9, 2009
Tuesday, November 24, 2009
Next: {config_load}
I'd like to implement {config_load} next.
{config_load file="filename.ext" section="section_name"}
{config_load} loads variables for use in the template. You will be able to access these values with hash marks: {#variablename#}. "section" is optional. You'll be able to load only the portion of the config file that you need.
Here is Smarty's explanation for {config_load}:
http://www.smarty.net/manual/en/language.function.config.load.php
I think I'll only be able to implement the "file" and "section" parameters. I don't think I'll be able to implement the "scope" parameter, because I'm not sure how much control I'll have in controlling the scope of variables.
After finishing {config_load}, I think I'll bump up the version number from 1.0 to 1.1.
{config_load file="filename.ext" section="section_name"}
{config_load} loads variables for use in the template. You will be able to access these values with hash marks: {#variablename#}. "section" is optional. You'll be able to load only the portion of the config file that you need.
Here is Smarty's explanation for {config_load}:
http://www.smarty.net/manual/en/language.function.config.load.php
I think I'll only be able to implement the "file" and "section" parameters. I don't think I'll be able to implement the "scope" parameter, because I'm not sure how much control I'll have in controlling the scope of variables.
After finishing {config_load}, I think I'll bump up the version number from 1.0 to 1.1.
Added truncate modifier
I just finished adding the truncate variable modifier. It cuts off a string at either 80 characters, or some number of characters you indicate. Smarty has more options, and I'd like to add them later, but this is good enough for now.
Working on truncate
I'm working on the truncate modifier.
{ $strVariable|truncate }
{ $strVariable|truncate:intLength }
Truncate will end a string variable's output to a character length. If no length is given, the default intLength value is 80. It will try to cut off at a word boundary before the intLength value. Smarty's truncate has some additional optional parameters, but I don't think I'll be able to implement it fully very soon. So, I'll just implement the length parameter, for now.
Also, I'm going back and forth regarding implementing dynamic includes in Dermis. The difficulty is that Dermis would have to determine if the .tpl.file needs to be compiled at every occurrence of an {include} tag. If it is, this means that the Dermis compiler would need to be invoked. Therefore, the Dermis code would need to be #included once the script begins.
{ $strVariable|truncate }
{ $strVariable|truncate:intLength }
Truncate will end a string variable's output to a character length. If no length is given, the default intLength value is 80. It will try to cut off at a word boundary before the intLength value. Smarty's truncate has some additional optional parameters, but I don't think I'll be able to implement it fully very soon. So, I'll just implement the length parameter, for now.
Also, I'm going back and forth regarding implementing dynamic includes in Dermis. The difficulty is that Dermis would have to determine if the .tpl.file needs to be compiled at every occurrence of an {include} tag. If it is, this means that the Dermis compiler would need to be invoked. Therefore, the Dermis code would need to be #included once the script begins.
Friday, November 20, 2009
Dynamic includes might be possible
Despite what nearly everyone says, dynamic includes may be possible in ASP. You just have to go through some effort to do so.
Dermis passes variables from ASP to the compiled Dermis file using session variables. It then shells to the compiled file using the server.execute("filename.asp") command. When you use the server.execute command, the called script cannot see variables (or code) from the parent (i.e., calling) script. However, session variables are outside of the variable space. So, Dermis can copy ASP variables into session variables, server.execute the script, return to the parent script, and delete the session variables.
(Incidentally, once the server.execute command finishes, the parent script can see its own variables again. Because of this, you can call sequential objT.display("filename.tpl") commands. But I digress...)
Right now, {include} compiles to <!--#include--!>. However, after a bit of searching, I found a site that has given me an idea. Using server.execute instead of #include may be a better solution, because you can have:
server.execute(strFilename)
server.execute(strDirectory & "/filename.tpl.asp")
server.execute(strDirectory & "/" & strLanguage & "/filename.tpl.asp")
...and such. However, the hard part will be how to compile an {include} file with variable components, because you don't know what the final filename will be until you run the code. (I think this is called "just in time" compiling.) Because we've shelled into a running script, and we can't see parent variables or code, I think the only solution is to somehow write the resolved filename to a session variable, exit the script, create the included file using the session variable, re-start the script, and go from there.
I have to think about this some more, but something in me tells me there's a way to do this!
Dermis passes variables from ASP to the compiled Dermis file using session variables. It then shells to the compiled file using the server.execute("filename.asp") command. When you use the server.execute command, the called script cannot see variables (or code) from the parent (i.e., calling) script. However, session variables are outside of the variable space. So, Dermis can copy ASP variables into session variables, server.execute the script, return to the parent script, and delete the session variables.
(Incidentally, once the server.execute command finishes, the parent script can see its own variables again. Because of this, you can call sequential objT.display("filename.tpl") commands. But I digress...)
Right now, {include} compiles to <!--#include--!>. However, after a bit of searching, I found a site that has given me an idea. Using server.execute instead of #include may be a better solution, because you can have:
server.execute(strFilename)
server.execute(strDirectory & "/filename.tpl.asp")
server.execute(strDirectory & "/" & strLanguage & "/filename.tpl.asp")
...and such. However, the hard part will be how to compile an {include} file with variable components, because you don't know what the final filename will be until you run the code. (I think this is called "just in time" compiling.) Because we've shelled into a running script, and we can't see parent variables or code, I think the only solution is to somehow write the resolved filename to a session variable, exit the script, create the included file using the session variable, re-start the script, and go from there.
I have to think about this some more, but something in me tells me there's a way to do this!
Thursday, November 19, 2009
Added {strip} tag
I added the {strip} tag! Just like Smarty, it removes leading and trailing whitespace around newlines (vbcrlf) in the compiled code, as well as the newlines themselves. The {/strip} tag is optional.
I've only tested it with one {strip} in a file. I'll test it with several soon, in the next few days.
I also added breadcrumbs to the documentation. No big deal, but it makes it look a bit nicer.
I've only tested it with one {strip} in a file. I'll test it with several soon, in the next few days.
I also added breadcrumbs to the documentation. No big deal, but it makes it look a bit nicer.
Dermis 1.0
Dermis 1.0 is out! I'm very excited!
Documentation finally looks decent!
After thinking about it for a while, I decided to call it 1.0 after the documentation was acceptable.
For the documentation, I modified a free layout I found called "Artificial Castling" (wrongly called Artificial Casting). Of course, I linked back to where I got it from in the footer, as the author requested.
It took me a few hours to write the code to distribute the single large documentation file into multiple files. It took me about as long to get the stylesheet code tamed.
I also think I may have a better workaround for using Dermis on IIS+XP: if the .tpl file is modified, just delete the old .tpl.asp immediately before writing the updated .tpl.asp file. It will only do this on XP (actually, non-"windows nt"), because Server 2003 doesn't have this problem, and I want to minimize the permissions needed for the system.
As you use it, let me know where you're from, and how you're using it!
Documentation finally looks decent!
After thinking about it for a while, I decided to call it 1.0 after the documentation was acceptable.
For the documentation, I modified a free layout I found called "Artificial Castling" (wrongly called Artificial Casting). Of course, I linked back to where I got it from in the footer, as the author requested.
It took me a few hours to write the code to distribute the single large documentation file into multiple files. It took me about as long to get the stylesheet code tamed.
I also think I may have a better workaround for using Dermis on IIS+XP: if the .tpl file is modified, just delete the old .tpl.asp immediately before writing the updated .tpl.asp file. It will only do this on XP (actually, non-"windows nt"), because Server 2003 doesn't have this problem, and I want to minimize the permissions needed for the system.
As you use it, let me know where you're from, and how you're using it!
Subscribe to:
Posts (Atom)