ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
961
|
Thu Feb 24 12:44:29 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | 2.5.6 | Re: HTML 4.1 transitional validation fails |
> > > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> >
> > > it should be used an HTML entity instead of the ampersand sign.<p>
> >
> > Can you please be a bit more specific? In which URL should the ampersand be
> > replaced?
>
> uhmm...
>
> http://midas.psi.ch/elogs/Forum/page2?mode=threaded&expand=0&last=7
>
> the bug is also a "documentation bug", infact similar tricks are also
> in FAQs (FAQ 5 for example)
>
> I tried to substitute avery occurrence of hard coded "&" with "&" but it does
> not do the job at all ... infact the first time the HTML code is ok, but
> following a link let the browser to automatically decode html entities .. and
> everything turns wrong again ... maybe the encoding should be done in
> printing-to-the-browser-time ..
BTW, the current url (taht should be perfectly well formed makes the elog not to
display attachments ... so may be thare is a problema in the query string decoding
routine ...
http://somehost.it:8080/LBNAME/?mode=full&attach=1 |
962
|
Thu Feb 24 12:45:02 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | r. 1.571 | Re: HTML 4.1 transitional validation fails |
> > > as this url shows http://www.htmlhelp.com/tools/validator/problems.html#amp
> >
> > > it should be used an HTML entity instead of the ampersand sign.<p>
> >
> > Can you please be a bit more specific? In which URL should the ampersand be
> > replaced?
>
> uhmm...
>
> http://midas.psi.ch/elogs/Forum/page2?mode=threaded&expand=0&last=7
>
> the bug is also a "documentation bug", infact similar tricks are also
> in FAQs (FAQ 5 for example)
>
> I tried to substitute avery occurrence of hard coded "&" with "&" but it does
> not do the job at all ... infact the first time the HTML code is ok, but
> following a link let the browser to automatically decode html entities .. and
> everything turns wrong again ... maybe the encoding should be done in
> printing-to-the-browser-time ..
BTW, the current url (taht should be perfectly well formed makes the elog not to
display attachments ... so may be thare is a problema in the query string decoding
routine ...
http://somehost.it:8080/LBNAME/?mode=full&attach=1 |
966
|
Wed Mar 2 15:00:04 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | All | | Re: length of fields |
> When creating/updating entries in elog, excluding the main text field are
> there any limits on the size of the other fields?
Yes, this is controlled by the variable NAME_LENGTH in elogd.c, which is
currently set to 1500 characters. You can try to increase this and recompile,
but at some point you will produce a stack overflow and elogd will crash. So
the current length is a compromise.
- Stefan |
967
|
Wed Mar 2 15:19:56 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | r1.571 | Re: boundary problem with Type lists display |
> using:
> Display mode = threaded
> List display = Subject, Type, Author, Date
>
> in the config file (omitting "ID" then) rise the bug
>
> ie, an unneeded "," is displayed after the "supposed to be printed" ID
Fixed in CVS revision 1.574 |
968
|
Wed Mar 2 17:31:33 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | r. 1.571 | Re: HTML 4.1 transitional validation fails |
> > I tried to substitute avery occurrence of hard coded "&" with "&" but it does
> > not do the job at all ... infact the first time the HTML code is ok, but
> > following a link let the browser to automatically decode html entities .. and
> > everything turns wrong again ... maybe the encoding should be done in
> > printing-to-the-browser-time ..
That won't help, since the 'Start page = ...' string is used for redirection (outside
of any HTML). The '&' thing should only occur inside the HMTL text.
I changed elogd.c to encode things properly, but I'm not sure if I covered all
occurences. Can you try release 1.576 if it works correctly? |
969
|
Thu Mar 3 10:21:21 2005 |
| Paul Harrington | paul.harrington@oup.com | Question | All | | Re: length of fields |
> > When creating/updating entries in elog, excluding the main text field are
> > there any limits on the size of the other fields?
>
> Yes, this is controlled by the variable NAME_LENGTH in elogd.c, which is
> currently set to 1500 characters. You can try to increase this and recompile,
> but at some point you will produce a stack overflow and elogd will crash. So
> the current length is a compromise.
>
> - Stefan
Thanks. Thats useful to know.
Paul |
974
|
Mon Mar 7 16:05:22 2005 |
| Emiliano Gabrielli | AlberT@SuperAlberT.it | Bug report | All | rev. 1.51 | Display <attribute> do erroneously encoded |
Display subject = <b>$subject</b>
is printed to the browser encoded, so that it is diplayed as is.. |
975
|
Tue Mar 8 13:16:14 2005 |
| Paul Harrington | paul.harrington@oup.com | Question | All | | Re: length of fields |
The reason for the earlier question is that we are trying to use Elog to store
data in a form we'd need to store more 1500 characters in more than one field.
Is it possible to get around this problem by having more then one main text field
per record?
thanks
Paul
> > > When creating/updating entries in elog, excluding the main text field are
> > > there any limits on the size of the other fields?
> >
> > Yes, this is controlled by the variable NAME_LENGTH in elogd.c, which is
> > currently set to 1500 characters. You can try to increase this and recompile,
> > but at some point you will produce a stack overflow and elogd will crash. So
> > the current length is a compromise.
> >
> > - Stefan
>
> Thanks. Thats useful to know.
>
> Paul |