I'm looking some way to split complicated template to few ones.
When create page with few tabs - template file structure come to be ugly and complex. This is bad way. I can split templates with creating new by
template(name="some")
and then
{{>some}}
But it's mean i need to make helpers, events_handlers, etc for each template. But much of data for this templates will duplicate, so it's again not good way.
Maybe exist some way to split html, but not create few Template objects?
One solution is to divide your templates up as you suggested but have each inherit its events and helpers from a single template using the template-extension package. That should give you a logical division of template code without repeating yourself.
Related
Can anyone tell me if its possible to retrofit inheritance into a Sitecore template?
I have a task to add a new page field into multiple existing templates and I think this should be in a base template.
I've also noticed that the existing templates have fields that should be moved to a base template and then inherited from. Is this possible and if so will there be any side effects with existing code / data?
Yes, it's absolutely ok to add extra base templates to existing Sitecore templates.
E.g. if you already have multiple "page" templates and you need to add extra token for some tracking, you can create new template (let's say "ICustomTracking") and then add it to base templates of your page templates.
To answer your second question: you can "extract" base templates from the existing templates. If you don't want to loose any data, the order of your actions is:
Create new base template
Set this template as a base template for all templates you want it to inherit from.
Move field item from the inheriting template to the base template.
Make sure you move the field item. If you remove the field, and add a new one later, most probably all the data will be lost.
Also it's not recommended to build too complex inheritance structures. It won't be easy to maintain that in the future.
I'm learning golang - coding small web blog, and writing router(I know there are available few - gorilla mux, martini, etc).
I have simple struct
type Routes struct {
method string
pattern string
handler Handler
}
and some regex matchers. But i can't understand how do i keep all routes that i will define in one place. Is using slice of structs good idea(like
[]Routes) to keep them all together?
P.S. This is meant for personal understanding of how it all works together
Your question is not really well defined. You told us you want to implement routing functionality based on regular expressions, but you haven't told us what kind of tasks you want to achieve which greatly influence the optimal or best data structure to be used.
You already mentioned you know about a lot of other implementations which are open source, maybe you should check their sources.
This answer might also be a help to you which shows a simple implementation of a basic implementation how to do routing functionality using regular expressions.
If you just want to be able to register regular expressions which if matched by the request path and then forward the serving to a Handler, yes, storing the "rules" in a []Routes is a viable and simple option.
Things to keep in mind:
I would definitely compile the regexp in advance and store the result and not compile them each time which is an awful waste of resources. So your Routes struct should contain a field of type *regexp.Regexp instead of the pattern (you can keep the string pattern too e.g. for debugging purposes).
If your Routes struct grows bigger, I would consider storing pointers in the slice and not struct values, e.g. []*Routes because each time when you loop over them (e.g. in each request to see which matches) or whenever you create a local variable from one of the Routes, a copy is made from the values. Copying large struct is inefficient compared to copying a pointer which is fast.
I found this template tag which allows me to run a counter inside a template. I have this requirement where I need to render out nested paragraph numbers but I can't use a CSS counter (for various reasons).
The problem I run into with the above mentioned template tag is that it only works inside the context of the template that includes the tag library. Unfortunately I do have a lot of different templates to include and the counter has to work across all of them with the same instance.
Is there a way to accomplish this with modifications on the given template tag or is it possible to get this done in any other way?
Ah, never mind. Should have thought a minute longer. Sticking itertools.count() into the template context does the job.
Can anyone tell me whether it is possible to call only a part of a template?
I have a large template which I must use, yet the first two lines in the template need to be adjusted/changed.
How can I do this? Any suggestions?
Thanks in advance
Greets
You need to refactor the large template so that it calls the first couple of lines as a child template or function which can then be called directly from outside.
It's generally true in XSLT as in any other language that templates/functions have a habit of growing too big, which reduces the reusability of the code, and the answer to this is always to be prepared to refactor the code to isolate the reusable parts into individually callable (and overridable) components.
Since XSLT files have XML format, you could have an XSLT script that changes the original template as needed. After that you use that changed template to do the actual work.
The problem is that if I call a templatetag into a block
and it fills me a variiable with the usual context[varname]=something,
then if I need that variable into another block, I have to call the
templatetag again. This for me means extra db queries, which is really
something I'm trying to avoid.
This templatetag is called in a base template which is extended by
many other templates, so I can't just change all the views to pass
something to the context, it makes no sense (WET principle?)
Even a context processor would be not good because I don't want to
call it for every page rendered in the site, even the ones not based
on that template.
I was thinking about writing a templatetag which would use the
internal context structures to put the variable in a global context,
but I'd feel too guilty doing it.
How would you solve this problem?
You said, "This templatetag is called in a base template which is extended by many other templates."
The question is: is this tag called from within a named block? If it is then you have a couple of potential problems.
{% block %} pushes a new dict on the Context stack and pops it off when it reaches the matching `{% endblock %}'. This means any context value created while in the block has essentially gone out of scope on block exit.
If this block is overridden by some other template that extends the base template, the value may not be available at all unless you do a {{block.super}}, and even then I'm not certain the value will be available to the template doing the extending.
If the tag is not called from within a {% block %} then the context value should be available to all of the code that follows it, either in the base template, any included templates and (I think) any extending templates.
This is one of those cases where building a set of careful tests will probably save you time and tears.
Alternatively, if you are always accessing this value, you could just put it in a context processor so that its availability is guaranteed.
Update for comments: OK, time to bring in the big guns! One of the most irritating, long-standing bugs in Django templates is that callables (ie. functions) that are top-level context values (as opposed to functions that are dict-values/methods of context values) are not called! This ticket is over 2 years old and takes about 10 lines of code to fix. We have several heavy-weight DB calls that we only want to happen if the template cache has expired. So we a) MonkeyPatched the template _resolve_lookup() code to fix the callable problem, and then b) curry functions to have all of the necessary parameters if needed, because you can't pass params to functions in the template "language".
I think you've accurately described the limitations in this situation. The most maintainable solutions will likely involve some restructuring of your template inheritance chain, though its hard to say without knowing the details. Can you introduce a new template in the inheritance hierarchy, probably somewhere near the top of the pyramid but so it only is inherited by templates that need this data, with a single block that encompasses the entire region within which you need this data? That big block can then be subdivided into smaller blocks that inheriting templates will override. If you call your templatetag at the beginning of that block, all blocks within it (including in inheriting templates) will have access to the data.
Update: I can't say much without seeing your templates, but introducing a new template in the middle of an inheritance chain very rarely involves "changing all the templates," in a sane inheritance structure it often can be done with changes to only one or two other templates. And I think what I am suggesting is actually not a hack, it's just better design. If you need a certain piece of data in certain parts of your site and not other parts, there should be a specific single template you can point to and say "this template represents the logical layer at which this piece of data is introduced, and encompasses the parts of the site where that data is needed."
Are you just trying to keep down the number of database queries or are you looking for a clever solution?
If it's the former, I would definitely go with caching. Would fragment caching work in your case? If not, perhaps you could put the caching in the template tag code (assuming it's not one of Django's own template tags your using)?
Just came across this trick from Liviu, Agile Bear (all credit goes to him)
Instead of doing
context['some_var']='some value'
do
context.dicts[0]['some_var']='some value'
May not be a by-the-book-coding-practice but works well enough