![Smarty Forum Index Smarty Forum Index](templates/smarty/images/phpbb2_logo.gif) |
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
View previous topic :: View next topic |
Author |
Message |
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Wed Dec 20, 2006 4:46 am Post subject: |
|
|
Hi all,
As boots mentioned, in order for us to make the code more maintainable, it would be helpful for us to deal with doc_raw's and doc_infos. My idea now is to allow both of them, but to change the underlying code so that both items share most of the same code. I know how I can do this, but I first want to make sure how exactly to set it up so that naming can be agreed upon and made stable or even frozen for future additions.
But before this, I'll mention the specific naming changes I've made.
Backwards-breaking changes
I changed 'doctype' to 'dtd', since it would adhere to the convention I started of giving internal changes the element name and external references a pseudonym (and thus relieving the memory load, especially on newcomers to SmartyDoc). I also changed my own 'stylesheet' to 'xsl' (it can only be external anyways), as 'xsl' is shorter, more specific, and easier to type. And as discussed, the one backwards-breaking difference of my already-published incarnation of SmartyDocB is carried over: use of the term "script" and "code" reversibly so that script allows injection of specified code into the head, whereas 'code' references (and with doc_raw possibly adds content to) an external file. So, therefore, now when adding to the head, use the name of the element (script, style, doctype), whereas when adding externally, use the alternate name (code, css, dtd). (XSL and XSD don't have options to target to the head--at least as far as I know--someone correct me if otherwise).
Oh, and should I just change all of the doc_raw's into "inject" as we were discussing earlier? It's easier to type than 'doc_raw' with its underscore and maybe more descriptive too (maybe we could even change 'doc_info' too, though maybe it helps on the memory that they both become the same way). But that's more backwards-compatibility breaking.
Reorganization of current code
If doc_raw (or "inject") and doc_info are made to share the same underlying code, a few issues are raised:
1) Since doc_raw is being made to be able to share the same constraints as doc_info as far as allowable attributes, I should mention that in XML mode (and possibly XHTML mode, as that can be extended too as I understand), we'll have to make the code so that it in fact won't enforce these constraints, since XML is not limited to the allowable elements and attributes.
2) Should we forego the use of a separate target attribute and all of the pseudonyms mentioned above and just allow the target to be specified after the element name (i.e., $renameto) as well as use the attribute such as maybe "_content"? This would lighten the memory load too, as one could forget about the pseudonyms.
Code: | // Note that one doesn't need to also have a "css" doc_info then for the following:
{doc_info script="" _content="alert('Hello');"} // Puts the script in the site-wide file since no script is specified
{doc_info script="head" _content="alert('Hello');"} // Puts the script in the head (might also have a body option for those using plain HTML)
{doc_info script="script.js" _content="alert('Hello');"} // Puts the content in the named file
{doc_info script="script.js"} // Links to the named file (but doesn't add any content to it)
{doc_info script=""} // Links to the site-wide file (but doesn't add any content to it) |
Of course, by being a block function, doc_raw assumes some content...
Code: | // Adds a script to the site-wide file (a target attribute might be clearer, but more redundant and cumbersome)
{doc_raw script=""}
alert('Hello');
{/doc_raw} |
Code: | // Adds a script to the head
{doc_raw script="head"}
alert('Hello');
{/doc_raw} |
Code: | //Adds a script to the specified file
{doc_raw script="script.js"}
alert('Hello');
{/doc_raw} |
I think the above is elegant and easy on the memory. So, to sum it up, how does it sound if I try to program it to allow it as described above (but then this would render the old pseudonyms invalid)?
best wishes,
Brett |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Thu Jan 11, 2007 9:17 am Post subject: |
|
|
Hi boots and all,
Well, I did mean to have the script ready, but due to the Taiwan earthquake blitzing network access here in mainland China, I wasn't able to work on the project.
However, I just started back on it today, and it looks like I'll need one or two more days to tweak things, but it's coming along fine.
I know this might throw a monkey-wrench in cross-compatibility, but I can be a bit compulsive in trying to finish things. Hopefully, there may be some way boots' future modifications can be reconciled with what I'm doing or vice versa.
The prefilter using the gzipping seems like a nice idea. Alternatively, the files created by SmartyDocB could be saved in that format (since the version I'm working on combines scripts/css from doc_raws and saves it to one main file (the file being possibly also targeted by other doc_raws in other files' templates).
One other nifty thing I think that this add-on can also be used for is for people who don't want to even bother with PHP (who just wanted to hand-code XML or HTML), but who like the ability to shuffle off CSS. One might have just one PHP file which allowed templates to be specified within a GET call, and then simply used SmartyDocB to display the template (e.g., example.com/portal/index.php?tpl=intro). Thus, one could simply add files like the following to the specified template directory rather than needing to add any PHP:
Code: | {doc_raw target="css"}
.h2 {font-style:italic;}
{/doc_raw}
<html><head></head><body>
<h2>A heading</h2>
</body></html>
|
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Thu Jan 11, 2007 9:28 am Post subject: |
|
|
Unresearched question: Is there any way to have a PHP script submit a string to some kind of display function to have it processed as though it were a template--without actually adding it to a real template? In other words, can one use Smarty's (or more specifically SmartyDoc's) features within PHP without using any templates? |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Sun Jan 21, 2007 1:53 am Post subject: |
|
|
Well, it is taking me longer than I expected to more thoroughly test and debug the program. I do think it is close to finished.
(I just edited this post since I solved the problem I was having.)
I'm also adding one other feature which I think is kind of fun.
In addition to being able to have a block of text shuffled off into the style head tag, an external file, or an external site-wide styles file, you will also be able to generate individual tags which do this.
For example, you can type
Code: | <<h1 clstyle="color:blue;" class="mainheading">>My heading<</h1>>. |
... and the style information will be shuffled off into the head's style tag.
If you don't specify a class, one will be auto-generated.
Likewise, you can do:
Code: | <<h1 istyle="color:blue;">>My heading<</h1>>. |
...to reference the style by id (and, in this case, since there is no specified id, an id will be autogenerated).
You can also do:
Code: | <<h1 estyle="color:blue;">>My heading<</h1>>. |
....and the style will be shuffled off with a reference to the whole "h1" element.
In addition to allowing one to place style information next to the tags (yet having it appropriately shuffled off), this can make for less redundant and more portable code, since one is not having to rewrite the id, class, or element information.
I'm also making it so that tags can be self-closed in this manner, or just be an opening or closing tag, etc. (though I expect that would be a less common need).
e.g.,:
Code: | {{hr clstyle="width:200px;" class="middlebreak" /}} |
You can change any of the above "style" references to "css" to shuffle it off into an external file (and, you can also use a "file" attribute to specify a specific file--otherwise it goes to your site's main script file).
e.g.,:
Code: | {{hr clcss="width:200px;" class="middlebreak" /}} |
You can also still use the actual "style" attribute since the names I added didn't conflict with it (you can also use "css" which will be converted into a "style" attribute--this is just a convenience so you can more easily add or subtract the preceding "e", or "cl" or "ecl" (when you want to reference the element and class). You can also add an attribute with the name "pseudo" to add a pseudo-class to the references.
For those who are curious, the shorthand code such as above is being converted via a prefilter into either a new block function I called {tagc} or a new function called {tag} which accepts the parameters like "istyle" that I mention above in addition to the target tag's own attributes.
Thus, the longhand version for the above would be like:
Code: | {tagc e=h1 istyle="color:blue;"}My heading{/tagc} |
or:
Code: | {tag e=h1 istyle="color:blue;" _con="My heading"} |
or, if for some strange reason, you prefer:
Code: | {tag o=h1 istyle="color:blue;"}My heading</h1> |
("e" could be changed to "o" to reflect just an opening tag or to "sc" to create a self-closing tag)
take care,
Brett
Edited to reflect the new default brackets |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Sat Feb 03, 2007 2:28 pm Post subject: |
|
|
Ok, we've been trying to paste in the code at the wiki for some time now without success, and I was going to post it here, but it seems I posted too much (though it was all right in the preview)...
Here's also the intro I wanted to post there too...I'll attach the informal readme as a separate post as well as the actual code in bits in subsequent posts...
It may slow things down a little in some ways (by the way, has anyone here seen or tried http://www.amfphp.org ), but I hope the ability to transfer less over the network (and all in one place) can make up for it (not to speak of the utility of it).
--------------------------------------------------
Code: |
This is a fork of ((SmartyDoc)) and requires PHP5+ and Smarty 2.6.10+.
[http://www.phpinsider.com/smarty-forum/viewtopic.php?p=22977#22977 Discuss at the forums]
Please note that this is still alpha and that the API will likely undergo further changes. Docs and additional information will be added when things stabilize. There is also more information in the forum discussion.
The purpose of this fork was originally to improve XHTML support and allow unescaped CSS (expanding on doc_raw) until such time as Boots is able to update his version and reconcile any parts of the fork that he wishes to use. However, the file has since expanded considerably to include strong support for XML (including XHTML), with the ability to shuffle off styles, scripts, XSL's, DTD's, XSD's, and parsed/unparsed entities (though external ones are not supported well in Firefox) not only into the head of the document (where appropriate and specified), but also into either a site-wide external file (with the advantage for styles of providing a consistent site-wide style pattern, and to take advantage of browser caching of stylesheets) or into specified files. Comments will also be auto-generated to denote which blocks were created by SmartyDocB and from what templates the code within originated(and these comments (C-style or XML-style depending) are also used when the script tries to recreate the content for a given template or set of templates), so if you edit the site-wide file, don't tamper with those comments! (also be sure to back-up any manual additions you make just in case the automatic rewriting process goes awry for some reason and overwrites your manual addition). One can even shuffle off one's personal notes into external file(s) in this way (with references to the notes file either showing up in the comments of the resulting X/HT/ML or not).
A number of other features have been added, especially to facilitate use of XML (e.g., CDATA, robots/processing instructions, targetting pre- or post-root, byte-order-marks, etc.). One can now add attributes to doc_raws (where appropriate--e.g., when shuffling off content to a style tag). A number of PHP extensions or external code can be made use of through this script (e.g., Tidy, XSL, Browscap (for detecting mobile phones to serve them XHTML Basic)) and this script also incorporates some new functions/modifiers that can also be used independently (e.g., various PHP5-compatible XSL conversions). The tag and tagc functions in combination with the prefilter allow one to make individual tags which will be printed out where they were called (unlike doc_info and doc_raw), but which will intelligently shuffle off style information into external files or the head. More features are detailed in the forums; questions on setup or use are also welcome as is any feedback.
The new version of this fork has also made some backwards-compatibility-breaking changes. For example, 'DOCTYPE' was changed to 'dtd' for definitions referencing an external file, while it is 'doctype' for internal doctype additions (following the convention we have started to have the tag-name (e.g., doctype, style, script) represent internal additions, with a pseudonym (e.g., dtd, css, code) representing externally-targeted items). As far as programmer-related changes, the bulk of doc_raw processing has been moved to its own 2 functions to facilitate code maintenance.
Be sure to doublecheck your resulting code, as the script, improperly configured, might add information you did not intend to be added (e.g., if you are adding a 'note' or 'comment' doc_info/doc_raw, and you do not specify that you are hiding the notes, they may appear referenced as comments in your code. We have tried to set the defaults, however, to be optimal for your privacy/security. Please also read the instructions at the top of the code below.
The system may be adding backslashes here to the code, even though they are not present at the original ((SmartyDoc)) page. If so, they would of course first need to be removed. |
Last edited by brettz9 on Sat Feb 03, 2007 2:44 pm; edited 1 time in total |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
|
Back to top |
|
vain Smarty Rookie
![](images/avatars/177509199346433691e3200.png)
Joined: 20 May 2006 Posts: 23 Location: Berlin / Germany
|
Posted: Wed Feb 21, 2007 5:52 pm Post subject: |
|
|
After some initalization trouble, i got it running.
The new functionalities are very helpful.
Excellent job, brettz9! Thank you!
Some "small" remarks:
a) There is an issue when trying to instantiate the class.
$tpl = new Render_SmartyDoc;
The error "Use of undefined constant file - assumed 'file'" is thrown.
Code: |
protected $doc_info_types = array(
.....
'notes' => array(
'renameto' => [b]file[/b]
|
b) This Class is very big, something about 3500 lines of code.
So my main question is: How can filesize be cutted down?
Would it be possible to divide it into smaller classes and functions?
I think some kind of refactoring for repeatedly done tasks is needed.
Maybe it's possible to make a RenderDoc Base Class and extend it by (sub)classes. Can some of the public functions (modifier/ blocks etc.) inside this class be pulled off and placed into the Smarty/Plugins Directory?
Base_RenderDoc
i)Extension: XML
ii)Extension: General Movements into target or file
--Extension for General Movements: build a main-css file, build js-file
--Extension for General Movements: auto-commenting (where things come from)
c) I would suggest to rename {docinfo} and {docraw} into something that expresses (with the commandname itself) what is done on the template.
I've seen you had discussed that already some posts above.
Instead {inject} i would propose {moveto}, but it's similar.
Code: | Set the Doctype
{setdoctype type= level=}
Make a Movement
{moveto file='somefile.css'} this {/moveto}
{moveto target=head} stuff for header {/moveto}
{moveto target=selfdefined_target_point} stuff for my target point {/moveto} |
d) If you take a normal index.html (with doctype, html head body tags) and displayDOC it, while $add_openclose = false, you can't doc_raw move anything correctly. i tried to move something from a subtemplate of index.html into the header using {doc_raw target=header} xy {/doc_raw}. it's moved to the top of the file in a new header, but not in the existing header. is this behaviour wanted?
i turned then $add_openclose on, removed the normal head and body tags (because now they were doubled) and used {doc_info/doc_raw} to move blocks to header and body? it's kinda scary to rebuild a working html this way, but works!
Again thanks a lot.
Regards, vain |
|
Back to top |
|
|
|
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
|
|