Re: [tracecompass-dev] Proposal for a way of working with views and view

[Matthew Khouzam <matthew.khouzam@xxxxxxxxxxxx>]

On 16-04-26 10:42 AM, Matthew Khouzam wrote:
> pre-emptive tl;dr - make the viewers less smart and re-usable.
>
> Hi all, I am proposing a new architechture for Oxygen. I wish I had time
> before the feature freeze of neon, but let's face it, that won't happen. :)
>  
> Right now we have views and viewers. All (most) of our views are
> TmfViews. What is a TmfView? Something that can be time aligned and
> pinned. Not much else.
>  
> What is a viewer? it is a super-powered item that contains a lot of
> logic pertaining to traces and analyses.
>  
> What is a trace? a container of events.
>  
> What is an analysis? something that does something something...
>  
> The good news is, I think we got the trace's role down perfectly.
>  
> Here's a new repartition of responsibilities I propose.
>  
> The view: has a notion of the trace, has all the signal handlers.
> Notifies its viewers and supplies viewers with analyses, never the trace.
>  
> The analysis: has all the information necessary to populate a viewer. (including start and end times if needed)
> This has a view model and the logic to fill it.
>  
> The viewer: (reduced responsibility) gets an analysis and refresh
> signals and updates its data with these signals and model.
>     The viewer( or later the viewer content provider?) must advertize
> the moduleIds it needs.
>  
> The trace: stays the same.
>  
> This should reduce the view-viewer coupling, and allow for a more
> modular way of integrating viewers into views.
>  
> Prototype for TmfView:
>  
> TmfView{
>     private trace;
>     public signalhandlers; // updates the viewers and the initial state.
>     private Viewer viewers; // or a collection?
> }
>  
> Analysis{
>     String ID;
>     doIt(); // schedule and execute
>     getOutput;
> }
>  
> Viewer{
>     String getModuleId();
>     update(analysis);
> }
>  
> Trace{
>     // same
> }
>  
> This would be a HUGE change IMO, but would make the code more
> extendable, testable, and also make sense of why we have a view and
> where what code goes. At this moment, we have the viewer and the view
> playing with the trace and the analysis. This is looking for trouble.
>
> tl;dr - make the viewers less smart and re-usable.
>
> Thoughts?
> _______________________________________________
> tracecompass-dev mailing list
> tracecompass-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/tracecompass-dev