![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: Mon Feb 26, 2007 6:59 am Post subject: |
|
|
Hi Vain,
Sorry I didn't get back to your earlier... Yahoo seems to always put my Smarty-related emails into the bulk folder....
Really great to hear it basically worked for you. I didn't know if anyone would be brave and resourceful enough to try it out with all the cut-and-pasting I made you do!
I've got a Sourceforge page reserved now and besides planning to release the code I put there (I've made a couple of changes myself that aren't reflected above yet and still a couple more I know I need to make), I am working on some DocBook/XHTML documentation (using the script to help me write it of course!) that I'd also like to put up there once it's done.
To your points...
a) As far as the "undefined file constant" error, I have no idea about that. I see that I just added the @ error suppression mark to it! I noted in my comments (in my instantiation page where I had this line) that the error came up even if I made a class_exists test). I really don't know about that one. Anybody else know?
b) As far as class size, yes, you're right, it is too big.
Here are some possibilities:
1) Some of the XSL functions could definitely be moved into their own plugin files (actually, they can be used independently of this program). I just packaged them so one wouldn't have to install them separately. But it is not a bad idea to separate them.
2) If you don't mind tampering with the Smarty code (be aware that you have to either force recompiling or delete your compiled files when doing debugging with that stuff--that always tripped me up when I was testing), in all the overriding functions, I've noted which lines I've added, so you could get rid of the overriding functions and just make the changes directly to the Smarty code (the compiler class).
3) Yes, it would be possible to eliminate a lot of bulk in the outputfilter by processing the doc_infos in one common function as I did for doc_raws. However, as with the doc_raws, there'd be a lot of work involved in doing this because it is hard to find the common ground between the types and make the function general enough to work as one function and specific enough to deal with all the nuances of each type. If you or anyone else has any inclination to work on the code to make it better, let me know... I'm finding Subversion (at least on Windows) with Tortoise SVN, on at least a basic level, is pretty easy to do...
c) Yes, I think "moveto" is a very good idea. Clear, simple, and short enough. And it is a good time to make the change. I just have to change my old code too! Though maybe I could work in some aliases... Were you also suggesting "setdoctype" as a replacement for "doctype"/"dtd" with doc_info and doc_raw or was that just an example? Although it might be nice to have separate names for each functions, as I recall boots mentioned earlier in this thread, it would make the code harder to maintain. The doc_info (and doc_raw) allows it to all work within one or two functions.
d) Instead of "header", do you mean "head"? If I understand you correctly, this behavior threw me for a loop too when I first tried boots' original program. The script doesn't detect if you have already manually added things like a doctype, etc. In fact, you probably shouldn't manually add them. By 'manually', I mean done without a doc_info or doc_raw. $add_openclose adds in some common XHTML tags for you, but if you have this set to false, you can either add specific doc_info's or doc_raw's named/targeted to the dtd, html tags, etc. (or stuff them in a generic doc_raw with target=head, target=root_pre, or target=body, etc.), or from PHP use the appropriate addRaw function to thrust it in there. Let me know if that doesn't address your problem. It would be nice to autodetect any manually added html tags, etc., but this script doesn't do that (and it would involve more regular expressions, which are slower than most types of processing). So, I guess we just have to go with the doc_info/doc_raw for that stuff.
By the way, was that intentional that you excerpted some code ('notes' in the doc_info_types array)?
Also, it'd be nice to know features you are specifically using or plan to use? Thanks!
Brett |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Mon Feb 26, 2007 3:19 pm Post subject: |
|
|
Hi.
I would like to split this topic to separate the SmartyDocB discussion from the originial SmartyDoc thread. It seems like SmartyDocB has grown up and deserves its own thread at this point
Any suggestion where to make the split -- or if it is a good idea to do so? I was thinking starting at Brettz9's post of September 8, 2006 or there abouts but I don't want to act from fiat.
Cheers.
Last edited by boots on Tue Feb 27, 2007 1:48 am; edited 1 time in total |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Feb 27, 2007 1:45 am Post subject: |
|
|
Sure, boots. Whatever you think is best is fine. And thanks again for your help.
best wishes,
Brett |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Feb 27, 2007 7:17 am Post subject: |
|
|
Oh, Vain, sorry, I see now that you were highlighting the code since that was the source of the "undefined constant file" error. I thought it was referring to a "constant file" or something instead of a constant named "file". I was looking for the error in my instantiation page, to no avail.
thanks,
Brett |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Feb 27, 2007 12:00 pm Post subject: |
|
|
Howdy folks,
Well, I've made the fix Vain mentioned and added his suggestion for the 'moveto' alias and made some other additions/fixes of my own.
To still use doc_info and doc_raw as the names (for backwards-compatibility), you need to add 'doc_info' and 'doc_raw' in that order into the constructor. Otherwise, it will use the new defaults 'info' and 'moveto'.
Although I agree about file size, I do want to be able to maintain the code as simply as possible without requiring any copying into different directories, so I've kept it as one file for now.
You should also know that I added:
1) An XML entity moveto function which optionally allows tab-delimited text to have multiple entity files created and which can be optionally converted server-side (useful at least until such time as Firefox and other browsers support external XML entities). This feature could be used for localizing a website without needing a database.
2) XInclude function. This is probably pretty useless right now I know (since even Firefox doesn't support this), but I wanted to offer every possible general-purpose XML function I could think of...
Vain or anyone else who downloaded this before, I think the only other change of importance I made was to swtich $rewrite_docraw_on to false by default. Although this may frustrate some newcomers (who'll think the script is not working), I also don't want to have constant file rewriting going on for people (including for my own site).
I added this release at Sourceforge: https://sourceforge.net/projects/smartydocb/
You can directly go to the download page at https://sourceforge.net/project/showfiles.php?group_id=188824
Boots, I hope I haven't added extra work for you by adding yet another post to migrate (I presumed the forum software lets you migrate them fairly easily though)...
best wishes,
Brett |
|
Back to top |
|
vain Smarty Rookie
![](images/avatars/177509199346433691e3200.png)
Joined: 20 May 2006 Posts: 23 Location: Berlin / Germany
|
Posted: Mon Mar 19, 2007 5:40 pm Post subject: |
|
|
hello all, hello brettz9,
as boots said, this plugin is grown up. putting this up on sourceforge is a good step to work on ideas and develop it further.
currently i have set up a testing template-set with it and it's working really nice. basically i'm amazed by the powerful "moveto" feature of this plugin
and will include it immediatly in our cms, when development reached a somehow stable point.
i have not tested any xml/xsl functionality, because at this time, i don't really know what the benefits for our cms would be. but i'm open to using them.
yes, documentation is needed. i would suggest pear or phpdoc commenting style, which would ease the process of creating a developers docu automatically. the next step would be a manual with usage examples.
i would suggest a directory with working examples as a feature demonstration.
to answer on the discussed points:
a) thanks for fixing the "constant file error".
b) size of class:
the argument is, that the class is easier to maintain, if all things are kept together in one file. but for me it's better to keep things spearated from each other. i think, especially now with the svn, the files are bundled together good enough.
i vote for splitting up the file by setting up the same directory structure as of the smarty class and putting the files in there.
so the user just copies the directories of the plugin with all files into the smarty folder and that's it.
1) XSL - functionality is (as said) independently usable and should be separated.
2) Override of Smarty Compiler Code
Although i made the changes directly at first time, shortly after that smarty was updated.
from that point of view one can live with the overhead, knowing,
that the change in code has not to be applied again if smarty updates.
(When redesigning and rethinking Smarty v3, the feature of this override should be added.
It's important to know where things come from, even more when having a feature like "moveto" from subtemplates.)
3) reducing the bulk for doc_info in one common function:
yes, the matter is to find the common ground between the types.
i have to think about that...
4) big set of options and data
there a currently about 124 lines of configuration-settings added by two data arrays ($DTDS, $doc_info_types).
my following idea is again in opposit to maintaining a single file.
the first thing which comes to my mind is to shuffle things off.
i don't know if it's good but, i would put the config into a separate smartydocb.config.class, which is loaded at the beginning of the plugin. smiliar to the smarty config. so if class would be named docbcfg and initialized, config values would be address like $docbcfg->value in the smartydoc2.class.php5. i suggest ordering the options from general options to specific options for the related plugins.
what about building a xml file for the doc_info_types?
c) i appreciate the step to use "moveto" as alias. that makes command usage a lot clearer to the user. yes, i was suggesting "setdoctype" as a replacement for "doctype"/"dtd" with doc_info and doc_raw.
d) i meant "header" while using "head", sry. but you understood my problem in the right way. i noticed that, the solution is not to add a head manually or have it in the template file. that idea of automatical detection of a existing doctype in the template is very nice.
tell me, how i can assist you, in further development of this class. i checked out the svn already.
so much for this time - regards, vain |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Mar 20, 2007 1:58 am Post subject: |
|
|
Quote: | tell me, how i can assist you, in further development of this class. i checked out the svn already. |
Great! Since you were brave enough to try it out and shown an understanding of how it works, and I'm happy to have any extra help, I'll be glad to add you as a developer. Just let me know your account name at Sourceforge, and if you don't have one, you'll need to add one before I can add you as a developer. The site says you'll need "to go to the SourceForge.net site and register a new account via the "New User via SSL" link."
Quote: | i have not tested any xml/xsl functionality, because at this time, i don't really know what the benefits for our cms would be. but i'm open to using them. |
Since XHTML is itself an XML language, and since XHTML is going to be the standard, I'd recommend at least serving your pages as XHTML, preferably the latest working version, 1.1 if you are not already. One benefit of using XHTML is that, as with other XML, you can apply XSL stylesheets to it. One very useful stylesheet which I've referenced in SmDocB is the ability to translate XHTML into XHTML Basic, the latter being accessible to cell phones and other devices without so much processing power. However, to use the latter, you can't be using nested tables (which you really shouldn't be using for accessibility reasons anyways, though I know CSS 2 is not quite 'all there' for making tableless layouts even though it can be done via the CSS float property).
Quote: | yes, documentation is needed. i would suggest pear or phpdoc commenting style, which would ease the process of creating a developers docu automatically. |
In my case, I started with the verbose documentation, and I think I may be able to finish it in a few days.
Boots already had the code following some documenting standard, although, not being familiar with documentation styling myself, I didn't maintain it. If you are familiar with PHPDoc or PHPDocumentor or whatever, feel free to go through the code to bring it up to snuff (and preferably point me to the essentials of the syntax so I can follow it in the future too).
Quote: | the next step would be a manual with usage examples.
i would suggest a directory with working examples as a feature demonstration. |
Not sure what you mean by a 'directory'. Do you mean a Table of Contents? I'm writing the documentation in DocBook 5.0 (an XML language for writing documentation) and then styling it with CSS and transforming it with an XSL stylesheet (both included via doc_raws!) into XHTML. I'm also using the stylesheet to add chapter/section/paragraph numbering, and I could also use XSL to make the Table of Contents based on the headings. I can also make the original source DocBook XML available.
Quote: | i vote for splitting up the file by setting up the same directory structure as of the smarty class and putting the files in there.
so the user just copies the directories of the plugin with all files into the smarty folder and that's it. |
Great idea. I've been won over now to splitting it up. I'll be able to split off not only the XSL functions (though there is also an XSL moveto which stays with the other moveto's)
Quote: | 2) Override of Smarty Compiler Code
Although i made the changes directly at first time, shortly after that smarty was updated.
from that point of view one can live with the overhead, knowing,
that the change in code has not to be applied again if smarty updates. |
I haven't made any additional changes in that part so you're safe in sticking with it. I am now noting all changes in the messages accompanying the SVN updates as well as intend to do so in the release notes for full releases.
Quote: | (When redesigning and rethinking Smarty v3, the feature of this override should be added.
It's important to know where things come from, even more when having a feature like "moveto" from subtemplates.) |
That'd be nice. Not sure my way of implementing it was ideal, but it works for the time-being at least.
Quote: | 3) reducing the bulk for doc_info in one common function:
yes, the matter is to find the common ground between the types.
i have to think about that... |
As with doc_raw, we can probably just configure most things by accepting different parameters. There are a few type-specific things which may need to be hard-wired into the function, but the more general purpose (yet fully adequate) and thus reusable by other types (including any future ones), the better.
Quote: |
4) big set of options and data
there a currently about 124 lines of configuration-settings added by two data arrays ($DTDS, $doc_info_types).
my following idea is again in opposit to maintaining a single file.
the first thing which comes to my mind is to shuffle things off. |
Maybe that's a good idea, but when I'm developing, I like to be able to use the find (or find-and-replace) feature of my text editor to comprehensively go through the code or remind myself what the attributes are, etc.. That wouldn't be a problem for the $DTDS array, but it would for $doc_info_types.
Since I haven't tested all of boots' module code (and wasn't using them myself), I was also considering removing those functions until such time as someone wanted to make any needed adjustments for them to work with the current code (and preferably to help document this functionality).
There are still a number of other functions which I think could possibly be moved too: 'cdata', 'xinclude', 'tag' and 'tagc', etc. A closer look is needed though since at least in the latter cases, they have been relying on some configurable member variables. And the XSL functions were able to use the class to rely on one reusable piece of code.
Quote: | i don't know if it's good but, i would put the config into a separate smartydocb.config.class, which is loaded at the beginning of the plugin.
so if class would be named docbcfg and initialized, config values would be address like $docbcfg->value in the smartydoc2.class.php5.
i suggest ordering the options from general options to specific options for the related plugins. |
By loading, do you just mean adding a 'require' statement?
Is your reason for this based on reducing the size of the one document, or is there some other advantage you can see to doing it that way?
Quote: | what about building a xml file for the doc_info_types? |
Again, we could do it, but what advantage do you see to it?
Quote: | c) i appreciate the step to use "moveto" as alias. that makes command usage a lot clearer to the user. |
A bit more work is needed to update the whole API (including the work I'd need to put in to my existing site for which I have been developing this class!). But I do agree it would be very desirable to do so.
Quote: | yes, i was suggesting "setdoctype" as a replacement for "doctype"/"dtd" with doc_info and doc_raw. |
Hmm. In the previous thread, I mentioned the possibility of merging all internal/external types (e.g,. 'script'/'code', 'css'/'style'), but an email exchange, boots recommended against it, as I recall for the sake of clarity.
Also, if you set a function directly, Smarty can't handle a regular Smarty function and a block Smarty function of the same name. And if you have a separate function for each type, we can't maintain the code all in one place. (we do have the PHP method already named "setdoctype", but I don't even know if that is usable as a public API anymore--I've pretty much only been setting member variables via the API).
I think the changes I made to the naming convention make it fairly easy to remember the convention (i.e., if it is internal/for the head, use the name of the element or pseudo-element that gets printed in the head (e.g,. '<!DOCTYPE', '<script>', etc.), whereas if it is targeted externally, use the pseudonym (e.g., 'dtd', 'code', etc.)).
(For anyone just joining this discussion and who wanted to track its history, our thread started at http://www.phpinsider.com/smarty-forum/viewtopic.php?t=5836 under the discussion of SmartyDoc).
Quote: | d) ...i noticed that, the solution is not to add a head manually or have it in the template file. that idea of automatical detection of a existing doctype in the template is very nice.
|
Yeah, I agree...though that would mean yet more regular expressions...I already have added a bunch within the prefilter, but it would be nice to have...
Anyhow, look forward to working together on making this more usable for each of us and others...
all the best,
Brett[/quote] |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Mar 20, 2007 3:42 am Post subject: |
|
|
Sorry for an off-the-topic question, but does anybody here know anything about sleeping MySQL processes that build up (even with max timeout, etc. set low)?
We've been having a lot of problems with PHP5 in CGI mode occasionally causing crashes after eating up a lot of CPU and RAM.
We are not using persistent connections--just regular mysql_ functions
best wishes,
Brett |
|
Back to top |
|
vain Smarty Rookie
![](images/avatars/177509199346433691e3200.png)
Joined: 20 May 2006 Posts: 23 Location: Berlin / Germany
|
Posted: Tue Mar 20, 2007 4:24 am Post subject: |
|
|
i agree on working together to make this a little more usable for all, so i have sent
my sourceforge account data to your sf-mail.
as said, i would like to work on the comments at first.
you can find a quickstart tutorial for the phpdocumentor comment style here:
http://www.phpdoc.org/tutorial.php
smarty.class.php itself is very good commented and a good start to get familiar with it.
Quote: | vain: i would suggest a directory with working examples as a feature demonstration. |
i had the folder structure of smarty in mind. there is a directory named "demo" with a working example in it.
for new users it would be nice to have a look at examples besides the documentation, to get an overview and learn the features of this plugin faster.
your DocBook xml approach sounds very good and interesting too. seems to be an easy to maintain user-manual.
fmpov shuffling config settings into a separate config class
would bring more overview to the user and reduce the class file size. yes, i meant "require".
on the other hand, you're right, from developers view it's not that practical, as you have to overview two files.
maybe some more user-feedback would shape the functionality and it's config settings.
my idea with doc_info_types in an xml file was to let the user edit/add types
and then have them checked against dom->validate. but that was just a rough idea.
vain
ps: monitor connections with mysql> show status like '%conn%';
mysql_close in proper use? |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Tue Mar 20, 2007 8:08 am Post subject: |
|
|
Ok, vain, you're on as a developer. Boots, if you're monitoring the thread, of course I can add you too, if the 'boots' listed at Sourceforge is in fact you.
Vain, great if you'll be working on the comments. FYI, I just updated the file slightly.
I like the idea of putting the examples in demo folders, as well as in the documentation. I might even be able to have XSL do that for us based on the DocBook documentation. Yes, the manual is easy to maintain, and since DocBook is more semantic than XHTML, you feel more like you're working on the material rather than code.
Thanks for drawing to my attention the existence of a validator in the DOM functions! I had been looking searching for "PHP validator" to no avail, and there it is already in PHP! I also see there is an XInclude function so we could optionally resolve any XIncludes server-side (most people will probably just be using Smarty's include file features, but...).
As far as using the validator, the user should be able to edit the array directly too though, no?
One other significant use for the validator I can see would be to optionally validate the resulting XML/XHTML (of the whole document being served) before serving it, possibly avoiding the need for some of the pseudo-validation that is taking place inside of smdocb->addinfo in the process.
Again, do you want to move this discussion over to our Sourceforge forums page?
And, does anybody want to maintain boots' module code (as well as check all of the public API functions) and update it if necessary to work with this version? I think it would be nice to have it updated but as I don't need it now for my own stuff, I haven't worked on it. Boots, you said something about wanting to implement drivers? Was that related in some way to the modules?
best,
Brett |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Wed Mar 28, 2007 12:32 pm Post subject: |
|
|
Ok, we've released another version, thanks in large part to vain's helpful contributions for use with PHPDocumentor. Also included are a number of important fixes.
You can also see the main XML documentation now at http://smartydocb.sourceforge.net/docs/documentation.xml (fairly large file, especially with the stylesheet) or the PHPDocumentor documentation at http://smartydocb.sourceforge.net/docs/htmllib/index.html (the former links to the latter, but the latter does not yet link back to the former).
And if you were curious or wanted a working example, the SmartyDocB template file that I used to create the XML documentation is at http://smartydocb.sourceforge.net/docs/documentation .
I hope to break up the single document into multiple files in the future.
Any feedback on the readability of the documentation would be appreciated. Also, let me know if anyone may be interested to join in on the project.
best wishes,
Brett |
|
Back to top |
|
Barguast Smarty n00b
Joined: 07 Nov 2007 Posts: 3
|
Posted: Wed Nov 07, 2007 3:23 pm Post subject: |
|
|
Hi all. Hope that SmartyDoc(B :p) is still being developed as it looks really promising, and seems to be a good candidate for solving a problem I've been having - that is, how to include javascript and css in the head as the templates are being built.
One question though - is there a mechanism in SmartyDocB that prevents a javascript file from being included twice? For instance, lets say I have one template that includes the javascript, and later another (independent) template includes it again. I don't want the same <script> tag to be output twice.
Thanks. ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Wed Nov 07, 2007 4:00 pm Post subject: |
|
|
Hello Barguast,
There is only one way in which you can ensure that a particular block is not written twice, and that is if it is always written with the same key. For example, if you had the following code in different templates (the key can also be alphabetic, say if you want to use a name, but this wouldn't allow easy control over ordering, as using numeric keys do), it wouldn't get repeated, even if you have this placed in different templates which are part of the same include chain:
Code: | {doc_raw target=script key=5}
alert ('hi');
{/doc_raw} |
But are you aware that one of the benefits of using SmartyDocB is to have the contents shuffled off into one site-wide file? The advantage of doing this--besides being able to see and optionally manipulate all of your scripts or CSS, respectively, at once, is that browsers, when they visit your site, may save in their memory (cache) your script or styles file, so that for each page at your site which they visit after the first time, they won't need to reload the scripts/styles content, and consequently, your pages can be transmitted more quickly over the Net since you won't have all of that code getting repeated within the head of each HTML document that uses them... And you can also use keys to ensure there is no duplication of content....
The only down-side about doing things with a site-wide file is that you have to learn a little more to do this, since you will probably want to know how to turn on/off the file rewriting (so you can also avoid the file writing portion if your code is not being changed), how to set the site-wide file name, etc.
You can also specify a target file name for your scripts/styles from within the template (though it is less ideal for browser caching if you are specifying different file names).
best wishes,
Brett |
|
Back to top |
|
Barguast Smarty n00b
Joined: 07 Nov 2007 Posts: 3
|
Posted: Wed Nov 07, 2007 4:34 pm Post subject: |
|
|
brettz9 wrote: | But are you aware that one of the benefits of using SmartyDocB is to have the contents shuffled off into one site-wide file? |
Sorry to be a pain, but can you elaborate on this. I must admit that I am new to Smarty - I've only started looking at it in any kind of detail today.
Would a solution be to perhaps create a function plugin along the lines of:
Code: |
// Function
public function smarty_function_include_once_js($params, &$smarty)
{
[If url in $params in not already in $smarty's scripts]
$smarty->addDocInfo($params);
}
// Example
{include_once_js script="js/tooltip.js"}
|
I know - lazy pseudo-code.
But does SmartyDocB allow for that, and would that work / be a viable solution? I could guess, but you'll know better than I.
Thanks VERY much for your previous reply. |
|
Back to top |
|
brettz9 Smarty Regular
Joined: 07 Jul 2006 Posts: 93
|
Posted: Wed Nov 07, 2007 5:51 pm Post subject: |
|
|
Hi,
No problem at all... By the way, please download the latest version of SmartyDocB in Subversion at Sourceforge if you're ready to use it, as I've just made some changes relevant to what I describe below...
If you're using SmartyDocB, you don't need to create an additional plugin of your own to do it... The code is already designed to do it...
I've basically stuck to the rule of using the tag names as target names (like "style", "script", etc.) when targeting to the head, and pseudonyms (like "css", "code", etc.) as targets when targeting to an external file or site-wide file.
So, to target to a specific file (relative to $smartydocb->site_root_public ), you could do:
Code: | {doc_raw target=code file="myJSpath_from_siteroot"}
alert('hi');
{/doc_raw} |
or, for styles:
Code: | {doc_raw target=css file="myCSSpath_from_siteroot"}
p {color:blue;}
{/doc_raw} |
or if you have set a site-wide file at $smartydocb->dr_code_file_st (for scripts, and optionally localizable into other languages by setting the $smartydocb->langu variable) (or set $smartydocb->dr_css_file_src for a site-wide styles file ), you can just do:
Code: | {doc_raw target=code}
alert('hi');
{/doc_raw} |
or, for styles:
Code: | {doc_raw target=css}
p {color:blue;}
{/doc_raw} |
I'm very happy to help with any further questions on it, if things are still not clear. There is also full documentation of SmartyDocB at http://smartydocb.sourceforge.net/docs/documentation.xml . |
|
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
|
|