Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 17 12:14
    jhickman opened #693
  • Aug 15 11:30
    armogur opened #692
  • Aug 12 16:12
    jhickman opened #691
  • Aug 12 12:26
    jhickman commented #690
  • Aug 11 19:15
    jhickman commented #690
  • Aug 11 18:41
    vegegoku commented #690
  • Aug 11 17:40
    jhickman opened #690
  • Aug 09 20:42
    jhickman opened #689
  • Aug 09 19:54
    jhickman commented #688
  • Aug 09 19:39
    vegegoku commented #688
  • Aug 09 19:26
    jhickman commented #688
  • Aug 09 19:18
    jhickman opened #688
  • Aug 09 13:28
    jhickman opened #687
  • Aug 09 13:01
    vegegoku commented #683
  • Aug 08 19:27
    jhickman edited #683
  • Aug 08 19:21
    jhickman opened #686
  • Aug 08 16:25
    rjeeb closed #679
  • Aug 08 16:25
    rjeeb commented #679
  • Aug 08 16:24

    rjeeb on development

    fix: #679 Readonly TextBox gett… (compare)

  • Aug 08 16:24
    rjeeb closed #685
Nick Gaens
@NickGaens
I'll try to screenshot those.
It's ... weird .... perhaps you can make something out of it.
Frank Hossfeld
@FrankHossfeld
@NickGaens Just checked the demo app. It uses Domino-UI version 1.0.0-RC10. Doing a search inside the navigation tree works as expected. Please, can you check, that there is no additional coding from your side, that causes the error. As far as I can see fro your video, it looks like an element did get inivisible inside a tree item (that should be invisible) Please can you chek the generate code for that element.
Nick Gaens
@NickGaens
@FrankHossfeld Sure, I'll reiterate my code, but I'm quite sure no such custom code exists inside my project. I'll post my findings here later today.
Jan
@HAC-jh

ok you mean the tree expand all/ collapse all

Hi @vegegoku , did you have the chance to investigate regarding that problem?

Frank Wynants
@FrankW76

@FrankHossfeld Did you run the demo app on your own pc? Or are you talking about https://demo.dominokit.org/home?

In the latter case how do you know this is RC10?
Cause the online demo states : Last build on : 2021-10-10T07:04:46Z

Which is before RC10 was released.

Ahmad K. Bawaneh
@vegegoku
Demo is now updated to the latest and I can only confirm the expand all issue for tree component
Frank Hossfeld
@FrankHossfeld
Ah, ok, expected the demo is uptdate. Sorry, my fault.
Frank Hossfeld
@FrankHossfeld
@FrankW76 I took a look at your video. Thought, your were talking about the empty entries inside the tree when searching ...
Frank Wynants
@FrankW76

@FrankW76 I took a look at your video. Thought, your were talking about the empty entries inside the tree when searching ...

It is not my video.
I think @NickGaens is seeing a cache issue (and is in fact using RC10 with old domino css files)

Nick Gaens
@NickGaens
That seems to be the case.
I cleared the .m2/org/dominokit directory and (so I thought) the browser cache, but somehow there must have been cached CSS files still present. The issues I showed above in the screenshot and the recording are no longer.
Frank Hossfeld
@FrankHossfeld
sorry ... was confused, cause both of you are talking about tree issues ... :-)
Frank Wynants
@FrankW76
Do you guys have any hint on how to avoid some domino css files to get cached by the webserver.
image.png
For our own css files, everytime we compile we append a different ?version=1234 to the <link href tags in the index.html file
But for those imported by domino we cannot do this
And we often have the problem when updating domino. That the olds css files are being used
Ahmad K. Bawaneh
@vegegoku
why you cant do the same with domino css files?
Frank Wynants
@FrankW76
I think these are injected or something by domino code?
These are not in my index.html
Colin Alworth
@niloc132
the 304 means that your server is telling the browser "those files didnt change"
Frank Wynants
@FrankW76
Yeah I know.
But for some reason the browser is not telling the truth always.
Colin Alworth
@niloc132
how are you deploying? is it possible that your deployment mechanism (a war for example) is not updating the dates of the files when they are deployed? or that the server could use e-tags?
check the headers to be sure, i would be surprised if the client was the wrong one here
Frank Wynants
@FrankW76
In IIS just copying over the contents of the war...
Or in tomcat just normal deploy.
Colin Alworth
@niloc132
often the server has a bad implementation, where the client says "i last loaded this file at Jan 1", but the server says "well this new release of the CSS came out on Dec 31, but we didnt deploy it until Jan 15, so the file is dated Dec 31 and Jan 1 is newer"
ok, so what i am describing is probably what IIS is doing - two quick suggestions:
  • see if IIS can use e-tags instead, that way it is the hash of the file instead
  • if not, when you unpack the war, touch all the files so that the date on them is the moment you did the most recent deploy
consider for example if you downgraded a deployment, rolled back to an older release
you wouldnt want the server to say "well you have the newer file, so keep that"
you want the server to know that the "old" file was deployed more recently
so you have to update the file's timestamp
(or use etags)
Frank Wynants
@FrankW76

We often have the problem that after updating domino we have weird things.
Until CTRL+F5.

Only thing I can think of (and which I actually do see) is these CSS files are not downloaded because of the 304

Colin Alworth
@niloc132
yes
when this happens, look at the headers, i'll bet you a dollar that what i'm describing is happening
the simplest fix will be to touch each file when you unpack the war (either to tomcat or IIS)
not when you build the war, unless you can promise you deploy instantly after building and never ever rollback to old releases
do you see what i'm saying
Ahmad K. Bawaneh
@vegegoku:matrix.org
[m]
Domino does not inject any css in the inndex page ..we expect you to manually build your html page and add links to those css files
Frank Wynants
@FrankW76
In IIS I can see
ETag: "0eb32f0f914d71:0"
In tomcat
ETag: W/"40635-1615304174000"
Last-Modified: Tue, 09 Mar 2021 15:36:14 GMT

Domino does not inject any css in the inndex page ..we expect you to manually build your html page and add links to those css files

hmmmm...
That is strange....

Colin Alworth
@niloc132
in the response it says that? but it still says 304? that doesnt make any sense
the last modified at least makes sense, that is a very old file, the user probably loaded the app since then
you should discuss this with someone who can help debug the server directly, something sounds like it is misconfigured
Frank Wynants
@FrankW76
image.png