Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

SmartyDocB (fork of SmartyDoc)
Goto page 1, 2, 3  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Add-ons
View previous topic :: View next topic  
Author Message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Wed Sep 13, 2006 9:39 pm    Post subject: SmartyDocB (fork of SmartyDoc) Reply with quote

[ADMIN NOTE: This thread was split from the original SmartyDoc thread]

Hi boots and all,

I sure hope you're not getting tired of my bombarding this thread here...

I had a few more ideas I wanted to share...

I'd suggest changing addRaw and getRaw to be public rather than protected functions. By doing this, you'd even be potentially creating a whole new style of PHP HTML authoring. For those of us who lack the discipline (or, more accurately, those times we all do), sometimes doing things all mixed and hacked together can be easier (and perhaps in some cases, the code would be faster), at least for the short-term (which may be ok for some short-term projects). Even if one believes strongly (as I have come to) in the need for templating, having more potential approaches at one's disposal is also nice.

By whole new style, I mean that people could get by without anything besides a blank template (or maybe one with some standard headers), but shuffling things off into the addRaw targeted to the head, body, style, or script, from anywhere within their PHP script (maybe you've thought of this before, but thought I'd mention the idea).

Although with a conventional approach, this would probably not be worth it to the lazy programmer since we might only think we'd need to add a whole bunch of $smarty->assign's to our code, in actuality, if we were not concerned with templating, we could either build up variables which we then assigned to addRaw (or can I start using "inject" instead?) targeted to the body (the body tag could even be optional, making it a free-for-all dump).

Or, for the old-style scripter just using "print" statements everywhere, use ob_start at the top of the script and ob_get_clean at the end (and the $smarty->displayDoc) to inject that buffer all at once into the addRaw. Within the PHP script, addRaw assignments would be unaffected by the buffering approach, so sequencing would not need to be essential.

With either approach, the programmer can really be all over the place, PHP/HTML-wise, giving the choice to be as messy as desired. This might be useful for those folks not interested in templating, but who wanted to say put all CSS styles next to the relevant element in their PHP code, but targeted to the head (or external).

This brings me to another idea. A prefilter could be used to extract all inline style elements, replace it with a unique id (or class), then move the styles (referencing the auto-created ids/classes) to an external sheet.

This could even perhaps be done for XML (which generally depends on external stylesheets), detecting from the DTD what an id/class could be (see the note at http://www.w3.org/TR/2001/CR-css3-selectors-20011113/#id-selectors ) to facilitate referencing of the elements from CSS. Maybe the Tidy extension (with the clean option - see http://uk.php.net/manual/en/function.tidy-setopt.php and http://tidy.sourceforge.net/docs/quickref.html#clean ) could be tied in here as part of such a prefilter.

Although this is some more work, I think it would be very cool to achieve because I think one of the things keeping people back from using pure XML and CSS is the whole bit about needing external stylesheets. Doc_raw (and perhaps the prefilter and to a lesser degree addRaw) could really help with that.

For those who weren't aware, for modern browsers, you can define your own XML tag and use CSS to tell how to display it. Basically you use CSS's "display" to define your elements to behave like HTML (using "block" or "inline" to work like a div or span respectively).

So, with a modified doc_raw (besides the file-stitching, making the html and body tags optional), one could add one's own XML easily.

Code:

{inject target='style'}
book {display:block; color:red; position:abolute; left:30px;}
CD {display:block; background-color:blue; color:black;}
intro {display:block; font-size: x-large;}
{/inject}
<intro>Here are some good works of art and literature</intro>
<book title="War and Peace">War and Peace is a celebrated but long book</book>
<CD title="American Pie">My favorite artist Don McLean sings this great album, American Pie.</CD>


Or, one could use this approach with styling one's own RSS (perhaps the non-style aspects were already created for the purposes of an RSS feed).

You could even make a componentized template to make the template invokable as a whole from a PHP file in a specified or default directory--without needing to first create the PHP file manually. For example, maybe the following code could be added to the above XML, so one wouldn't even need to create the index.php file (the component would perform displayDoc too):

Code:
{access_point filename='index.php'}


With all of this becoming easier and more flexible, maybe expecting common users to build the Semantic Web isn't so pie-in-the-sky in that it can be easy to add semantics with the above tools/techniques.
Back to top
View user's profile Send private message
boots
Administrator


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

PostPosted: Thu Sep 14, 2006 4:17 pm    Post subject: Reply with quote

@brettz9: have you tried using/writing any RenderDoc modules yet?
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Sep 17, 2006 10:52 am    Post subject: Reply with quote

Hi boots,

I'm sorry to take a while to get back to you.

I wanted to finish the thing I was working on to answer your question, as it was related.

I finished the navigation bar/site map/breadcrumbs/link metadata & title auto-creator (which are all part of the W3C's accessibility guidelines). Rather than auto-detecting one's position in the physical file structure (as I have seen some breadcrumbs programs do), this one requires you to build an XML file to represent it. I preferred this approach as it did not confine a person to having/building a particular physical file hierarchy.

From the readme I just put up:

Quote:
The class requires PHP5 and installation of the SimpleXML extension (which is available and enabled by default in PHP5).

The file navbartest.php5 instantiates the class without Smarty, and thus the variables can be printed from within PHP. The file navbar.php5 does use Smarty and is intended to be used in conjunction with templates such as those included with this package (note that several of the templates may refer to SmartyDoc (and if you want to escape the literals at this point, you may need my own modified version of it, SmartyDocB), which is a great plugin for Smarty which I highly, highly recommend downloading).

I cannot provide a lot of explanatory documentation and it will probably involve some tweaking and study of the interface, but hopefully the code will be sufficient to get anyone going who is interested.


Edit note: I've changed the file location here:
I've put the file at https://sourceforge.net/projects/navbarcrumbs/ for anyone who's interested (LGPL like Smarty).

To answer your question more directly, this does not work as a module (I haven't used any modules, but I did take a moderate look at how they are implemented).

The class I just finished working on allows two extremes, but not the middle ground that the modules offer. What I mean is that if one does not pass the Smarty object to the class, it just returns the raw HTML, but if you do pass Smarty, it will create the Smarty assignments (whose names can be changes via the public API) and then you can control the exact display of the plugin content via one's templates (For the hierarchical menus and sitemaps, however, the HTML is all done on the PHP side and passed in one variable to Smarty, as I didn't have the energy to build the multi-dimensional array (and use of func/defunc plugin) to make these also templatable.

What is your reason for asking about the modules, by the way?

best wishes,
Brett


Last edited by brettz9 on Wed Feb 28, 2007 12:31 am; edited 1 time in total
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Sep 17, 2006 6:32 pm    Post subject: Reply with quote

One problem with getting the template name into the comments--although it is quite easy to do on a basic level (using your suggestion to add the resource_name to a global variable from fetchDoc), I don't know how it would be done to refer to included files.... I am guessing the compiler would need to store each file it was including into a global object variable?
Back to top
View user's profile Send private message
boots
Administrator


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

PostPosted: Mon Sep 18, 2006 1:32 am    Post subject: Reply with quote

Quote:
What is your reason for asking about the modules, by the way?

It was in reference to your post just before the one I made where I asked that...the intent I had for modules was to provide a way to allow php code interact with RenderDoc in a plugin style manner similar to Smarty's plugins -- and similarly to what you seemed to be proposing. The main idea is that the modules take care of some of the things you would likely need to do otherwise in your template. For example, I have a set of modules that I use to integrate Scriptaculous into my templates. When a template simply uses the module (eg: {client Effect=Appear for=myElement}) the module automagically inserts all references to needed javascript code and other needed resources in the propoer place in the resulting output document without you having to do so explicitly in the template.

As for the template name issue -- I'll have to think about it. Maybe extend the internal doc_info structure to track those?
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Sep 18, 2006 3:30 am    Post subject: Reply with quote

Quote:
As for the template name issue -- I'll have to think about it. Maybe extend the internal doc_info structure to track those?


But may I ask where in the code a given included template's information is referenced if not stored? If there are no object variables containing this information, maybe during compilation, something needs to be added to store it and then retrieve it in RenderDoc (pardon my ignorance here)?
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Sep 18, 2006 9:04 am    Post subject: Reply with quote

Here is my own hack to shuffle off the raw data to an external file.

Here are my remaining questions:
1) Template name include issue we were already discussing.
2) Is it more costly time-wise to write the file to disk (or even to check if the file exists) than the benefits of caching?

And though I allowed for cache id and compile id here, I think in many ways, it may be better to at least optionally do without them, since there are the issues of garbage collection and reusability.

In the future, I'd like to change the following to be able to append (if one doesn't already exist) an "import" line to the site's main stylesheet referencing this page's CSS stylesheet code, and then have this page's HTML import the main stylesheet instead of an individual one. This should facilitate caching a great deal, as the browser will only need to cache once for the whole site.

I added this to (the beginning of) fetchDoc to make the variables accessible within the outputfilter, but I am guessing you may want to access (and later reference) a different object variable, at least for the cache id and compile id?

[php:1:6611dd4136] $this->_smarty_vars['template'] = $resource_name; // Added so that the template name would be accessible within the outputfilter
$this->_smarty_vars['cache_id'] = $cache_id;
$this->_smarty_vars['compile_id'] = $compile_id;[/php:1:6611dd4136]

From the last version of SmartyDocB, it was also necessary to change this assignment to include "css" (and I also added "code" for future use): [php:1:6611dd4136] static $target_choices = array('head', 'body', 'style', 'script', 'css', 'code');[/php:1:6611dd4136]

[php:1:6611dd4136] // process doc_raw targetted for an external stylesheet
if (isset($this->doc_raw['css'])) {
$ext_doc_source = '';
// Add reference in stylesheet comments to location of template file
foreach ($this->doc_raw['css'] as $raw) {
$ext_doc_source .= "/* From: {$this->_smarty_vars['template']}*/\n";
$ext_doc_source .= $raw."\n";
}

// Revert back temporarily converted CSS brackets
$ext_doc_source = str_replace(array('[[', ']]'), array('{', '}'), $ext_doc_source);

// Clean up cache and compile id's for use in file name
if ($this->_smarty_vars['cache_id']) {
$cache_append = "_caid_".rtrim($this->_smarty_vars['cache_id'], '|');
$cache_append = str_replace('|', '__', $cache_append);
} // end if
if ($this->_smarty_vars['compile_id']) {
$compile_append = "_coid_".$this->_smarty_vars['compile_id'];
} // end if

// Prepare for file writing
$cssext = '.css';
$cssdir = '/css/';
$file = $cssdir.urlencode(str_replace('.tpl', '', $this->_smarty_vars['template']).$cache_append.$compile_append).$cssext;
$file_dir = $this->file_dir;
$put_file = $file_dir.$file;

// Check if file exists and if not, write to file
if (!file_exists($put_file)) {
file_put_contents($put_file, $ext_doc_source);
} // end if

// Create stylesheet reference
$doc_source .= "{$indent}<style type=\"text/css\">\n\t/*<![CDATA[*/\n";
$doc_source .= "@import \"{$file}\";\n";
$doc_source .= "\t/*]]>*/</style>\n";
}[/php:1:6611dd4136]
Back to top
View user's profile Send private message
chidera
Smarty Rookie


Joined: 08 Dec 2004
Posts: 22

PostPosted: Sun Dec 03, 2006 2:55 am    Post subject: Reply with quote

Hi,

I've been struggling a bit with this for a while now....

When I have the following in my template file:
Code:
{doc_info script="http://www.mydomain.com/scripts/myscript.js"}


I get the following output:
Code:
<script type="text/javascript">/*<![CDATA[*/
http://www.mydomain.com/scripts/myscript.js
/*]]>*/</script>


Why is that?

I'm not even sure whether or not it's "good"....but it doesn't seem to work.

This is what I expected:
Code:
<script type="text/javascript"> src="http://www.mydomain.com/scripts/myscript.js"></script>


Or this, too, perhaps:
Code:
<script type="text/javascript"> src="http://www.mydomain.com/scripts/myscript.js" />


Any ideas?

Thanks,
_________________
Travis
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Sun Dec 03, 2006 11:00 am    Post subject: Reply with quote

From what you are saying, it looks like you are using SmartyDocB from http://smarty.incutio.com/?page=SmartyDocB In this case, I have changed the behavior of "script", but you can follow the instructions below.

I presume you mean to say you expected this:

Code:
<script type="text/javascript" src="http://www.mydomain.com/scripts/myscript.js"></script>


You should use the word "code" in this case instead of "script", so use this instead:

Code:
{doc_info code="http://www.mydomain.com/scripts/myscript.js"}


Using the word "script" (which is the result you got) would allow you to put your javascript code within the script tags in the head of your document--not as an external file.

For example, you could use the following to add a greeting into the head of your document...

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


But, generally speaking, what you are doing in adding an external file is a better way to go, since you can reuse an external file more easily, as well as get faster performance if you are reusing the script at your site (since your browser will cache the script in its memory and you won't have to load up a long list of script commands each time you visit a page using that script). The same is true for using "css" (for external stylesheets) instead of "style" (for adding styles to the head). Notice that this behavior is different in SmartyDocB than it is in the original SmartyDoc, as is the fact that you can use curly brackets in SmartyDocB without escaping them.

Also, FYI, for internal scripts (and stylesheets) (which is not what you want, but which is what you got), the "/*<![CDATA[*/ ... /*]]>*/" block is used for XHTML (the replacement for HTML and a kind of XML) to inform the parser (browser) to not treat things like greater-than signs or ampersands as if they were XML tags or entities. In plain HTML, <!-- --> was used to allow older browsers to not be confused by the text, but these cannot be used for XML in this case because XML parsers/browsers will ignore their contents entirely.

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


Joined: 08 Dec 2004
Posts: 22

PostPosted: Mon Dec 04, 2006 3:46 am    Post subject: Reply with quote

Brett,

Thanks for the great reply.

Yes, I'm using SmartyDocB right now. I'm anxious to see the various "forks" pulled back together so that I can feel good about using "one of one" instead of "one of several"....if you know what I mean.

I looked at the line that you presumed I meant to say that I expected. Yes, that's what I expected, but I didn't see any differences between what you typed and what I typed. Whatever the case, you hit the nail on the head.

Thanks, by the way, for explaining the difference between using "code" and using "script". It was very helpful.

You make mention of "the fact that you can use curly brackets in SmartyDocB without escaping them." What do you mean by this? Is it too much trouble to ask for a short/simple example?

Oh, one more question...Do you know if SmartyDocB works with Template Lite (http://templatelite.sourceforge.net/)...? I'm considering looking into using that to see if I can't squeeze a little more speed out of the template engine part of my application. Right now, that's up to 90% of the overall time. Neutral

Again, thanks for the great help.

Take care,
_________________
Travis
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Dec 04, 2006 6:33 am    Post subject: Reply with quote

Hello chidera,

As far as the forks being pulled back together, that all depends on boots, since he is by far the more qualified programmer (not to mention formally associated with the project, as it seems)... Though at the hour you emailed me, I had just started back work on SmartyDocB after a hiatus in order to see whether I can figure out how to work it so that the raw contents of styles and scripts can be shuffled off into one external file for the whole site (for when you want the data in a site-wide external file but when you want the flexibility to be able to store specific styles and scripts across various templates).

As far as the difference of what you had expected, there was an extra greater-than sign closing the "script" tag prematurely. I.e., <script type="text/javascript"> src="..... won't work because there shouldn't be that sign before "src". No big deal, just wanted to point that out if you were new to scripting or something.

What I mean by using curly brackets without escaping them is that if you do something like this in SmartyDocB...

Code:
{doc_raw target="style"}
   par.beginning {text-indent: 10px;}
{/doc_raw}


or

Code:
{doc_info style="par.beginning {text-indent: 10px;}"}


... Smarty doesn't get messed up with the { and } inside of the doc_raw block (which are normally used by Smarty for variable delimiters). (I have a prefilter running that looks inside of these blocks converting them temporarily into something that doesn't look to Smarty like a variable, and then after processing the variables converts the temporary filler back to curly brackets.)

You can also use curly brackets within a "script" doc_info or doc_raw. In case you were curious, doc_info and doc_raw (whether for "script" or "style") here are not really acting any differently. Boots mentioned here that he was considering getting rid of doc_raw entirely, though I am personally partial to having a block function as well as I think it is more elegant to have a separate opening and closing tag separating long blocks of styles or script commands.

I don't know anything about Template Lite, but I presume by looking at the site that there would be no need to use it and Smarty together, unless you mean whether the Template Lite templating code were a subset of Smarty's templating code (I don't know). Anyhow, though I am a relative newcomer to Smarty, I also have seen a performance cut when it is used. But, as the manual points out, an accelerator can supposedly help out a lot.

FYI, although the manual doesn't mention this one, since eAccelerator and the other previously popular open source accelerators have gone inactive (and are not compatible with PHP5 if you are using that), I have become interested in the PEAR package "APC". I haven't tried it yet, but this has some very prominent PHP developers actively working on it over some time, so I presume it should be good. Also, be sure you are taking advantage of caching if at all possible. I saw another accelerator "Ioncube" which is free (but not open source, and which doesn't work with PHP5 as I recall) and had advertised that it could speed up Smarty apps by 10 times, and as I recall seeing APC being benchmarked as fairly comparable to Ioncube, I am hopeful this can make Smarty a more viable option for me, without needing to learn a whole new templating system (and forego Smarty's great features and advantages). Feel free to share your experiences.

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


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

PostPosted: Mon Dec 04, 2006 6:21 pm    Post subject: Reply with quote

Just as a quick note: eAccelerator is neither inactive nor is it incompatible with PHP5. In fact it is quite a nice module. APC, of course, has gotten a lot of attention since its maintenance was actively picked up by Rasmus and Yahoo in general. There is also another accelerator by the author of lighttpd but I can't recall its name. Any opcode cache will be a useful addition to a Smarty based site.

As for Template Lite, I have no idea if you can use these addons with them. My understanding is that while Template Lite was originally a fork of Smarty, it has been completely rewritten. Assuming it still supports filters and plugins, this stuff should work or at least be made to work, but you'll have to tackle that yourself.

As for folding all the forks back into a single project -- that's on my todo list Smile In the meantime, I (humbly) suggest purists to continue using my version and to those who are looking for all the latest features to use brettz9's SmartyDocB which has more features than the versions I have released.

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


Joined: 07 Jul 2006
Posts: 93

PostPosted: Mon Dec 04, 2006 6:28 pm    Post subject: Reply with quote

My sincerest apologies about my mistake on eAccelerator... I truly remember investigating it a while ago and recalled reading about some problems with it with my configuration at least as well as something related to PHP5. However, I see from the website that the first stable release compatible with PHP5 looks like it just came out in October, so maybe that is why I mixed it up. Anyhow, my sincere apologies. I should have double-checked before stating that...

Brett
Back to top
View user's profile Send private message
chidera
Smarty Rookie


Joined: 08 Dec 2004
Posts: 22

PostPosted: Mon Dec 04, 2006 8:28 pm    Post subject: Reply with quote

Hi Brett/boots,

Thanks for the replies.

Regarding bringing the forks back together...I would normally say that I'm a purist, but I was also looking at some of the features that were only found in SmartyDocB....So I'm DEFINITELY looking forward to your (boots) getting that checked off your todo list. Wink

I didn't notice the extra greater-than sign. It was definitely a typing/copy-paste mistake or something since I know it doesn't belong there. Good eyes, though, because I couldn't see it until you pointed it out.

OK. I'm happy to hear about not having to escape the curly brackets when using doc_raw. I have been using doc_raw together with literal to get what I want/need. I'll keep that in mind and play around with it a bit the next time an opportunity presents itself.

For whatever it's worth, I like the idea of keeping the doc_raw block available. I would prefer to NOT have to use it, but having it there for when I need it would make me feel better.

I'll look into the different accelerators that you guys mentioned. I really don't know much about them, but I will probably want to check them out at some point in time. Thanks for your insights/corrections/etc.

Well, that's it for now. Thanks again, you two, for your time and help.

Take care,
_________________
Travis
Back to top
View user's profile Send private message
brettz9
Smarty Regular


Joined: 07 Jul 2006
Posts: 93

PostPosted: Wed Dec 20, 2006 4:41 am    Post subject: New version of SmartyDocB Reply with quote

Hi all,

In the past few days, I've made some major changes to SmartyDocB.

Beyond just adding features, I think I've learned a bit more (also from studying boots' code more deeply) to be able to provide a more easily maintainable set of code, and due to which I hope boots might not even feel the need to fundamentally rework it.

I plan to release the code as soon as possible, but I first need to get some feedback on naming conventions in order to finish the code properly. I'll ask these questions in my next post, but first, I can announce the features so you can see what this will be able to do.

1) Shuffling off content into head, files, or one site-wide file
SmartyDocB has been expanded significantly to offer the ability to shuffle off content (such as CSS, Javascript, and now also XML Schema, DTD's, and XSLT) from anywhere within your templates (including included ones) into now not only the head of the document (where appropriate) but also into an external file, or into one site-wide file (e.g., stylesheets).

SmartyDocB also automatically encloses the content one is thus shuffling off within comments that indicate from which template that code originated (so when you look at the resulting source code of your XHTML, XSL file, etc., you will be able to find out from where that CSS, script, etc. came.

The external files can also be edited independently (as long as one does not edit within the labeled blocks created by SmartyDocB) so that you can reference and reuse these external files by any page. Whenever SmartyDocB has the file-writing mode on, it will erase all old automatic additions made for the given invoked template and prepend the new additions to the top. This prepending is done in order to make sure that when testing the resulting page, the effects of cascading done by other style/etc. instructions within the file can take effect. So, if you accidentally tried to add new style instructions which override instructions added earlier to the site-wide file manually or by another SmartyDocB page (e.g., due to your unintentionally naming a class within the current file with the same class name as that in another file), your current additions wouldn't take effect (and thus ruin other pages that also reference the site-wide file), and by seeing your changes not take effect, you'd be forced to change the new style additions (and/or the class/id names) or otherwise reconcile them with the styles/class names, etc. on the other pages, if you wanted to see your changes work as intended.

When one finishes templating changes, one can turn the live file-writing option off, so that the main purpose of this site-wide feature (browser caching) can take effect without being slowed down by file-writing!

In a similar fashion, I've also added the ability for one to add one's personal notes within the code and have it shuffled off (optionally being referenced within comments in the XML/XHTML) into one external file or specified external files (e.g., a plain text file--or even PHP)--in case you wanted to say leave your comments in the right place in your code but also have your notes/todos/etc. viewable as one single document (also with the auto-notation mentioned above indicating which blocks come from which templates). You could conceivably use these notes for anything else too, like a grocery list or whatever (remember not to have the hidden option off for this file or save it publicly or otherwise people could read your personal notes on the web!).

2) XML support

The new version also offers XML support (beyond just XHTML) and some fixes. The script can run now without it printing out <body>, or other XHTML-specific tags. DTD's, XML Schema, and XSL are all supported (though if anybody knows whether XML Schema, or DTD's for that matter, can have multiple instances on one page, please let me know ASAP so I can fix it for the next version--or at least know that it can't be done!). Note: I have since investigated this, found the answers, and changed the script accordingly...Multiple namespaced schemas are possible, as is the use of one internal and one external DTD together but not more than one of each. Header options/defaults for plain XML have now been added in addition to those for XHTML and HTML.

3) Tidy support and mobile phone support

Added Tidy support and allow (with the addition of the Browscap class) the ability to auto-detect mobile devices (or detect a call via a GET request), and, if XSL is also installed, the script can optionally auto-transform one's document into XHTML Basic--the W3C language for mobile phones--using an XSL stylesheet (after optionally tidying one's original X/HTML).

4) Fixes and configuration options: XSL, regexps, whitespace

Did some fixes:
a) use of the PHP5 XSLT extension (if loaded and available); as I couldn't test my code for this earlier, the previous version didn't work with server-side transformations, but now XSL stylesheets should be able to be pre-transformed server-side where specified. b) The regexps are more clean (and should be faster now).

Added many configuration options including whitespace stripping.

5) Smarty variables within doc_raws

Altered prefilter to allow variables or config. variables within doc_raws, but marked as [- ... -] or [# ... #] respectively.

6) Doc_raw with other attributes

Although I haven't programmed this feature yet due to the decisions yet to be agreed upon consensually (as I'll explain in the next post), I plan to have this next release allow additional attributes to be added to doc_raws. For example, if you have some Javascript data you want shuffled off into an external file, you could specify the attributes 'defer' or 'charset' on the targeted doc_raw (as you can already do on the doc_info). Note: I have since added the ability for doc_raws to have the same attributes as doc_infos, with the exception of generic targets which create no elements such as "head_pre" or "root_post".

7) Revival and expansion of PHP4 XSL functions/block functions/modifiers

Piggy-backing on those extra functions available on the Smarty wiki, I made versions of these XSL transformation functions to work for PHP 5.

Now, whether as a modifier, regular function, or block function, you can use a variable or filename in any position to represent the XML or XSL. (The function is named XSLT instead of XSL to avoid a name conflict.)

Thus, the following would work (with $xsldoc or $xmldoc being variables with the content or referencing a filename; in place of the variables, you could also place quoted text to represent the content or filename):

Code:
// As a Function:
{xslt xsl=$xsldoc xml=$xmldoc}


Code:
// As Modifiers:
{$xmldoc|xsl:$xsldoc}
{$xsldoc|xml:$xsldoc}


Code:
// As Block functions:

{xsl xml=$xmldoc}
...XSL content here...
{/xsl}

{xml xsl=$xsldoc}
...XML content here...
{/xml}


Note that these allow you to perform server-side transformations on just part of the page. There are also the doc_info's and doc_raw's that let you specify a stylesheet (or shuffle off content into an external stylesheet or site-wide stylesheet) to apply to the whole page.

Questions or feedback are welcome.

best wishes,
Brett

Edited on January 24th (edited comments added in bold) to reflect new developments.


Last edited by brettz9 on Wed Jan 24, 2007 2:05 am; edited 1 time in total
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Add-ons All times are GMT
Goto page 1, 2, 3  Next
Page 1 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