Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 625 of 808  Not logged in ELOG logo
 Find |  Login |  Help 
 Full | Summary | Threaded | Hide attachments  Show only new entries    6457 Entries 
Goto page Previous  1, 2, 3 ... 624, 625, 626 ... 806, 807, 808   Next  
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1913   Thu Aug 24 19:28:35 2006 Reply Steve Jonessteve.jones@freescale.comQuestionLinux2.6.2-1714Re: Auto-refresh ELog display

<html>

<head>
<title>Refresh JavaScript Example</title>
<noscript>
<!--
We have the "refresh" meta-tag in case the user's browser does
not correctly support JavaScript or has JavaScript disabled.

Notice that this is nested within a "noscript" block.
-->
<meta http-equiv="refresh" content="2">

</noscript>

<script language="JavaScript">
<!--

var sURL = unescape(window.location.pathname);

function doLoad()
{
// the timeout value should be the same as in the "refresh" meta-tag
setTimeout( "refresh()", 2*1000 );
}

function refresh()
{
// This version of the refresh function will cause a new
// entry in the visitor's history. It is provided for
// those browsers that only support JavaScript 1.0.
//
window.location.href = sURL;
}
//-->
</script>

<script language="JavaScript1.1">
<!--
function refresh()
{
// This version does NOT cause an entry in the browser's
// page view history. Most browsers will always retrieve
// the document from the web-server whether it is already
// in the browsers page-cache or not.
//
window.location.replace( sURL );
}
//-->
</script>

<script language="JavaScript1.2">
<!--
function refresh()
{
// This version of the refresh function will be invoked
// for browsers that support JavaScript version 1.2
//

// The argument to the location.reload function determines
// if the browser should retrieve the document from the
// web-server. In our example all we need to do is cause
// the JavaScript block in the document body to be
// re-evaluated. If we needed to pull the document from
// the web-server again (such as where the document contents
// change dynamically) we would pass the argument as 'true'.
//
window.location.reload( false );
}
//-->
</script>
</head>

<!--
Use the "onload" event to start the refresh process.
-->
<body onload="doLoad()">

<script language="JavaScript">
<!--
// we put this here so we can see something change
document.write('<b>' + (new Date).toLocaleString() + '</b>');
//-->
</script>


</body>

</html>


Steve Jones wrote:
Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!


Alan Stone wrote:
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?

Thanks, Alan
  1914   Thu Aug 24 20:16:23 2006 Reply Alan Stonealstone@fnal.govQuestionLinux2.6.2-1714Re: Auto-refresh ELog display
I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan


Steve Jones wrote:
Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!


Alan Stone wrote:
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?

Thanks, Alan
  1915   Fri Aug 25 05:27:13 2006 Reply Steve Jonessteve.jones@freescale.comQuestionLinux2.6.2-1714Re: Auto-refresh ELog display
eLog allows one to add custom headers or footers as well as include Cascading Style Sheets. I believe there is a post somewhere in here from Stefan indicating that javascript can be added through one of these methods . . . hold on, a simple search, yes Stefan mentions it at http://midas.psi.ch/elogs/Forum/1837


Alan Stone wrote:
I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan


Steve Jones wrote:
Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!


Alan Stone wrote:
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?

Thanks, Alan
  1931   Mon Sep 11 16:32:52 2006 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.6.2-1714Re: Auto-refresh ELog display

Alan Stone wrote:
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?

Thanks, Alan


The JavaScript is one possibility as Steve mentioned correctly. Another possibility is to use the RSS feed capability of ELOG. Use any RSS reader, and it will notify you immediately if there is a new entry in ELOG. Have a look at http://midas.psi.ch/elog/config.html and search for RSS on how to configure this.
  66414   Thu Jun 25 10:09:18 2009 Reply Stefan Rittstefan.ritt@psi.chBug fixAll2.7.6-2191Re: Auto-increment substitutions broken with records for multiple days
> An alternative patch:
> 
>       /* if date part matches */
>       if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
>           /* retrieve old index */
>          if (atoi(attrib[index] + loc) > old_index)
>             old_index = atoi(attrib[index] + loc);
>   
> does not make this assumption and also appears to work OK when I test it.

Yes, this is the right one, it searches all entries to have the same date than the current one, and then looks for the 
largest index which will be stored in old_index and later incremented by one. I committed your patch to the 
repository. Thanks a lot.
  66097   Fri Dec 5 16:14:19 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukBug reportLinux2.7.5Re: Auto-increment attributes

Steve Williamson wrote:

We have an auto-incrementing reference attribute defined as:

# RFC

Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change

We also have a "Created by/when" attribute.  Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the  $@MID@$ seems to be set when the user clicks "Submit".

# Created

Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date

Every once in a while the incrementing stops working and the number 'sticks' or misses some out.  It looks as if it might be because multiple people are adding entries concurrently.  Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated?  Here is a list showing the discrepancies.

Date        Item     Time Stamp (from the line after $@MID@$)  "Created" attribute time stamp

22/09/08    124      16:15:10                                   11:58

22/09/08    125      16:33:54                                   16:24

 

22/09/08    125      16:35:37                                   16:33              Should be 126

...

10/10/08    146      10:39:09                                   10:30                    Correct

10/10/08    146      10:46:57                                   10:35              Should be 147

10/10/08    147      13:04:03                                   13:02              Should be 148

10/10/08    148      15:11:38                                   15:00              Should be 149

...

17/11/08    171      10:21                                      10:17              Correct

17/11/08    174      14:30                                      13:47              Should be 172

17/11/08    175      16:14                                      16:04              Should be 173

17/11/08    176      16:49                                      16:38              Should be 174

...

25/11/08    187      15:49:58                                   15:47              Correct

25/11/08    187      15:52:39                                   15:48              Should be 188

25/11/08    188      16:49:56                                   16:44              Should be 189

25/11/08    188      16:52:40                                   16:40              Should be 190

25/11/08    188      16:55:17                                   16:43              Should be 191

Let me know if you need any more information.

regards

Steve

 Hi

This is to let you know that the increment problem has just happened again.

Item 206 has timestamp (from the line after $@MID@$) of 11:59:45 and "created" attribute timestamp of 11:29

overlapping with this, a second item 206 has timestamp of 12:04:02 and "created" attribute of 11:53

So, both users were entering information between 11:53 and 11:59:45 and both picked up the same increment number.

There's no easy solution tho, is there? If you pick up the increment number at the start so it can be displayed on screen and ensure uniqueness then, if a user cancels a new entry you end up with "holes" in the sequence.  If you pick it up at the end then you can't display it until the user presses submit.

regards

Steve

  66100   Mon Dec 8 10:09:14 2008 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.7.5Re: Auto-increment attributes

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

  66101   Mon Dec 8 13:13:13 2008 Reply Steve WilliamsonStephenWilliamson@Barnsley.gov.ukBug reportLinux2.7.5Re: Auto-increment attributes

Stefan Ritt wrote:

I finally found some time to address this problem. It is indeed related to the fact that the new number gets assigned when you click on 'New'. So if two people edit the new entries at the same time, they get assigned the same number. To fix this problem, I made the tag generation work with the 'Subst' command, which is evaluated at the entry submission, and not when you click on 'New'. So to make this work, you need to upgrade to SVN revision 2152 and then put into your configuration file: 

Attributes = Author, RFC, Subject
Preset RFC = <will be assigned when you submit>
Preset on duplicate RFC = <will be assigned when you submit>
Locked attributes = RFC  Subst RFC = RFC-######

I also changed the documentation accordingly.

 Stefan

Thanks for fix - I've just tested it and it works beautifully.

regards

Steve

 

Goto page Previous  1, 2, 3 ... 624, 625, 626 ... 806, 807, 808   Next  
ELOG V3.1.5-3fb85fa6