On Thu, Oct 19, 2017 at 12:55 PM Leonardo Maccari <[email protected]>
wrote:

>
>
> On 19/10/17 10:33, Federico Capoano wrote:
>
>
>> Just the examples. The modifications I made are only to the CSS and to
>> the way the d3 function is called from the HTML.
>>
>
> Nice, I guess we can include the most significant examples in the main
> netjsongraph.js repository, I'd suggest to choose one or two, what do you
> think?
>
>
> there are already two of them, ninux and AWMN, in the examples folder.
>
> Have time to send a PR?
>
>
> is it ok with the CSS trick for the properties or we wait to have it fixed?
>
>
I'm super busy, so if we want this to be showcased sooner rather than later
is better to do the PR now and fix the issue later.


>
>
>>
>>
>> Blue circles are important because they tell you visually how big is the
>> part of the network that remains disconnected if you remove one cutpoint,
>> without clicking on the cutpoint (which shows the number of potentially
>> disconnected nodes). So they are not nodes, but their size is important to
>> understand what is happening. maybe we can change the color, or the alpha,
>> or we may change the shape of the cutpoint (from circles to diamonds).
>> I suppose for the latter thing we need to change the library though.
>>
>
> Ok we can play with the alpha.
>
>
> ok, open an issue please?
>
>
which repo?


>
>
> Note that when I use json.dumps() whatever property of the node ends in
>> the "properties" section of the node, which means it is displayed. I hide
>> them with CSS, but maybe there is a better way of putting them somewhere
>> else in the node data.
>>
>
> We should look into add a way to do what you are doing now without using
> properties but other custom attributes that are in the node.
>
>
> another issue?
>
>
Yes please, open one if you can:
https://github.com/netjson/netjsongraph.js/issues/new

done. do you think it is a good idea to add it the topology module, so when
>> one visualizes the topology he can actually choose between several views? I
>> can start digging into it if you think it makes sense.
>>
>
> Yes, I think it would be a nice feature, we could start thinking about a
> generic way to create different elaborations and visualisations.
>
> To accomplish this we should think about either using functions or classes
> that take something in input (NetJSON NetworkGraph?), perform some work on
> it and return NetJSON NetworkGraph output.
> Once we have this defined, we can create a django setting that lists the
> available elaborations/visualisations (let's find a good name for this) and
> we can have a menu item in the visualiser that when clicked shows the
> available elaborations/visualisations, if the user clicks on one of this is
> taken to that view.
>
>
> Exactly, my original plan is to process the NetJSON as soon as it is
> fetched/received  by openwisp from the source url, and store the modified
> NetJSON graph somewhere in the DB (elaborations on the graph may take some
> time, depending on the graph size, so it is better to store then and only
> serve them when you click on the view). Then add a URL to expose the
> corresponding NetJSON and finally as you say integrate the menu in the
> topology view.
>
> What do you think is better:
>  1 - integrate everything into openwisp-network-topology, modify the model
> for the topology adding another field that determines the type ("original",
> "compressed" and one for all the views we add)
>  2 - keep the library separate (as it is now), do a separate django module
> with its own model?
>

We should probably do 1,  including such a feature in django-netjsongraph,
in a similar fashion as we did for the Snapshot/History feature. Rohith
knows what I'm talking about.

openwisp-network-topology is a glue layer that integrates
django-netjsongraph into openwisp2 so we won't need to do much there apart
from integrating the new feature into openwisp2.

I suppose we need to modify the topology view page, so some modifications
> in the topology module are needed even if we go for the second choice.
>

Yes we need to change the visualiser for sure.

> Is your python module published in pypi yet? I don't see any setup.py file
> so I guess it's not published yet.
>
> not yet, need to take 1/2 decision before.
>

The module could become part of django-netjsongraph, or it could live
outside and have its own life, immagine being able to build more
visualizations over time without changing django-netjsongraph, that could
be an advantage if you think it will likely happen.

So what name would you use in place of visualization/elaboration?

Federico

-- 
You received this message because you are subscribed to the Google Groups 
"OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to