However, I am having problems editing the wiki from here (China). I can't get access to even view the pages for some reason without using a proxy, and I can't make edits, apparently because of the proxy. I see you have to type in the "s" word, but when I did my page's edits weren't reflected in the preview and when I then added my changes to the current version window (as I was being told that there was an edit conflict) and tried to submit, I received an SQL error (for security I won't send that now unless you prefer). The error message said to contact wiki == a_t incutio.com but my email to it was undeliverable.

As far as BC, I think I will go ahead then and change "script" to "code" and "code to "script" so that style/script (the tag names) can be inline and css/code can be external. I also will remove the "onload" functionality if that is ok, and go with the superset "body" (I could alternatively keep the "onload" working for BC if you prefer and "deprecate" it so to speak). Other than that, I see no reason to make any other breaking changes.

Just for others' reference, I have added SmartyDocB (with cumulative series of modifications including the backwards-compat-breaking changes for script/code and onload here: http://smarty.incutio.com/?page=SmartyDocB

I have the following template which I am including in another template, assigning it to a variable, and then using eval on it (in order to allow the {$var...}'s that can occur in the links to be converted) It all works as intended except when caching is on. Then it doesn't seem to like the doc_raw, as it complains about my nocache tags (which I have registered). The specific error message follows:

It seems to be something with doc_raw (at least my modified version of it?), as it acts this way even if I remove all the contents from within the doc_raw

I know I can move doc_raw (at least for this case where I need eval), but it would be nice to keep it compartmentalized with the CSS targeted for the head right there alongside the template for which the CSS is intended...

Well, the unescaped brackets do work now that I added a prefilter (that's what SmartyDocB is about). In other contexts it worked fine.

My problem was that I had not thought to do the simple step of just capturing the segment not including the doc_raw and then eval that...Now it's working fine...Sometimes it's the easiest things...

The reason that a custom resource would not work (I think) is that I am using SimpleXML to selectively retrieve data from an XML file--some of it needs to first be processed in PHP but it is still sent with Smarty variables that I'd like to be processed with Smarty.

Let me tell you, by the way, that it is now fun to code CSS... Without having to escape and with the ability your plugin offers to add it within any template (which makes sense and much easier to read, I think, alongside the classes for which it is intended), I can now get over my grudge with the W3C (as I like adhoc solutions) that even the style tag became deprecated!

For those who are concerned that splitting the doc_raws all over the place would make it hard to find the source of the styles when viewing the resultant stylesheet (e.g., if you have a lot of templates working together-and even moreso if we stitch all the CSS files of the site together via SmartyDoc in the future (using imports)), I had the idea that one could simply add comments to those doc_raws indicating the current template file (one could even simply use {$smarty.template}), etc. (we could even have SmartyDoc do that automatically (by obtaining the template name via the Smarty variable in the output filter as you and I discussed and adding that (optionally) to the comments so that it was clear from which file a given doc_raw originated).

Well, the unescaped brackets do work now that I added a prefilter (that's what SmartyDocB is about). In other contexts it worked fine.

My problem was that I had not thought to do the simple step of just capturing the segment not including the doc_raw and then eval that...Now it's working fine...Sometimes it's the easiest things...

Ah, cool. Glad you got it sorted.

brettz9 wrote:

Let me tell you, by the way, that it is now fun to code CSS... Without having to escape and with the ability your plugin offers to add it within any template (which makes sense and much easier to read, I think, alongside the classes for which it is intended), I can now get over my grudge with the W3C (as I like adhoc solutions) that even the style tag became deprecated!

For those who are concerned that splitting the doc_raws all over the place would make it hard to find the source of the styles when viewing the resultant stylesheet (e.g., if you have a lot of templates working together-and even moreso if we stitch all the CSS files of the site together via SmartyDoc in the future (using imports)), I had the idea that one could simply add comments to those doc_raws indicating the current template file (one could even simply use {$smarty.template}), etc. (we could even have SmartyDoc do that automatically (by obtaining the template name via the Smarty variable in the output filter as you and I discussed and adding that (optionally) to the comments so that it was clear from which file a given doc_raw originated).

Yes, keeping things together logically was one of the motivations for the addon -- I'm glad you find it as useful as I do I agree that it really begs for some sort of stitching mechanism as we have been discussing. I like your ideas on adding in comments. In all, thanks for helping advance this little bit of code into something more robust and generally more useful. I will definately be incorporating some of these ideas -- but don't wait around for me and my unpredicatable time-commitments...I'm anxious to see what else you do with your fork. Lastly, thanks for the nice comments...it is very rewarding to get positive feedback like that.

I had another idea I'd like to propose concerning doc_raw. Although a bit unconventional, {doc_info} works on an overloading basis -- that is, only one smarty tag is used but it acts differently based on the parameters it is given (as opposed to providing separate tags for each behaviour). For me, this was an important "feature" int the design because it allows: a generalized way to handle tags, all done in a single place in the code; ease of adding new behaviours (imho) since you can do so by simply adding a new definition to the doc_info_types array instead of having to implement a complete new plugin; ease for the designer who only has to know one tag (again, that is simply imho). As such, I've never really liked the fact that {doc_raw} was a seperate tag type in SmartyDoc (or really RenderDoc as I call it now) which required its own codepath.

So here is the idea I would like to propose: deprecate doc_raw and instead add a new {doc_info} overloading triggered by a new parameter "inject". It would take all the other parameters that doc_raw supports. eg:

Code:

{doc_info inject=$some_raw_data target=head}

where $some_raw_data could be created via capture or include, or something similar:

Taking it a step further, rename {doc_info} to something along the lines of {renderdoc} as I was never overly happy with "doc_info". I actually think that it may even better be called {inject} since that is what it essentially does. In that case, the parameter for deprecating {doc_raw} could be "raw", eg:

I agree that it really begs for some sort of stitching mechanism as we have been discussing.

For the public record here, I'll excerpt from our email on this:

Quote:

boots wrote:

I realized afterwards that you were probably asking in regards to automating the creation of single js/css files for inclusion. Of course, these need also be keyed by cache_id and compile_id. As it happens, when I was thinking about that problem awhile back, I was considering doing something similar to what I outlined in my last email.

brettz9 wrote:

Yes, I see why one would also want the cache_id and compile_id's. However, I was thinking that there may be advantage to optionally ignoring them and just adding any style doc_raw's (via a prefilter) to a stylesheet automatically. Here's why:

1) In many cases, the CSS won't change conditionally anyways (though the designer, for readability, might end up putting the blocks within conditionals) (though of course there would be some cases when it would).
2) One of the benefits of external stylesheets is of course reusability, and having id #'s appended to the saved files would be cumbersome for referencing (not to mention reusing).
3) The benefit external stylesheets provide as far as caching, is, as I have read and understand, that if a site has the same stylesheet for all its pages, it will cache that one page upon its first visit, and though it has that additional overhead during the first visit, visits to subsequent pages using the same stylesheet will be speeded up.

What I was thinking might be a nice approach to solve the above issues would be, for one, of course to save each template's own file as described above (One could also avoid the need to save files each time by testing to see if the file exists and whether the user has specified a public class variable to overwrite any previously existing scripts with that name or append to any such files (giving the option to people to work manually with the file). But, specifically to address #3 above, when processing individual templates, the script could add a line to the main stylesheet as well (as indicated perhaps also by a public class variable) adding a CSS import line (if the stylesheet had not already been referenced in the file). This could also allow manual editing of the main file, yet would ensure that any templates using style doc_raw's could automatically expand the main CSS file (and that the main script file could probably be read more quickly by SmartyDoc without the actual styles being placed there).

Javascript could be done in a similar manner, maybe using something like this (if no official "include"/"import" yet exists for JS): http://krijnhoetmer.nl/stuff/javascript/include-javascript/ . One could also simply check to see whether a whole block of code already existed and if not append it, but that would be more cumbersome, not to mention ugly.

We could add an attribute to doc_raw to also allow the user to manually append a specified prefix for the stylesheet/script instead of it being entirely with or without cache/compile ids.

So in summary, besides being able to stitch together documents for the current file, we could even have SmartyDoc/RenderDoc optionally coordinate stitching together into one file (one each for CSS and JS respectively) the script and style documents for the whole site.

boots wrote:

Lastly, thanks for the nice comments...it is very rewarding to get positive feedback like that.

I had another idea I'd like to propose concerning doc_raw. Although a bit unconventional, {doc_info} works on an overloading basis -- that is, only one smarty tag is used but it acts differently based on the parameters it is given (as opposed to providing separate tags for each behaviour). For me, this was an important "feature" int the design because it allows: a generalized way to handle tags, all done in a single place in the code; ease of adding new behaviours (imho) since you can do so by simply adding a new definition to the doc_info_types array instead of having to implement a complete new plugin; ease for the designer who only has to know one tag (again, that is simply imho). As such, I've never really liked the fact that {doc_raw} was a seperate tag type in SmartyDoc (or really RenderDoc as I call it now) which required its own codepath.

While I do see it'd be easier to code (I was too lazy myself to readd all of the potential attribute processing to doc_raw (targed for style or script) as existed for doc_info) and my own additions to the code actually began because I saw it was easy to add functionality to your code, though I hate to say it, I think for the designer it would be a little less cumbersome (and more intuitive for HTML'ers) to use {body}, {meta}, etc. (since they still need to know these element names as attributes with doc_info anyways, but with the latter, they also have to type "doc_info"), even though doc_info does make it more intuitive to find documentation as long as the tags are not part of the main Smarty release (how about that anyways?--I think this would be a nice inclusion to the regular release, as I've suggested before).

boots wrote:

So here is the idea I would like to propose: deprecate doc_raw and instead add a new {doc_info} overloading triggered by a new parameter "inject"...where $some_raw_data could be created via capture or include, or something similar...

While I like your suggestion as an addition (the targed attribute wouldn't even be needed in most cases, as it could be discovered via the doc_info type, including for "script" (which is now deprecated from being in the body) and "style", targeting it to be within the respective tags), while also allowing other (non-external) attributes to be added, unlike for doc_raw), if it is at all possible, I think it would be great to keep such a block function as doc_raw (even if you rename it). I think allowing these makes the template not only more succinct, but is also less code-like and thus I think should be easier for designers too. I'd actually like to see every function in Smarty (where possible) be available (automatically?) as both a block function and individual tag/modifier (e.g., "eval" as we discussed in another thread could also be made into a block).

As far as lightening the memory load for designers, maybe a system-wide convention for blocks vs. plain tags would be helpful. If it is ok to keep two parallel items going, maybe appending something like "_block" would helpful (e.g., inject_block).

boots wrote:

It would take all the other parameters that doc_raw supports.

I hope that would include the new target "style" and "script" (and for external targeting, "css" and "code")... (Do you agree by the way that this BC-breaking naming change is worth it--so that the HTML names (style/script) can always refer to internal and the pseudonyms to external sheets?)

boots wrote:

Taking it a step further, rename {doc_info} to something along the lines of {renderdoc} as I was never overly happy with "doc_info". I actually think that it may even better be called {inject} since that is what it essentially does.

Either would be fine by me...I think "inject" is less technical-sounding, and more suited for the designer-friendly Smarty (not to mention, as you say, more clear). (I like removing the underscore in any case, as it takes an extra step for my text editor to option-arrow over it.)

boots wrote:

I'm anxious to see what else you do with your fork.

Two things in mind for now:

1) I've added special attributes for meta and link so that the auto-detected http-accept type (e.g., application/xhtml+xml or text/html, etc. depending on the browser ) and the user-set charset can be automatically added to attributes. i.e., to allow building types such as:

The above is also in the spirit of standards compliance, with the latter type meeting accessibility regulations and tying in to the Smarty-friendly navbar/breadcrumbs/sitemap generator class that I'm hoping to finish soon.

2) Consider reworking things a little so that any XML document could be built up with the script (e.g., not adding "</body></html>" if the document is declared as XML or, better yet perhaps, auto-appending closing tags at the end, depending on the doc's root).

3) If we get file stitching going, allowing client-side XSL to be shuffled off too, and although not directly related to yours, update the also cool (server-side) XSLT plugins at the wiki (modifier and block functions) to work with PHP5.

This thread has been split to allow Brettz9's fork (SmartyDocB) to be discussed independently. Brett has put a lot of work and added many new features to SmartyDocB while SmartyDoc has not been updated for quite some time. The goals of SmartyDocB are somewhat different than SmartyDoc. I still intend to update and improve SmartyDoc but I do not plan on a new release in the immediate future.

While SmartyDoc is still as useful as ever, you may want to look at SmartyDocB to see if it better suits your needs.