Is it good to make Velocity Template Object Static?
The situation is im going to use this object in (Servlet) multi user environment populating different data for each user-request with same template.
You can make it static, only it would mean that you have to redeploy your app every time you make changes to your templates. If you are worrying about performance (and reading template from file every time is indeed slow) better solution would be to enable template caching which helps a lot, that way you still can make changes to templates on the fly without sacrificing performance.
file.resource.loader.cache = true/false
file.resource.loader.modificationCheckInterval = <seconds between checks>
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
As my Meteor project grows and I add more templates, partials and helpers, it gets harder to figure out what will be the data context for it. Then I'll have to console.log(this) inside a helper function to figure out what's the data I'm dealing with.
Does anybody have a naming scheme or any other strategy to handle this?
Or is this mess just a sign I'm failing to modularize stuff properly and should refactor everything?
For me, each module has a folder. Each folder contains helpers.js, events.js, the "ons" (onCreated.js, onDestroyed.js, onRendered.js) and finally templates.html. If your project is big, break these out into individual subfolders for the necessary CRUD actions (I have a create folder and an update folder because reading & deleting happens in the update templates.
My template names are long and verbose, but that's OK, WebStorm does a good job of guessing what I want. For example, if I had some infowindow that listed all the addresses associated with a client: clientMap, clientMapPopup, clientMapPopupLocationList clientMapPopupLocationListItem.
Regarding data context, it's usually pretty easy to see since my helper is the one that added something to the context. Although I honestly try to avoid using that unless I'm in an {{#each}} because IMHO things like grabbing grandparent context is neither elegant nor robust. Instead, I have a temporary module object that I create & destroy on route changes.
So if my global object is Global = {}. In the onCreated and onDestroyed I write Global.Module = {} Then, I can create all the module-scoped variables I want (ReactiveVars, ReactiveDicts, local collections, primitives, client markers object, etc).
All that said, doing what you do & looking at my schema js (e.g. collections/clients.js) is still the fastest/thoughtless way to see what you want & what you're currently getting.
This relates to Drupal 6 and Views 2.
I'm not new to Drupal, but I am new to problematically using Views.
I have a custom view defined in a module which is integrated with data like this (I think):
$view->base_table = 'tblName';
I am integrating a third-party API. It returns me a pretty vanilla PHP object.
I need a way for list returns from that API to become the base_table for the view, on the fly. Is this possible? The ugly solution I was think of was making every return item a node, and then using those as the "base_table". I think that would work, but it seems ugly. I don't want a bunch of nodes hanging around for later.
Any suggestions? Thanks.
I'm not sure this is a good idea, but I ended up creating a routine based around Drupal's caching mechanism. I'm droping and creating a table on the fly and handing that table to Views. The table is populated every five minutes by the API. It can be forcibly re-populated by clearing the Drupal cache.
I tried using MySQL Temporary tables, but they didn't persist well enough. I wonder if there is a way to make them more connection-persistent, or to last a certain amount of time.
I have a Drupal 6 website with about 20 pages. Inside every page, I need to create a lot of widgets with information either stored inside the database or from external web services. Most of the time, a "view" (from the view module) is just not enough to solve the requirement.
Up until now, any time I need such a widget, I create a new module which implements hook_block. Then, I drag and drop this new module inside the panel I want. I will need to create about 20 modules. This works pretty good. However, I'm not sure if this is the correct-drupal-strategy and I would love to receive some feedback from experienced Drupal developers.
A module can expose as many blocks as you want (in theory, admin/build/blocks will teach you otherwise ;)).
Have a look at the documentation of hook_block(), you just need to extend yours to return multiple block infos and then decided which one to show based on the $delta.
So you don't need 20 separate modules, maybe 2-3 and group the blocks somehow together because just a single module might be hard to maintain. The thing is that every single module makes your site a tiny bit slower (at least one more file to load, module_implements() needs to loop over every module for every hook and so on).
Without more information , it's hard to give any better advice. Maybe you could expose your data to views, or write a views plugin to display it in the way you want it, or...
Although Berdir's answer is pretty good, I'm impressed there's no link to any documentation in it. hook_block is meant for several blocks, and they can share functions that build their content. The API page is good, the example it gives defines two blocks at once.
You should notice each defined block has a delta (a key in the $blocks array). You can have dynamic deltas and use values in it to fetch data (passing a nid or uid and getting related content, for example).
I am developing an application that has a repeater that will use dynamic templates for each row based on the underlying DataItem (in this case a product). What I would like to do is have some sort of XML file that will store which templates are to be used with which templates, and then use a default template if there is not one specified for the product. My product catalog does not contain a particularly large number of products, but having to open and parse an XML file for each row would almost certainly have adverse performance effects. What I would like to do is have the ASP.net engine compile the entries in the XML file into some sort of global collection that can easily be accessed when needed. Ideally, the application would be able to determine when I have made changes to the file and would automatically recompile the collection and restart the application if necessary. If my understanding is correct, this is already how the engine deals with the web.config file.
Does anyone know if an approach like this is possible, and how I might be able to accomplish it?
Thanks,
Mike
Well you could likely open and parse the XML file on each page load without any significantly adverse performance issues. Toss the result in a page-level collection and for each repeater row, read from that. This will at least prevent you from having to manage a global collection with a file change update dependency.
I do use XML in similar ways, albeit for mostly non-critical company Intranet type applications, so I'd certainly say your approach isn't too awful. :) In my specific cases, I have ultimately put the XML in a global application level object, with the trade off being that I have to manually restart the application to re-load the XML, should it change.
If you do want to tackle your ideal scenario, I would look to store the XML templates in the Cache object and set up a CacheDependency on the XML file.