I have piece of code which I want to use in some of the dust templates, so i am planning to use partials. I am not sure if following is the best approach. Please help.
1) I extracted common code from base templates in to a template file called userinfo.html
2) I compiled userinfo.html to create userinfo.dust
3) I added {>"userinfo.dust"/} code into all templates where I wanted to see user information.
4) Now when I render the template with following command. I get "Template not found: userinfo.dust" error.
dust.render("moduleTemplate", templateData, function(err, out) {
$main.html(out);
});
Do, I need to send userinfo.dust along with templateData while rendering? I tried reading all partial related information which google can give me, but not able to to figure how to implement partials.
In your template, when you call:
{>"userinfo.dust"/}
You should really be calling
{>"userinfo"/}
As yo don't need to specify the .dust extension. Here's a template example of mine:
{>header /}
{>results /}
{>footer /}
HTH
It sounds like the answer to your problem is that the partial is not being included on the page. Dust compiles to JavaScript, so this will make more sense if you rename your files: userinfo.dust (the template), and userinfo.js (the compiled template). Now include your template using a script tag:
<script type="text/javascript" src="templates/userinfo.js"></script>
Finally, you need to call the template using the svame name it was compiled with. It is a good idea to use the filename (often but not necessarily without the extension):
var userinfoCompiled = dust.compile('userinfo', 'user info template goes here');
A template compiled in this way can be called using:
{>userinfo/}
If you're not sure what your compiled template's name is, you can open the compiled JavaScript file and look for:
dust.register('userinfo')
Related
app.engine('hbs',hbs({extname:'hbs',defaultLayout:'layout',layoutsDir:__dirname+'/views/layout/',partialsDir:__dirname+'/views/partials/'}))
why is hbs,extname,defaultLayout used here
app.engine(ext,callback) will takes two arguments, one is the extension and the other is a callback function. Therefore, hbs is the extension you are using to create your views.
you can also take a look at handelbars's github repository when they mentioned extname from here.
https://github.com/ericf/express-handlebars#extnamehandlebars
This link also might be helpful for you, they mentioned the defaultLayout option and what it means.
This link might help you understand why to use defaultLayout.
A layout is simply a Handlebars template with a {{{body}}} placeholder.
Usually it will be an HTML page wrapper into which views will be
rendered.
https://github.com/ericf/express-handlebars#layouts
Has anyone else encountered this problem?
I cannot modify files of this type:
{% include 'mobshop/template/common/icons/wishlist.twig' %}
The file "wishlist.twig" is modified in the log but the changes do not appear live.
Do you have any suggestions?
Short answer: you can't modify with OCMod twig files that are added via include method inside the twig template.
How twig include works?
include is twig method that allows you to add partials into your theme which is a cool feature. when twig engin runs, it compiles the template by following the link and adding the html part into the final html output string.
How OCMod works?
OCmod is basically a function that takes in the path of the file (in our case the twig template file path) and after parsing the string modifies it and saves to the OCMod cache.
Then, when OpenCart asks for that file, the OCMod engine tries to first return the cached file, and if that is not available, then the original file.
so all files that are wrapped in modification('') method have this support.
The reason why twig include is not supported by OCMod
From the logic above we can see that the OCMod modification method simply never sees the twig partial file path from the Include method. It is jsut beyond its scope.
The modification method sees only a string {% include 'path-to-partial-file' %} and that is it. it never dives into that path and never tries to create a OCMod cache off of that file.
Conclusion.
You should not use "include" in your themes at all. Its just bad practice in OpenCart themes. Although personally I love this feature of Twig, I am also forced to avoid it.
The only way you should add partials in OpenCart is via the Controller ($this->load->controller('...')) attaching it to the $data field and then displaying it in the template.
And if you still MUST have this feature
PHP Twig engine is a powerful tool and you can extend it to your needs. You can still add an extension that can make the include method to work with OCmod, although I have never added that feature.
Here is a twig extension https://github.com/Dreamvention/2_d_twig_manager/blob/master/system/library/template/Twig/Extension/DTwigManager.php that you can use as an example and modify to your needs.
Enjoy!
I have an index.html file that I'm trying to render using dustjs-linkedin but get the error:
500 Error: Template Not Found: C:\Users\Gilbert\WebstormProjects\NodeOfGames\views\index.html
The file index.html is definitely there. I'm using app.engine('html', require('dustjs-linkedin').render); to render .html files with dust.
dust.render looks in dust.cache for the named template, which in your case is named
C:\Users\Gilbert\WebstormProjects\NodeOfGames\views\index.html
dust.render only renders compiled templates - which are automatically put in dust.cache upon load.
I don't think the template is in there. if it is, it probably isn't named with the above name.
what you may want is dust.renderSource instead. even so, you need to pass in a context and a callback - I'm not sure how that works in express.
Brief description of the default behavior i want to override:
Creating a SharePoint list and using the "Title (linked to Item)" in a view provides a link to the DispForm for that list. By default, this link appends a Source parameter to the URL query string.
I would like to disable this behavior in some way while still retaining the default list view web part that is created by SharePoint when the view is defined.
To be clear, I know how to convert the list-view webpart to XSLT and then control this behavior. If at all possible, I'd like to keep from doing that so that the list view can still be easily supported by Help Desk and also keep the benefits of the standard list view (such as exporting to excel and so forth).
Any ideas?
Thanks in advance for your help.
Troy
SharePoint (2007) dynamically appends the source parameter in a javascript method named GoToLink. That method is defined in SharePoint's core.js file, and it can be easily customized without editing the original file. In fact, you never want to edit that file directly; it will put SharePoint into an "unsupported" state.
We'll create a solution for our customization, so it can easily be deployed or retracted in a consistent manner. Create a new Empty SharePoint solution in Visual Studio, targeted for GAC deployment. Within your project, create the following folder structure:
Templates
Layouts
1033
("1033" is for the English localization; if you're using a different language, your id will be different).
Within "1033", create a new Javascript file (we call our ours "CustomCore.js"). This will contain JUST the code we want to override from Core.js. Since GoToLink is the only thing we're interested in, let's focus on that. Here's the original from Core.js:
function GoToLink(elm) {
if (elm.href==null)
return;
var ch=elm.href.indexOf("?") >=0 ? "&" : "?";
var srcUrl=GetSource();
if (srcUrl !=null && srcUrl !="")
srcUrl=ch+"Source="+srcUrl;
var targetUrl=elm.href+srcUrl;
if (isPortalTemplatePage(targetUrl))
window.top.location=STSPageUrlValidation(targetUrl);
else
window.location=STSPageUrlValidation(targetUrl);
}
Not much to it. For our override, we just need to omit the bits that add the source parameter. From my reckoning, the modified method looks like this:
function GoToLink(elm) {
if (elm.href==null)
return;
if (isPortalTemplatePage(elm.href))
window.top.location=STSPageUrlValidation(elm.href);
else
window.location=STSPageUrlValidation(elm.href);
}
That should be it. Package up the solution and Visual Studio should interpret the "Templates" folder structure correctly when it builds the WSP (look in the generated manifest file for the TemplateFile element and that it's deploying to "Layouts\1033\CustomCore.js").
Once your WSP solution is deployed to SharePoint, we have the final step of referencing it in your Master page. In the HEAD section of your master page, you should see Core.js being referenced like this:
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="core.js"/>
We simply add a reference to the new JS file directly beneath this line:
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="core.js"/>
<SharePoint:ScriptLink Language="javascript" runat="server" Defer="True" Name="customcore.js"/>
Test it out and make sure it works. Note that this will affect ALL lists on the server to which you've deployed "CustomCore.js" and which use the master page.
In asp.net webpages framework what is the difference between using a content block versus a helper?
They both seem to be used to output HTML to multiple pages. They both can contain code and both can pass parameters.
Are there other differences? When should you use a helper versus a content block?
More info:
With Content Blocks we create a .cshtml (for example _MakeNote.cshtml) file to hold the content we want to insert into a page. Then we use:
#RenderPage("/Shared/_MakeNote.cshtml")
to insert the content into a page. We can pass parameters to the content block like this:
#RenderPage("/Shared/_MakeNote.cshtml", new { content = "hello from content block" })
It's somewhat like an include file, but I think does not share scope with the parent page.
With Helpers we create a .cshtml page in the App_Code folder (for example MyHelpers.cshtml) and place methods in that page which we want to call. The method looks something like this:
#helper MakeNote(string content) {
<div>#content</div>
}
The helper is called by using:
#MyHelpers.MakeNote("Hello from helper")
There isn't a lot of difference functionally. Helpers need to go into an App_Code folder - unless you download VWD or Visual C# Express and compile a binary - and the App_Code folder doesn't translate well to the MVC framework. Of course, that's only relevant if you want to upgrade to MVC at some point.
I would use a helper for generic functional snippets like your MakeNote. I would use a "content-block" (partial, really) for repeated site-specific sections of a page.