Re: [Tiki-users] A good way of representing record subtypes with trackers

Mm…

Your "main" item should have specific information for the event, let say:
Date, Time, Source Host, Events (item Link)

Your Events tracker could hold the event information
Type (keyboard, mouse, etc) of event, …

The Keyboard (possible) events
A, B, C, ctrl-c, etc

The mouse (possible) events
move, click, double-click, …

You can use then a customSearch to filter hosts and the key it doesn’t have to be in the same tracker.

If you use facet and elasticSearch you can acheive a more nice to use interface.

I like to test such thing because as I type it, I wonder if you couldn’t improve and use 2 trackers (main and event) only and then categories (type of event)

Sure that doing it will open more options depending of the big plan. (IE: may be you should start with a "host" tracker and then link/create events to the host item (so you can use item-list to search then).
… Relation field too can be an Ace in this game. ;-)

Bernard

PS: If you need (and can) we can look at that online… if others want to join I guess that will be welcomed.



> On 28 Feb 2021, at 19:32 , Ilya Perminov <[email protected]> wrote:
> 
> Hi Bernard,
> 
> Thanks for your answer. I like the option of storing event details in separate trackers, but I think it makes some queries tricky. That's probably because I do not have much experience with Tiki).
> For example:
> each event has field "source host" stored in tracker "Common event data";
> a key press event has field "key" stored in tracker "Keyboard events";
> the two tracker are linked.
> How do I search all key presses of key 'a' received from 'myhost'?
> 
> Thanks,
> Ilya
> 
> On Sun, Feb 28, 2021, 02:28 Bsfez Tiki via TikiWiki-users <[email protected] <mailto:[email protected]>> wrote:
> Hello Ilya,
> 
> I would first evaluate the "next " steps because the answer to your question depends of the big plan (and its size). ;-)
> 
> Putting all in one tracker is easier to create but can turn to be too dense for an easy "user" items management.
> 
> Having several sub-trackers offer better flexibility and granularity settings (like permissions screens, status, etc).
> 
> Not having to read/load all the item fields values for sorting or reporting also help (as I experienced) in term of load and speed page.
> 
> 
> How far you want to split… hard to say (how many items, events expected ?)
> 
> Raw answer, I would go for your last option :
> 
> > Define one tracker for common fields, one tracker per class for
> > class-specific fields and link the trackers via item links.
> 
> Bernard
> 
> 
> > On 27 Feb 2021, at 10:10 , Ilya Perminov <[email protected] <mailto:[email protected]>> wrote:
> > 
> > Hi,
> > 
> > Imagine we want to represent some events using trackers. Each event
> > has event class, event timestamp, maybe some other common fields, and
> > some fields that are specific to its event class.
> > The classes can be  key press, mouse click, timer event, etc. For a
> > key press we want to store which key was pressed, for a mouse click we
> > want to store a mouse position, for a timer event a timer id, etc.
> > What is a reasonable way of doing this?
> > I can think of 3 options:
> > - Put all events to one tracker that has a union of all fields from
> > all event types. Hide/show class-specific fields based on the selected
> > event class, probably using rules. This seems a bit hard to maintain,
> > e.g. if there are 5 class-specific fields for each class and 4
> > classes, I'll have to define 4 rules with 20 hide/show commands each.
> > Plugin JQ may help, but I am not sure how to inject it into a standard
> > tracker item editor.
> > - Define a tracker per event class and give the common fields the same
> > names in all the trackers. Plugin List can fetch items from multiple
> > trackers, so it may work, but I think it is a bit hackish, and plugins
> > that take only one tracker will not be usable.
> > - Define one tracker for common fields, one tracker per class for
> > class-specific fields and link the trackers via item links. This is
> > how one would do it in a SQL database, but I think doing joins in
> > TikiWiki is not that easy.
> > 
> > How do people usually handle something like this in TikiWiki?
> > 
> > Thanks,
> > Ilya
> > 
> > 
> > _______________________________________________
> > TikiWiki-users mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/tikiwiki-users <https://lists.sourceforge.net/lists/listinfo/tikiwiki-users>
> 
> 
> 
> _______________________________________________
> TikiWiki-users mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-users <https://lists.sourceforge.net/lists/listinfo/tikiwiki-users>
> _______________________________________________
> TikiWiki-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-users

_______________________________________________
TikiWiki-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tikiwiki-users