Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.

SmartyDoc
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    Smarty Forum Index -> Add-ons
View previous topic :: View next topic  
Author Message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Aug 06, 2006 10:33 am    Post subject: Reply with quote

Hi,

I tried updating the old SmartyDocInfo class (changing public/private/protected to var, removing "public" from in front of functions, and changing the constructor to the name of the class) to work with PHP4, but got an internal server error (but only when I actually used rather than simply included the class--in my case to make a doc_raw to add CSS).

This class could be so useful in allowing the easy separation of content from formatting.

Though it's not much, I'd be willing to spring for $25 if you could successfully modify one of the files to get doc_raw working for PHP 4...It'd be especially helpful if a dedicated function could be added to avoid the need for adding {literal} and style tags too..

I have to use PHP 4 due to a bug in PHP 5 (handling multidimensional arrays of this length: $arr[$a][$b][$c]).

thanks,
Brett
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5613
Location: Toronto, Canada

PostPosted: Tue Aug 08, 2006 2:18 pm    Post subject: Reply with quote

Hi brettz9.

Sorry, I personally have no intention of porting to PHP4 (but feel free to do so -- it will require that you change things to properly deal with PHP4 object reference semantics and you will have to work-around PHP5 only object features that were used).

FWIW, I have no problem with $arr[$a][$b][$c] under PHP5 (I'm on 5.1.4 atm).


Best,
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Aug 13, 2006 4:33 am    Post subject: Reply with quote

Hello,

Although I realize you're working on a new version, boots, I was wondering what your (or others') opinions on the following modifications or ideas for modification would be.

Modifying SmartyDoc.class.php:
[php:1:832431a365]
if (isset($this->doc_raw['head'])) {
foreach ($this->doc_raw['head'] as $key => $raw) {
if ($key == "style") {
$raw = str_replace(array("[[", "]]"), array("{", "}"), $raw);
$doc_source .= "<style type=\"text/css\">\n\t/*<![CDATA[*/\n{$raw}\n\t/*]]>*/</style>";
} else {
$doc_source .= "{$raw}\n";
}
}
}[/php:1:832431a365]

Adding CSS via:
Code:

{doc_raw key=style}
h2 [[color:red;]]
{/doc_raw}


This would allow a less cumbersome addition of styles, I think.

(I know the use of "key" is probably not the best (in case you wanted to allow more than one style doc_raw), but I was just piggy-backing on the existing framework to get it to work without messing things up too much)

I suppose a prefilter might be used to allow the use of curly braces within this special style doc_raw without {literal} tags, such that the curly braces would be converted into something else before the compilation stage (and then converted back to curly braces later by SmartyDoc, such as I have for the code mod above).

I also wonder whether you have considered using separate functions for each element. For example {body onload='blah();'} rather than {doc_info body='blah();'}. I think that may be more easy-to-remember/shorter.

As far as the PHP5 issue I mentioned in my last post, in case anyone wanted to know, the problem with $arr[$a][$b][$c] I had was due to offsets. In PHP5, you can't set $arr[$a][$b] = $var1; (if $var1 is a string, for example) and override it later with $arr[$a][$b][$c] = $var2, as it will treat the latter as $var1[$c] (and array-style offsets on strings are no longer allowed).

As far as my XSLT idea, I see this has been done to some degree for http://smarty.incutio.com/?page=XSLTBlockFunction (albeit for a PHP4 XSLT extension). Another useful functionality I think could be integrated together with your function is http://smarty.incutio.com/?page=DOCTYPEHeaderPlugin

The functionality your script and these provide are all very broad feature sets, I think, and I would highly recommend these be added by default to a future version of Smarty, if at all possible. It is not of course just a niche who needs to have a doctype or CSS added!

I'd be happy to help somehow if I could, but if you're planning a new release sometime (and aren't adding it as you develop it to the wiki, etc.), maybe I shouldn't spend too much time on this now?

best wishes,
Brett
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Aug 13, 2006 4:37 am    Post subject: Reply with quote

Also, do you have any thoughts on allowing users to generate some of the header data via a script and integrate it with the header data generated by SmartyDoc?

thanks,
Brett
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5613
Location: Toronto, Canada

PostPosted: Sun Aug 13, 2006 7:14 am    Post subject: Reply with quote

brettz9 wrote:
Also, do you have any thoughts on allowing users to generate some of the header data via a script and integrate it with the header data generated by SmartyDoc?

Hi.

How do you mean? By users do you mean template users? The SmartyDoc plugin API does much of that already and the {doc_raw} blocks allow similar from templates, but I suppose you have a different idea in mind?
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Aug 13, 2006 7:43 am    Post subject: Reply with quote

Ahh..I'll have to take a look at the API then...But as far as doc_raw, if I add my own header, apply that to the template, and then use doc_raw also, I end up with two full headers (and bodies too, as I recall)

Also, since they were posted right after each other, you might not have noticed that I also just made a longer post previous to the last post (to which you did respond)...

best wishes,
Brett
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5613
Location: Toronto, Canada

PostPosted: Sun Aug 13, 2006 8:36 pm    Post subject: Reply with quote

Hi brettz9.

Ah I see. Well, I can't really see how to stop someone from inserting a tag from within their templates. I suppose you could filter them and either remove the manually inserted tags and/or retarget their content into doc_info commands -- but I'm neither here-nor-there on that.

As for your css suggestion, its actually pretty good. I already support the "target" attribute which atm only accepts "head" and "body" but adding in targets for "style" and maybe "code" would be useful. Thanks for the idea, I'll see what I can do to accomodate it.
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Aug 14, 2006 9:42 am    Post subject: Reply with quote

boots wrote:
Ah I see. Well, I can't really see how to stop someone from inserting a tag from within their templates. I suppose you could filter them and either remove the manually inserted tags and/or retarget their content into doc_info commands -- but I'm neither here-nor-there on that.


Yeah, my bad. No need to filter them, I just wasn't aware of the API to add them in from the PHP side (which is more reasonable anyhow).

As far as additions to the code, thought I'd put what I could together in case it would be helpful.

1) About the doc_raw, in case one wishes only to use doc_raw, I believe this line in smarty_outputfilter_SmartyDoc:

[php:1:aa4eb626bf]if (!empty($smarty->doc_info)) {[/php:1:aa4eb626bf]

...should be:

[php:1:aa4eb626bf]if (!empty($smarty->doc_info) || !empty($smarty->doc_raw)) {[/php:1:aa4eb626bf]

2) In order to facilitate people converting to your script, I'd recommend changing the function (or adding an alias) of "displayDoc" to simply "display". This is discouraged below by boots

3) Below are a bunch of additions to allow relevant XML headers, XML declaration, XML stylesheet instructions, html and head definitions, as well as both doc_info and doc_raw inline styles and scripts (including the prefilter to deal with curly braces).

First, add this variable at the beginning of the class:
Code:
    public $encoding = "UTF-8";  // Used for generating headers


The following allows the <?xml version="1.0"?> and <?xml-stylesheet type="text/xml" href="file.xsl"?> tags, with all possible attributes (besides those no longer used in XHTML) as defined at http://www.w3.org/TR/2004/REC-xml-20040204/#dt-xmldecl and http://www.w3.org/TR/xml-stylesheet/ :

[php:1:aa4eb626bf] , 'xml' => array(
'renameto' => 'version'
, 'optional' => array('encoding', 'standalone')
, 'defaults' => array()
)[/php:1:aa4eb626bf]

and

[php:1:aa4eb626bf] , 'stylesheet' => array(
'renameto' => 'href'
, 'optional' => array('type', 'title', 'media', 'charset', 'alternate')
, 'defaults' => array('type'=>'text/xml')
)
[/php:1:aa4eb626bf]

and the following (the XHTML namespace here (and below, if no doc_info is specified for 'html') is put as the default as it is likely to be changed, as it works with XHTML 1.0 and 1.1 (though it will probably not work with XHTML 2.0 when that comes out--the latter will also require additional attributes we can add at that time))

As xml:lang might be a more frequent need than say "dir", I put that as the renameto for these:

[php:1:aa4eb626bf] , 'html' => array(
'renameto' => 'xml:lang'
, 'optional' => array('xmlns', 'dir', 'xml__lang', 'lang', 'version')
, 'defaults' => array('xmlns'=>'http://www.w3.org/1999/xhtml')
)
, 'head' => array(
'renameto' => 'xml:lang'
, 'optional' => array('profile', 'dir', 'xml__lang', 'lang')
, 'defaults' => array()
)[/php:1:aa4eb626bf]

Also, instead of 'onload', I think adding 'body' with access to its other attributes (as taken from the W3C's page, including deprecated attributes) would be suitable, especially since one cannot use SmartyDoc along with body being added at the template level (as body is generated by SmartyDoc):

Code:
    , 'body'=> array(
          'renameto' => 'onload'
        , 'optional' => array('id', 'class', 'lang', 'dir', 'xml__lang', 'title', 'style', 'onunload', 'onclick', 'ondblclick', 'onmousedown', 'onmouseup', 'onmouseover', 'onmousemove', 'onmouseout', 'onkeypress', 'onkeydown', 'onkeyup', 'bgcolor', 'background', 'text', 'link', 'vlink', 'alink')
        , 'defaults' => array()
        )



And, although the doc_raw option (updated and added below) would be better for longer additions, use of doc_info might still be suitable if more control over the attributes (for style or script) was desired (all attributes listed as possible at http://www.w3.org/TR/REC-html40/present/styles.html#h-14.2.3 and http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1 ):

[php:1:aa4eb626bf] , 'style' => array(
'renameto' => null
, 'optional' => array('type', 'media', 'title', 'lang', 'xml__lang', 'dir')
, 'defaults' => array('type'=>'text/css')
)[/php:1:aa4eb626bf]

and:
[php:1:aa4eb626bf] , 'code' => array(
'renameto' => null
, 'optional' => array('type', 'charset', 'defer')
, 'defaults' => array('type'=>'text/javascript')
)[/php:1:aa4eb626bf]

Maybe another 'optional' should be 'xml__space'? (language is deprecated, so I didn't see a need to add it and maybe should be removed from 'script' too? Even though something is required (like "type" in either of the above), it seems that they still get put under 'optional' too, so that they can be modified from the default.

Despite what I did above, for consistency, it might be clearer to rename what you have as "script" or "css" so that the inline versions will always have the same name as the tag itself (or always not). For example, "script" and "style" could always refer to internal uses, whereas the pseudonyms "code" and "css" could refer to external ones or vice versa. This would break backward compatibility though.

The following is taken from http://smarty.incutio.com/?page=DOCTYPEHeaderPlugin (presuming no copyright is ok or not relevant for a common piece of code) and could be placed (perhaps conditionally) right before generation of the doctype signature.

[php:1:aa4eb626bf] // first check if type is XHTML or not and if so, whether the browser accepts application/xhtml+xml content type

if ($this->doc_info['DOCTYPE']['FAMILY'] === 'XHTML') {
if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml")) {
header("Content-Type: application/xhtml+xml; charset=".$this->encoding);
}
elseif (stristr($_SERVER['HTTP_ACCEPT'], "application/xml")) {
header("Content-Type: application/xml; charset=".$this->encoding);
}
elseif (stristr($_SERVER['HTTP_ACCEPT'], "text/xml")) {
header("Content-Type: text/xml; charset=".$this->encoding);
}
//Send Opera 7.0 application/xhtml+xml
elseif (stristr($_SERVER['HTTP_USER_AGENT'], "Opera 7") || stristr($_SERVER['HTTP_USER_AGENT'], "Opera/7")) {
header("Content-Type: application/xhtml+xml; charset=".$this->encoding);
}
//Send everyone else text/html
else {
header("Content-Type: text/html; charset=".$this->encoding);
}
}
else {
header("Content-Type: text/html; charset=".$this->encoding);
}

// Send javascript header
if (isset($_doc_info['code']) || isset($_doc_info['script']) || isset($this->doc_raw['code'])) {
header("Content-Script-Type: text/javascript");
}[/php:1:aa4eb626bf]

Immediately following this then:

[php:1:aa4eb626bf] // process 'xml' (XML Declaration) doc info
if (isset($_doc_info['xml'])) {
$doc_source .= "<"."?xml";
foreach ($_doc_info['xml'] as $a=>$v) {
if ($a == 'version') {
$docadd = " {$a}=\"{$v}\"";
}
elseif (!empty($v)) {
$docadd2 .= " {$a}=\"{$v}\"";
}
}
$doc_source .= $docadd.$docadd2;
$doc_source .= "?".">\n";
}[/php:1:aa4eb626bf]

and then

[php:1:aa4eb626bf] // process 'stylesheet' (xml-stylesheet) doc info
if (isset($_doc_info['stylesheet'])) {
foreach ($_doc_info['stylesheet'] as $stylesheet) {
$doc_source .= "{$indent}<?xml-stylesheet";
foreach ($stylesheet as $a=>$v) {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
$doc_source .= "?>\n";
}
}[/php:1:aa4eb626bf]

Then, replace this code:
[php:1:aa4eb626bf] // generate the doctype signature
$doc_source = $smarty->getDoctypeSignature() . "\n<html>\n<head>\n";[/php:1:aa4eb626bf]

with this (note that a namespace declaration is required for XHTML :
[php:1:aa4eb626bf] // generate the doctype signature
$doc_source .= $smarty->getDoctypeSignature() . "\n";

// process 'html' doc info
if (isset($_doc_info['html'])) {
$doc_source .= "<html";
foreach ($_doc_info['html'] as $a=>$v) {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
$doc_source .= ">\n";
}
elseif ($this->doc_info['DOCTYPE']['FAMILY'] === 'XHTML') {
$doc_source .= "<html xmlns=\"http://www.w3.org/1999/xhtml\">\n";
} // end elseif
else {
$doc_source .= "<html>\n";
} // end else


// process 'head' doc info
if (isset($_doc_info['head'])) {
$doc_source .= "<head";
foreach ($_doc_info['head'] as $a=>$v) {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
$doc_source .= ">\n";
}
else {
$doc_source .= "<head>\n";
} // end else[/php:1:aa4eb626bf]

Later, such as after the meta declaration (which by the way, should probably be moved to the beginning of the head, because, as I recall, any encoding set there should precede the display of at least the title if not other head elements):
[php:1:aa4eb626bf] // process 'style' doc info
if (isset($_doc_info['style'])) {
$doc_source .= "{$indent}<style";
foreach ($_doc_info['style'] as $a=>$v) {
if ($a != '_content') {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
}
$_doc_info['style']['_content'] = str_replace(array("[[", "]]"), array("{", "}"), $_doc_info['style']['_content']);
$doc_source .= ">/*<![CDATA[*/\n{$_doc_info['style']['_content']}\n/*]]>*/</style>\n";
}[/php:1:aa4eb626bf]

and

[php:1:aa4eb626bf] // process 'code' (script) doc info
if (isset($_doc_info['code'])) {
$doc_source .= "{$indent}<script";
foreach ($_doc_info['code'] as $a=>$v) {
if ($a != '_content') {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
}
$_doc_info['code']['_content'] = str_replace(array("[[", "]]"), array("{", "}"), $_doc_info['code']['_content']);
$doc_source .= ">/*<![CDATA[*/\n{$_doc_info['code']['_content']}\n/*]]>*/</script>\n";
}[/php:1:aa4eb626bf]


and the updated doc_raw targetting the style tag and script tag:
[php:1:aa4eb626bf] // process doc_raw targetted for the style tag
if (isset($this->doc_raw['style'])) {
foreach ($this->doc_raw['style'] as $raw) {
$raw = str_replace(array("[[", "]]"), array("{", "}"), $raw);
$doc_source .= "<style type=\"text/css\">\n\t/*<![CDATA[*/\n{$raw}\n\t/*]]>*/</style>";
}
}[/php:1:aa4eb626bf]

and your idea for the script/code tag:
[php:1:aa4eb626bf] // process doc_raw targetted for the script tag
if (isset($this->doc_raw['code'])) {
foreach ($this->doc_raw['code'] as $raw) {
$raw = str_replace(array("[[", "]]"), array("{", "}"), $raw);
$doc_source .= "<script type=\"text/javascript\">\n\t/*<![CDATA[*/\n{$raw}\n\t/*]]>*/</script>";
}
}[/php:1:aa4eb626bf]

Finally, replace this:
[php:1:aa4eb626bf] // process special attributes for the body tag
$doc_source .= "</head>\n<body";
if (isset($_doc_info['onload'])) {
$doc_source .= ' onload="';
foreach ($_doc_info['onload'] as $body) {
$doc_source .= "{$body['onload']};";
}
$doc_source .= '"';
}
$doc_source .= ">\n";[/php:1:aa4eb626bf]

with:
[php:1:aa4eb626bf] // process 'body' doc info
$doc_source .= "</head>\n<body";
if (isset($_doc_info['body'])) {
foreach ($_doc_info['body'] as $a=>$v) {
if (!empty($v)) {
$doc_source .= " {$a}=\"{$v}\"";
}
}
}
$doc_source .= ">\n";[/php:1:aa4eb626bf]

For prefiltering (note that the regexps dictate that the "target" or "style"/"code" attributes must come before any secondary ones):

[php:1:aa4eb626bf]public function smarty_prefilter_SmartyDoc($source, &$smarty) {
// Prepare delimiters for insertion into regexps below
$ldelim = preg_quote($this->left_delimiter, '@');
$rdelim = preg_quote($this->right_delimiter, '@');

$source = preg_replace('@'.$ldelim.'\$([^}]*?)'.$rdelim.'@', '-~#-~$1-#~-', $source); // Adding a temporary replacement to hide the genuine smarty variables from the other curly brace items
$source = preg_replace('@'.$ldelim.'#([^}]*?)'.$rdelim.'@', '--#-~$1--~-', $source); // Adding a temporary replacement to hide the genuine config variables from the other curly brace items

$callback = create_function('$matches', "return \$matches[1].str_replace(array('{', '}'), array('[[', ']]'), \$matches[3]).\$matches[4];"); // This approach is better than using preg_replace with the e modifier, since preg_replace auto-performs addslashes() which we do not want here

$source = preg_replace_callback("@(".$ldelim."doc_info style=(['|\"]))([^\\2]*?)(\\2.*?".$rdelim.")@s", $callback, $source);
$source = preg_replace_callback("@(".$ldelim."doc_info code=(['|\"]))([^\\2]*?)(\\2.*?".$rdelim.")@s", $callback, $source);
$source = preg_replace_callback("@(".$ldelim."doc_raw target=(['|\"]{0,1})style\\2[^}]*?".$rdelim.")(.*?)(".$ldelim."/doc_raw".$rdelim.")@s", $callback, $source);
$source = preg_replace_callback("@(".$ldelim."doc_raw target=(['|\"]{0,1})code\\2[^}]*?".$rdelim.")(.*?)(".$ldelim."/doc_raw".$rdelim.")@s", $callback, $source);

$source = preg_replace('@-~#-~(.*?)-#\~-@s', $this->left_delimiter.'$$1'.$this->right_delimiter, $source); // Reverting back temporary replacement from above to allow smarty variables to work
$source = preg_replace('@--#-~(.*?)--\~-@s', $this->left_delimiter.'#$1'.$this->right_delimiter, $source); // Reverting back temporary replacement from above to allow config variables to work
return $source;
}[/php:1:aa4eb626bf]

and in __construct() :

[php:1:aa4eb626bf]$this->register_prefilter(array($this, 'smarty_prefilter_SmartyDoc'));[/php:1:aa4eb626bf]

Now, the following works:
Code:
{doc_raw target=style}
h2 {color:red;}
{/doc_raw}


Code:
{doc_raw target=code}
alert('hello');
{/doc_raw}


as would:
Code:
{doc_info style='h2{color:red;}'}


or:
Code:
{doc_info code="alert('hello');"}


Last edited by brettz9 on Wed Sep 06, 2006 5:40 pm; edited 20 times in total
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Aug 14, 2006 11:35 am    Post subject: Reply with quote

In addition to the code above I just posted, there is this which I think will allow PHP5 to automatically transform the output according to the referenced XSL file:

Modify the stylesheet code above to add one pre_xform boolean for use with the later code:
[php:1:6f88cb3a26] , 'stylesheet' => array(
'renameto' => 'href'
, 'optional' => array('type', 'title', 'media', 'charset', 'alternate', 'pre_xform')
, 'defaults' => array('type'=>'text/xml')
)[/php:1:6f88cb3a26]

Modify the stylesheet code above to avoid printing out this new (internal-use-only) attribute and to add two arrays which will keep track of the transforms for later use:
[php:1:6f88cb3a26] foreach ($stylesheet as $a=>$v) {
if (!empty($v) && $a != "pre-xform") {
$doc_source .= " {$a}=\"{$v}\"";
}
}
$xsl[] = $stylesheet['href']; // for XSL processing below
$pre_xform[] = $stylesheet['pre-xform']; // for XSL processing below
$doc_source .= "?>\n"; [/php:1:6f88cb3a26]

Finally, perform the transforms. Place the following immediately before "return $doc_source":
[php:1:6f88cb3a26] if (extension_loaded('xsl')) {
$xslproc = new XSLTProcessor;
$xslcount = count($xsl);
for ($i = 0; $i < $xslcount; $i++) {
if ($pre_xform[$i]) { // make sure the template designer in fact wants the stylesheet transformed server-side
$xslproc->importStyleSheet($xsl[$i]); // attach the xsl rule
$doc_source = $xslproc->transformToXML($doc_source);
}
}
} // end if[/php:1:6f88cb3a26]

I haven't had a chance to test all of this yet (though my regexps in the previous post did work), but I can let you know if I do, and I do think it should work. Note: I have now tested all of the code (besides the server-side XSLT transforms) and it seems to be working fine.

Subsequent Additon:

And of course, in $DOCTYPES, under 'XHTML' (as I guess you probably were going to add already), append the following after 'Frameset':

Code:
        , '1.1' => array(
           'signature' => '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">'
          )


Last edited by brettz9 on Wed Sep 06, 2006 6:16 am; edited 6 times in total
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5613
Location: Toronto, Canada

PostPosted: Mon Aug 14, 2006 3:25 pm    Post subject: Reply with quote

whew: thanks for the code and comments. I'll have to digest it. I just wanted to comment quickly on the idea of renaming displayDoc to display -- the short answer is that I don't think it is a good idea. Without time to get into details, there is a significant difference between the two -- namely, it relies on fetchDoc() rather than fetch() (which display relies on) and the difference there is that fetchDoc() temporarily registers the output filter for the duration of its call. Now, if you ONLY ever call display() or fetch() once from your PHP script to render a completed document, then you might get away with having displayDoc() renamed to display(); on-the-other-hand, if you need to render pieces of the document separately and then have them stitched together in a final document producing call, then having access to both methods is important.

I'll try to get to your comments sometime this week. Please feel free to continue adding more details and thanks for your efforts with the code!
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Thu Aug 31, 2006 4:32 am    Post subject: Reply with quote

Just-made modifications above:

1) Html and Head were added to $doc_info_types to allow control of their attributes and of course, as a result, I also added relevant code subsequently when building the document (there is also an elseif added when this occurs to automatically include a namespace for XHTML documents if no doc_info was specified for 'html')
2) I made a note about how meta should probably precede title (and others?) so that any meta encoding can first take effect.

best wishes,
Brett
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Fri Sep 01, 2006 3:36 pm    Post subject: Reply with quote

Hello,

Boots, you said this earlier...
Quote:
One thing I was pondering is the idea of automatically stitching linked css/js files and {doc_raw} items into single files (one for JS, one for CSS) based on the current compile_id and cache_id -- or perhaps to allow rules determine how/when files are stitched. (The idea there is to improve client performance by limiting the requests made for a given call while still permitting some client caching by not just simply stuffing everything into <script> and <style> elements in the <head>.)


One point first to clarify...I'm not sure I understand what you mean by "limiting the requests made for a given call" and why it seems you are contrasting that with (client) caching.

As far as compile_id and cache_id, it seems these can be null at some points in their lifetime (such as if there is no caching). For the sake of reusability (one benefit of external code/stylesheets), it seems it may be better not to inevitably append a (potentially variable) cache_id/compile_id, no? It seems that the template designer (or site developer) could conditionally supply the script/style generation with a URL (depending upon the section in which they appear), as I don't imagine the stylesheets would be varying as much as a cache would, no? (and if it were, the URL could be made variable by the designer/developer according to whatever conditions were desired). $smarty.template would seem to be handy to get the name of the current template to be used as at least a base. Maybe the PHP equivalent of $smarty.template ($smarty->_smarty_vars['template'] ?) could be used within the function to detect the template name if no file is specified.

As far as the general idea of it, I think it would be a real handy feature to have. It'd be very nice not to have to fumble around between different documents during the editing phase (i.e., just stuff it at the top of each template (if not out of necessity then to create a helpful convention)), yet have the benefit of allowing client caching of the external script/stylesheets. Despite the advantages of external sheets, if there are others out there like me, having the extra steps of creating, saving/uploading, and referencing can be a deterrent to adding this benefit.

best wishes,
Brett
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Sep 04, 2006 5:32 pm    Post subject: Reply with quote

Ok, now that I've tested this thing a bit more, I realized some bugs needed to be fixed (now altered in the code above) and the following also need to be changed:

I added the following array to be accessible from within addRaw and getRaw. I defined it as static since I didn't think this would be likely to be changed, but as I'm kind of new to OOP, I'm not sure whether this would in fact be suitable or not. I figured it should since we are not likely to dynamically change this information anywhere.

Code:
static $target_choices = array('head', 'body', 'style', 'code');


Within addRaw and getRaw, change
Code:
        if ($target !== 'head') {
            if ($target !== 'body') {
                $target = 'head';
            }
        }


to:

Code:
        if (!in_array($target, self::$target_choices)) {
            $target = 'head';
        }


Change the addRawHeader, getRawHeader, addRawContent, getRawContent functions to these, with the target being passed with head (or body) as the default rather than only head (or body) being passed (as they probably were intended to have originally been anyways). This change is necessary now that the code has the style and script tags as possible (head) targets
Code:
    public function addRawHeader($content='', $key=null, $target='head')
    {
        $this->addRaw($content, $key, $target);
    }

    public function getRawHeader($key=null, $target='head')
    {
        return $this->getRaw($key, $target);
    }

    public function addRawContent($content='', $key=null, $target='body')
    {
        $this->addRaw($content, $key, $target);
    }

    public function getRawContent($key=null, $target='body')
    {
        return $this->getRaw($key, $target);
    }


Also, very importantly, within smarty_block_doc_raw, the following must be changed (i.e., both instances of $target changed to $params['target']), as $target is not defined anywhere in this function:

Code:
        if (isset($params['target']) && strtolower($params['target']) === 'body') {
            $smarty->addRawContent($content, $key, $target);
        } else {
            $smarty->addRawHeader($content, $key, $target);
        }


to

Code:
        if (isset($params['target']) && strtolower($params['target']) === 'body') {
            $smarty->addRawContent($content, $key, $params['target']);
        } else {
            $smarty->addRawHeader($content, $key, $params['target']);
        }


Lastly, the line in addInfo here:
Code:
if ($allowed == 'title' || $allowed == 'base' || $allowed == 'DOCTYPE') {


should be changed to:
Code:
                if (in_array($allowed, array('title', 'base', 'xml', 'html', 'head', 'body', 'DOCTYPE'))) {


I may still have some kinks to work out, but I am getting the testing to work now finally...
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Wed Sep 06, 2006 6:23 pm    Post subject: Reply with quote

Hello,

Boots, what would you think if I added a link from your SmartyDoc wiki page to my own version of it--at least as an ongoing draft? This thread is probably not the best place for me to be revising my work continuously (though I really have it functioning now (as described above), at least).

Everything should be backwards compatible with the way you have it too, except I really think 'script' and 'style' should be aligned together to denote the same type (e.g., inline adds to the tags of those names) whereas 'code' and 'css' could be of the other type (e.g., external JS or CSS stylesheets). I am also eager to add functionality for the doc_raw contents, using the same nomenclature just described to make it optionally shuffled off to an external file, but if you think you may be able to catch up and get to that too, let me know (not to mention reconcile this with the additional work you said you had already done since your wiki posting).

take care,
Brett
Back to top
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5613
Location: Toronto, Canada

PostPosted: Wed Sep 06, 2006 6:39 pm    Post subject: Reply with quote

Hi Brettz9!

Sorry for the lack of replies -- I hope I haven't slowed your progress Smile I would in-fact prefer that you fork a different version at the wiki; that would give me some more time to find some cycles for the next release that I would like to make but have been unable to work on. I'm very glad you are still working on this and I have appreciated your many comments, code suggestions and additions. I'm sure to incorporate some of your ideas/code and if your work gets far enough ahead of my own, I'd be favourable to replacing my codebase with yours. Still, before that happens, I would appreciate having my code intact at the wiki so that I could both compare our versions and have a chance to do another release.

That said, if you do decide to create a new wiki entry, plesae do edit my wiki entry to cross-reference yours.

BTW, I'm glad that you decided on staying BC while I also appreciate that you may want to change some of the semantics to move forward. In the end, I don't think it is a good idea to diverge our codebases too much, so if I fall too far behind, you should probably just pick-up the reins and run with it.

best regards!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Add-ons All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP