Can hx-trigger happen in less than a second? E.g. hx-trigger="every 0.1s" - htmx

I want to do something like
<div hx-get="/latest_updates" hx-trigger="every 0.1s">
Nothing Yet!
</div>
Is this possible with HTMX?

Yes, you can use ms instead of s for sub-second triggers. E.g.
<div hx-get="/latest_updates" hx-trigger="every 100ms">
Nothing Yet!
</div>
Note
Polling every 100ms is unusual and you would probably look at SSE or WebSockets for something updated that frequently

Related

How to query rabbitmq_exporter

I am trying to use a rather popular Docker image with from my understanding uses Prometheus to scrape data from RabbitMQ. This assumption seems confirmed as the /metrics endpoint gives me exactly the data I would expect from Prometheus in this context.
My problem is that the usual queries to Prometheus yield unexpected results. If I query /api/v1/query?query=rabbitmq_queue_memory for example, I would expect to receive data about the queue memory. Building requests like this works according to the Prometheus documentation and also works on a plain Prometheus server. The field also does exist. However all I receive is a reponse status code of 200 with a html body:
<html>
<head>
<title>RabbitMQ Exporter</title>
</head>
<body>
<h1>RabbitMQ Exporter</h1>
<p><a href='/metrics'>Metrics</a></p>
</body>
</html>
It also does not matter if I actually make a correct query. The same result appears for /apasdfasdfasfsi/v1/query?query=rabbitmq_queue_memory
Any ideas how to properly query data here? Since this image is rather popular and I cannot find any related issues anywhere (except from myself), I assume it does work, but I am simply doing something wrong.
It would look as if you're querying your RabbitMQ exporter rather than Prometheus. Don't know if you already have a Prometheus instance, so you may need to start one, point it to your exporter's /metrics and then query said Prometheus instance for /api/v1/query?query=rabbitmq_queue_memory.
All the exporter does is produce the /metrics output you see. Prometheus (properly configured) will then scrape that endpoint periodically, build timeseries for each metric (from the value of each metric across time) and you can query Prometheus for said timeseries or aggregations thereof.

How to get flash messages to work in Hanami

I'm trying to figure out how to get flash messages to work in Hanami. The only reference to flash messages that I've found in the official docs are about testing, not actually implementing. If I overlooked something, please point me in the right direction.
I also found the Hanami::Action::Flash class in the source, but haven't been able to discern from that what I'm doing wrong.
So, I forked the official bookshelf demo app and added what I think is a super rudimentary demonstration of the flash message not working as I think it should, based on what I've read, immediately after creating a book. I feel like the message added in the create action should be visible in here somewhere, but all the index page shows (immediately after the redirect), is...
<div id='flash'>#<Hanami::Action::Flash:0x7f442c865408 {}></div>
<div id='message'></div>
What am I doing wrong? Thanks!
do you have sessions enabled? flash is exposed by default as you're using Hanami 1.1.
Then set it in the action flash[:some_notice] = "Test" and use it in a template.
regards,
Sebastjan

dojo load js script and then execute it

I am trying to load a template with xhr and then append it to the page in some div.
the problem is that the page loads the script but doesn't execute it.
the only solution I got is to add some flags in the page (say: "Splitter"), before the splitter, I put the js code, and after the splitter I add the html code, and when getting the template by ajax, I split it. here is an example:
the data I request by ajax is:
//js code:
work_types = <?php echo $work_types; ?>; //json data
<!-- Splitter -->
html code:
<div id="work_types_container"></div>
so the callback returns 'data' which I simply split and exeute like this:
data = data.split("<!-- Splitter -->");
dojo.query("#some_div").append(data[1]); //html part
eval(data[0]); //js part
Although this works for me, but it doesn't seem so professional!
is there another way in dojo to make it work?
If you're using Dojo, it might be worth to look at the dojox/layout/ContentPane module (reference guide). It's quite similar to the dijit/layout/ContentPane variant but with one special extension, that it allows executing the JavaScript on that page (using eval()).
So if you don't want to do all that work by yourself, you could do something like:
<div data-dojo-type="dojox/layout/ContentPane" data-dojo-props="href: myXhrUrl, executeScripts: true"></div>
If you're concerned about it being a DojoX module (DojoX will disappear in Dojo 2.0), the module is labeled as maintained, so it has a higher chance of being integrated in dijit in later versions.
As an anwer to your eval() safety question (in comments). Well, it's allowed of course, else they wouldn't have such a function called eval(). But indeed, it's less secure, the reason for this is that the client in fact trusts the server and executes everything the server sends to the client.
Normally, there are no problems unless the server sends malicious content (this could be due to an issue on your server or man in the middle attacks) which will be executed and thus, causing an XSS vulnerability.
In the ideal world the server only sends data and the client interpretes this data and renders it by himself. In this design, the client only trusts data from the server, so no malicious logic can be executed (so there will be no XSS vulnerability).
It's unlikely that it will happen and the ideal world solution is not even possible in many cases since the initial page request (loading your webpage) is in fact a similar scenario where the client executes whatever the server sends.
Web application security is not about being 100% safe (it's impossible), but it's to try to create as less as possible open doors that can be used by hackers. It's up to you what you consider safe and to verify if the "ideal world" solution is possible in this specific scenario (it might not be, or it might take too much time compared to the other solution).

How to handle errors in Zope page templates

I'm looking for a good way to handle errors in Zope's page templates. What I already know is:
<div ... tal:define=...
tal:on-error="string:Oops!">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="error/value">
This text will be replaced in case of errors
</div>
or
<div ... tal:define=...
tal:on-error="string:${error/type}: ${error/value}">
This text will be replaced in case of errors
</div>
However, it might be desirable to use a more elaborated error handling method, e.g.
to display details depending on certain permissions
to log and/or report the error to the maintainers
to have an easy way to create some pretty HTML without the need of a lot of code in the template
I had a look at the old Zope documentation page and created a script object like described there (amending the missing colon, of course); however, it won't work (I tried both on-error="here/errHandler" and on-error="here/scripts/errHandler", and I added *args and **kwargs, without success).
I tried to build a browser (on-error="here/##talerror") for such purposes, and it was used alright, but it didn't seem to get the error object.
I'm using Zope 2.10.7-final and Plone 3.3 (old, I know).
Is there a way to hand over the error object to the browser, or to make the script object work?
P.S., just to get it clear: This is not about sqeezing lots of logic in a template - no sermons about templates and logic, please! My goal is to find the error in existing templates, i.e. which part of the logic (which is implemented somewhere behind the scenes, in browsers etc.) fails in which way. The documented way of using an error script doesn't work for me (maybe I'm missing an important part?), and an error handling browser apparently doesn't have access to the error object.

Type of path best to use in web apps?

Following are the two ways of calling an image in your webb application.
<img src="/myapp/img/world.gif" />
OR
<img src="http://www.example.com/myapp/img/world.gif" />
Which will be best to use or both have the same meaning. If both do not have the same meaning then why? and is there any performance constraints if I use the second method in my app to call all files (images, swf, flv etc..)
Generally speaking, the first method should be your preferred way of referencing any resources that are part of your application. It is called a relative URI reference and it allows you to transfer your application to another domain-name without changing all the links.
You may even consider using relative paths such as
<img src="img/world.gif" />
... assuming that the HTML above appears at some place like http://www.example.com/myapp/main.html
That way you are also not tied to the /myapp path prefix and could easily move your application to /superapp without changing a thing.
Most application frameworks and templating systems have a way of reporting the root URI of the current application. In such cases it may be most convenient to use something like
<img src="$(APPROOT)/img/world.gif" />
... depending on what specific replacement/expansion mechanism your particular envrionment has. Here it is assumed that $(APPROOT) will be replaced with the absolute base URI of the current application.
The former method is a relative URL that locates resources relative to the server’s root. The latter is an absolute URL that indicates not just the directory, but the host, subdomain, even protocol.
They each have their pros and cons. Using a relative path makes it easier to migrate to a new domain since the domain name is not part of the URL. Using an absolute path makes it easier to organize your files since you don’t have to use things like ../../images/ (which can makes things messy and difficult to read).
As for performance, the only issue is that the absolute URLs are a slightly longer (though not always), otherwise no.
There is no performance issues but many times you work and test in a development environment and if you use the second form it would imply to change something like this:
<img src="http://beta.example.com/myapp/img/world.gif" />
to
<img src="http://www.example.com/myapp/img/world.gif" />
So it's better to have always an absolute-relative URI for all the resources
Use your web application framework's HTML helper for generating URLs.
For example,
In Java Servlets: <c:url value='/img/word.gif' />
In CakePHP: <?php echo $html->url('/img/word.gif'); ?>
In Rails:`<%= link_to ... %>
The reason for using your framework's HTML helper is because moving your web application will not disrupt your URLs.