I assume dynamic template's version is to specify the template's id and version when sending the email. How do I specify dynamic template's version when calling v3 api? I'm using c# client library.
Just click the version and you will see it on the address bar from your browser, e.g.
https://mc.sendgrid.com/dynamic-templates/YOUR_TEMPLATE_ID/version/YOUR_VERSION_ID/editor
And you can activate the version following the offical document.
After the verion has been activated, you will be able to send the active version of your template.
Note: You might need to swith your API key from Restricted Access to Full access.
It is so profoundly undocumented that I would almost suspect it is intentional but you may simply use d-#{template}.#{version} for the template_id field.
Just to expand on Chuan's answer: you can't explicitly use a specific version from the template. Sendgrid always sends the active version.
There might be some workarounds if you use the marketing/test/send_email endpoint, but controlling the template's personalisation might be limited.
More info here:
https://docs.sendgrid.com/api-reference/send-test-e-mail/send-a-test-marketing-email
Related
I have a website hosted on AEM. I want to change a text that is present in almost all pages (say I want to change my product name which is present in all pages) . How can i do it. It can either be a Groovy/Java code or an ondeploy script or anything else. Because doing it manually on all pages at multiple locations is not feasible. Will AEM Bulk Editor solve the purpose?
Its like Find and replace functionality in office
Yes, you will need to have a set of queries to find most of the references and then make a POST to these pages with the new value.
Example with: curl -u $USER:$PASSWORD -F"PROPERTY=new value" "http://$HOST/content/mysite/en/page/jcr:content"
Of course, you can do it with Java, Groovy (look for Groovy Console for AEM, which is very convenient), or even bash for simpler cases.
You can write a query using the query builder api to get all the nodes where your particular property is present.
Then once you get the path to that property you can update that using the node api.
Is it possible to retrieve an existing classic style, even though they are no longer supported?
I have a URL that used to point at our style, but now I get json that looks like this:
{
message: "Classic styles are no longer supported; see https://blog.mapbox.com/deprecating-studio-classic-styles-d8892ac38cb4 for more information"
}
My company was sidelined by the depreciation of classic styles. It required some emergency hotfixes to get things up and running again, but our maps no longer have our signature look. We had a professional design our classic style, and now we want to convert it to MapBox Studio.
Does our previous style still exist? If it does, how can we retrieve it?
Thank you!
They wrote on a blog entry:
We made the decision to stop active maintenance of the core technology that powers these maps (CartoCSS) back in 2016. However, we continued to support Classic Styles through our Legacy Maps and Legacy Static Images APIs.
Here is the documentation about the Legacy Maps: https://docs.mapbox.com/api/legacy/maps/
In my case, it was faster to change to the new API. The old access token was still working. Here is how to implement it: https://docs.mapbox.com/help/troubleshooting/migrate-legacy-static-tiles-api/
I want to stress test a system based on Apache Wicket, using grinder.
So what I did was that I used grinder's TCP Proxy tool to record a test session in my Application and then fed the generated test script to grinder to stress test the system; but we found out the tests aren't carried out successfully.
After a lot of tweaking and debugging, we found out that the problem was within the wicket's URL generation system, where it mixes the page version number into its URLs.
So I searched and found solutions for removing that page version number from the URLs (Like this), and used them and they worked and removed those version numbers from the URLs used in the browser. But then again, the tests didn't work.
So I inspected more and found out that even though the URLs are clean now, the action attribute of forms still use URLs mixed with page version number like this one : ./?4-1.[wicket-path of the form]
So is there anyway to remove these version numbers from form URLs as well? If not, is there any other way to overcome this problem and be able to stress test a wicket web application?
Thanks in advance
I have not used grinder, but I have successfully load-tested my wicket application using JMeter Proxy; without changing Wicket's default version mechanism.
Here is the JMeter step-by-step link for your reference:
https://jmeter.apache.org/usermanual/jmeter_proxy_step_by_step.pdf
Basically, all I did was running proxy server to accept web requests from the browser to capture the test scenarios. Once done collecting the samples, then change the target host url to whichever server you want to point to (other than your localhost).
Alternatively, there is another load testing tool BlazeMeter (compatible with JMeter). You could add the chrome browser plugin for quick understanding.
Also, you might want to consider mounting your packages to individual urls for 'cleaner' urls. That way, you have set of known urls generated for pages within same package (for example, /reports for all the reports pages within reports package).
Hope this helps!
-Mihir.
You should not ignore/remove the pageId from the urls. If you remove them then you will request a completely new instance of the page, i.e. you will lose any state from the original page.
Instead of using the href when recording you need to use the attribute set (by you!) with org.apache.wicket.settings.DebugSettings#setComponentPathAttributeName(String).
So Grinder/JMeter/Gatling/... should keep track of this special attribute instead of 'href' and later find the link to click by using CSS/XSLT selector.
P.S. If you are not afraid of writing some Scala code then you can take a look at https://github.com/vanillasource/wicket-gatling.
According to Microsoft Website on Database.ExecutedDataSet method
http://msdn.microsoft.com/en-us/library/microsoft.practices.enterpriselibrary.data.database.executedataset(v=pandp.31).aspx
Retired Content
This content is outdated and is no longer being maintained. It is provided as a
courtesy for individuals who are still using these technologies. This page may
contain URLs that were valid when originally published, but now link to sites
or pages that no longer exist.
So my question is what is the latest and greatest perferred method to fill a DataSet or DataTable?
Microsoft wants you to use a DataReader or DataAdapter, here's Microsoft's page on filling a DataSet. It uses the Fill method on a DataAdapter.
You could then use the Add method to add DataRows to that DataSet.
v5 still has it.
"This content is outdated" in this case means that you are looking in old documentation of entlib.
EDIT:
Method is not outdated nor replaced. It still exists in new version of entlib.
EDIT2:
And the method is not deprecated.
We've been trying to work with Liferay CMS to create Web Content (liferay terminology). The content is versioned in the sense, each time we change the content and publish it, the version increments.
This has an impact on the URL which is publicly exposed, and we're facing the trouble of changing the URL on content change.
Is there a way of getting a published URL that reflects change in content without changing the URL?
You could use friendly urls in this case. Have a look at this post for some more info.
It doesn't appear that you are able to grab the latest journal content with any invokable URL because it requires a version number to be passed along with the request (otherwise it will just grab the first version not the last).
A work around would be to create a hook plugin that modifies the /journal/view_article_content action path with your custom implementation to return the latest article.
See Liferay's Portal Hook Plugins wiki page on how to create a hook.
Then see Mika's blog post on the specifics of overwriting a struts path.
Good Luck!