Could you implement a 'hide attribute' and 'sort attribute' config option?
While sort is probably not so easy to do the hide option would already
be very useful. What I want to do is to use elog to collect bibtex entries
which are then used to generate a bibtex file. So, e.g. if the entry
type 'Article' is selected I would like that all fields that do not make
sense are hidden. Currently I just lock them. The config looks like
this:
Attributes = Login, Bibtex Key, Entry Type, Address,
Annote, Author, Booktitle, Chapter, Crossref, Edition, Editor, Howpublished,
Institution, Journal, Key, Month, Note, Number, Organization, Pages,
Publisher, School, Series, Title, Type, Volume, Year, URL, Short Comment
Options Entry Type = Article{1}, Book{2}, Booklet{3}, InBook{4},
InCollection{5}, InProceedings{6}, Manual{7}, MastersThesis{8}, Misc{9},
PhDThesis{a}, Proceedings{b}, TechReport{c}, Unpublished{d}
Required Attributes = Entry Type
; ARTICLE
{1} Comment Author = [required]
{1} Comment Journal = [required]
{1} Comment Title = [required]
{1} Comment Year = [required]
{1} Locked Attributes = Address, Annote, Booktitle, Chapter, Crossref,
Edition, Editor, Howpublished, Institution, Key, Organization, Publisher,
School, Series, Type
Instead of Locking the attributes, hiding them altogether would make the
entry form look much nicer.
A further improvement would be to sort the attributes, e.g. for author I
would sort the like this, i.e. the more important entries first:
{1} Sort Attributes = Author, Title, Journal, Volume, Pages, Year, Month,
Number, Note
Attributes not mentioned in the sort line could then be displayed
in any order. |
> Display Subsystem = <a href="/LogBook1/?Subsystem=$Subsystem" style="color:
> saddlebrown">$Subsystem</a>
>
> ABC and DEF links would perform filter searches of a _different_ logbook.
>
> MOptions does not work because the options are not fixed. The options can be any
> numeric ID for items in a related logbook.
>
> Consider the case of two logbooks, where we wish to associate items in the second
> logbook with more than one item in the first logbook. We could define separate
> attributes for each "parent item", e.g. Parent1, Parent2, Parent3, then use a
> "Display" spec to convert a numeric ID into a hyperlink to the first logbook's item.
> The exact relationship is not important, could be parent/peer/child - some generic
> relationship.
>
> The benefit here would be the same as having separate links for MOptions attribute
> values.
Ah, now I'm getting your point. You want kind of relational database where a logbook
correspond to a table, using the entry ID as primary key. Well, elog was not designed
having that in mind, so its capabilities will always be very limited. A MySQL with
phpMyAdmin might be better for that.
But what you could do is to put manual links betweek logbooks. If you enter in an
attribute following text:
elog:Forum/816 elog:Forum/806
then you get two links to entries 806 and 816. Writing this is a bit more than just
"816 | 806", but it's less than writing directly an HTML link. |
> > Can "Display" links work with multiple options?
> >
> > "ABC | DEF" is currently one link.
> >
> > Ideally, it would be two links, each formatted per the "Display" string.
>
> I don't understand your qyestion. You have an attribute with MOptions, so you
> get "ABC | DEF" displayed in the list view. All links in each line point to
> the individual entry, so what is the benefit of having two links for ABC and DEF?
Display Subsystem = <a href="/LogBook1/?Subsystem=$Subsystem" style="color:
saddlebrown">$Subsystem</a>
ABC and DEF links would perform filter searches of a _different_ logbook.
Separate links would perform separate searches.
> > Is there a way to disable wildcard matching in searches?
> > A search for "1" returns "1" and "10" and "11".
> > Is there a way to perform an explict match?
> > Could there be a numeric match if the attribute type is numeric?
>
> That should all be possible with the build-in regular expression. Just type
>
> \b1\b
>
> where "\b" means "word boundary". I agree that a numerical comparison for
> numerical attributes would be better, I will put that on the to-do list.
Thanks, this is very helpful.
> > Could there be a multi-value option for free text fields, e.g. comma-
> > separated? This would allow multi-parent relationships between log items.
> >
> > E.g. specifying 12, 15 as a value would create unique Display links
> > for "12" and "15", based on the Display specification for that attribute.
> >
> > This would be like "multiple fixed options", for the purpose of formatting.
>
> Again, this is not clear to me. What do you mean by "display specification"?
> Is it the "List display = ..." option or the "Format attribute = ..." option?
> What is a "multi-parent relationship"? Why do you need multiple options for a
> free text field? Why can't you use the MOptions specification?
MOptions does not work because the options are not fixed. The options can be any
numeric ID for items in a related logbook.
Consider the case of two logbooks, where we wish to associate items in the second
logbook with more than one item in the first logbook. We could define separate
attributes for each "parent item", e.g. Parent1, Parent2, Parent3, then use a
"Display" spec to convert a numeric ID into a hyperlink to the first logbook's item.
The exact relationship is not important, could be parent/peer/child - some generic
relationship.
The benefit here would be the same as having separate links for MOptions attribute
values. |