| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69223
|
Tue Sep 22 09:27:45 2020 |
 | Florian Feldbauer | florian@ep1.ruhr-uni-bochum.de | Question | Linux | 3.1.3 | Re: Query to get values for Attributes |
Thanks for the tipp. I managed to use XPATH to get the values for my Type and Category attributes!
The API, I'm developing for Phoebus is quiet simple. It currently just supports Author, Subject, Type and Category as attributes and the latter two are just lists of values.
| Andreas Luedeke wrote: |
|
That would be a nice feature...
If you are good in parsing HTML you can achieve this feature: when you create a new entry "<elog-URL>?cmd=new", you'll get HTML source code that provides you with all possible attribute choices.
Disclaimer: this only works if you don't use Conditional attributes.
| Florian Feldbauer wrote: |
|
Hey,
I'm trying to integrate the Elog into our SlowControl System (Phoebus/EPICS). As a first step I translated the python library to Java. So writing new Entries and viewing them works.
But for Phoebus, you need a list of the possible values for the attributes. Currently this is done via the config file from Phoebus.
Is there a way to get the values also via a query directly from the Elog?
Cheers,
Florian
|
|
|
|
69261
|
Wed Nov 25 15:10:34 2020 |
 | Florian Feldbauer | florian@ep1.ruhr-uni-bochum.de | Question | Linux | 3.1.3 | Placeholders in Python API |
Hey all,
In the configuration of the Elog one can use
Preset Author = $long_name
Preset Author Email = $user_email
to have predefined values for the Author and Author Email fields when creating a new entry via the web interface.
Is it also possible to use these placeholders when creating a new entry via the Python API?
Cheers,
Florian |
|
69272
|
Wed Dec 2 22:45:16 2020 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | length of condition names |
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it! |
|
69273
|
Thu Dec 3 01:51:49 2020 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | 3.1.3 | Re: Options <...> vs ROptions <...> |
Same problem here, in version 3.1.3. It would be very nice if this worked.
| Wolfgang Bayer wrote: |
|
According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?
|
|
|
69275
|
Thu Dec 3 09:57:20 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | Re: length of condition names |
You can easily use multi-character conditionals, up to 256 chars.
| Harry Martin wrote: |
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it!
|
|
|
69276
|
Thu Dec 3 09:58:44 2020 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.3 | Re: Options <...> vs ROptions <...> |
For conditional attributes, you have to use Options, not ROptions. Maybe I will implement that one day, but only if I will have plenty of time...
| Harry Martin wrote: |
|
Same problem here, in version 3.1.3. It would be very nice if this worked.
| Wolfgang Bayer wrote: |
|
According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?
|
|
|
|
69279
|
Fri Dec 4 02:03:56 2020 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | Windows | Mac OSX | All | Other | 3.1.3 | Re: length of condition names |
Could we update the doc for this?
| Stefan Ritt wrote: |
|
You can easily use multi-character conditionals, up to 256 chars.
| Harry Martin wrote: |
|
The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions. I don't see any update/change to that rule anywhere in the docs.
I have been using multi-character condition names successfully. I find these are easier to use since they can be more descriptive of each condition. It works, but I am concerned I may be doing something that might not be supported going forward. (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)
Thank you, again, for this fine (and, may I add, fun?) tool. I'm having a good time with it!
|
|
|
|
69284
|
Fri Dec 18 18:08:54 2020 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Request | Other | 3.1.3 | outdated debian package |
Hi everyone,
I am currently trying to setup elog as a docker container. I wonder if there is any reason why the elog debian package is stuck at version 3.1.3? Would it be possible to update it to the latest version?
Thanks very much! |