Best practice for dynamic text field?

[DevDave]

Dear Concerto Team and community,

i recently came across Concerto and currently evaluate it for our purpose.
thanks for making available this cool project!!

for our planned site, there will be a lot of dynamic content and i am unsure how to proceed.

there should be e.g. a dynamic text field, which displays a version number which needs to updated one a minute.
what is the general recommendation to display this version number?

creating a new content with the updated version number  does not seem like a good solution to me.
so i created a text field and traced down the entry in the concerto database backend, where it sits in the contents table, 'data' column.
if i simply update the data column there, the change will not be displayed on the screen.
i fiddled more and updated the 'updated_at' column in the fields table. this results in displaying the correct data entry from the contents table,
but produces a full reload of the screen(?).

so this is a lot of guesswork. is there some guideline available how to do this properly for a text field?

(i assume i will have the same issues for images later. (i know iframes exist, and i am already using them), but dynamically updated pics would be beneficial).

any hints would be appreciated,
thanks in advance

[Marvin Frederickson]

Best practice would probably be to create a custom concerto plugin, if it could meet your needs.  I am curious-- can you tell me a little more about the dynamic content, what it is, where it is coming from, and how frequently it is updated?  

You plan on updating a version number once a minute?  I'm wondering if you could expose what you need through an RSS feed and then possibly add it as rss content.  This is dynamic content, though it is only refreshed about every 5 minutes-- two areas impact this timing (see https://github.com/concerto/concerto/blob/master/lib/cron.rb#L12 and https://github.com/concerto/concerto/blob/master/app/models/dynamic_content.rb#L39).

You said that when you change the data in the content record in the database that it is not reflected on the screen-- perhaps it is a caching issue and you need to generate an etag header that contains a hash of the data column? Perhaps in the show method of this controller https://github.com/concerto/concerto/blob/master/app/controllers/frontend/contents_controller.rb?

You should not update the updated_at column in the fields table.  That is part of the data used to determine if the template needs updated and will result in an entire screen refresh.

[de...@gmx.de]

Hi Marv,
thanks a lot for the detailed reply!

Being a huge fan of the K.I.S.S. principle, i was really looking for the
easiest way to do this! ;)
Especially since this is a tech-dev project for now and I don't know
yet, whether we will go this way in the future, i was trying to avoid
getting familiar with ruby at this point...

Our plan is to expose a couple of numbers like processed customers and a
version number that both change frequently.
Therefore we would like the short, 1 minute update interval.

So i started looking at the concerto log file, did some fiddling and
found this:
I started with the string 'version: 41' in the data column of my field
in question.

mysql> select id, name, data from contents where name='Platform Version';
| id | name | data |
+----+------------------+-------------+
| 16 | Platform Version | version: 41 |

after restarting apache on the concerto system, the correct text
('version: 41') is displayed in the ticker field.

then i updated the content in the db table manually:

mysql> update contents set data='version: 42' where id=16;

this db update is not reflected on the screen. shift-reload (to bypass
the cache) in firefox (FF) does not help.

then i opened this link:
http://192.168.101.181/frontend/6/fields/2/contents.json
that afai understand returns the content for the ticker field i am
looking at:
[{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
41"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
41"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
41"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
41"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
41"}}]
not 0
i am not sure why there are 4 entries in the returned list... but note
that data still has the old value ('version: 41').

reloading the contents.json in FF did not change this;
BUT:
shift-reloading in FF did:
[{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
42"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
42"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
42"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
42"}},{"id":16,"name":"Platform
Version","duration":16,"type":"Ticker","render_details":{"data":"version:
42"}}]
0
I guess this tells us, that the correct text ('version: 42') is actually
served by the concerto server!
and after shift-reloading the contents.json, a simple reload of the FF
concerto screen shows the correct text as well.

so as you suspected, this actually seems to be a caching issue in the
browser. i was wondering if the simplest solution could be to add some
pragma info for no-caching to the html code delivered by the concerto
server...

and.... no :(
i tried to modify app/views/layouts/frontend.html.erb with something
like this, but no avail:
<meta http-equiv="Cache-Control" content="no-cache, no-store,
must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">


what do you think?

thanks in advance,
best regards from Cologne :)

On 17-03-02 07:13, Marvin Frederickson wrote:
> Best practice would probably be to create a custom concerto plugin, if
> it could meet your needs. I am curious-- can you tell me a little
> more about the dynamic content, what it is, where it is coming from,
> and how frequently it is updated?
> You plan on updating a version number once a minute? I'm wondering if
> you could expose what you need through an RSS feed and then possibly
> add it as rss content. This is dynamic content, though it is only
> refreshed about every 5 minutes-- two areas impact this timing
> (see https://github.com/concerto/concerto/blob/master/lib/cron.rb#L12
> and https://github.com/concerto/concerto/blob/master/app/models/dynamic_content.rb#L39).
>
>
> You said that when you change the data in the content record in the
> database that it is not reflected on the screen-- perhaps it is a
> caching issue and you need to generate an etag header that contains a
> hash of the data column? Perhaps in the show method of this
> controller https://github.com/concerto/concerto/blob/master/app/controllers/frontend/contents_controller.rb?
>

> You should *not* update the updated_at column in the fields table.

> That is part of the data used to determine if the template needs
> updated and will result in an entire screen refresh.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Concerto Digital Signage" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/concerto-digital-signage/t2nMPOpk8Qs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> concerto-digital-s...@googlegroups.com
> <mailto:concerto-digital-s...@googlegroups.com>.
> To post to this group, send email to
> concerto-dig...@googlegroups.com
> <mailto:concerto-dig...@googlegroups.com>.
> Visit this group at
> https://groups.google.com/group/concerto-digital-signage.
> For more options, visit https://groups.google.com/d/optout.

[Marvin Frederickson]

I think that we really do want caching, so turning it off unconditionally wouldn't be good for performance.  However, the caching should work properly so that when the content changes on the server, the client (frontend) gets it instead of using a stale cache.  I will create a ticket for this.

[DevDave]

On Friday, March 3, 2017 at 6:10:48 PM UTC+1, Marvin Frederickson wrote:

I think that we really do want caching, so turning it off unconditionally wouldn't be good for performance.  However, the caching should work properly so that when the content changes on the server, the client (frontend) gets it instead of using a stale cache.  I will create a ticket for this.

Hi,
thanks again.
Is said ticket visible somewhere? How can I help to get this going?

thanks

[Marvin Frederickson]

The code has already been merged and will be included in the next release.

https://github.com/concerto/concerto/pull/1398

--
You received this message because you are subscribed to the Google Groups "Concerto Digital Signage" group.
To unsubscribe from this group and stop receiving emails from it, send an email to concerto-digital-signage+unsub...@googlegroups.com.
To post to this group, send email to concerto-digital-signage@googlegroups.com.

[DevDave]

NICE!!!
I replaced the code line and now changes to the DB contents table are reflected on the screen!
thanks a lot for you help!
:)