Which technology supports creating a web application for graph and tree visualisation? - graph

I am looking for a technology which offers the best and the easiest way to create a specific web application. Besides the standard features like registration, login, CRUD etc., the application needs to give a user the ability to interact with graph/tree structures:
Create a graph/tree
Add/remove/edit nodes and edges
Visualise the current version of a graph/tree
Visualisation and interaction with the visual is the only challenge here. Animations are nice to have, but not mandatory.
If you have any tutorial or example project, I would appreciate it.

Related

Deciding which tools to use for a web project (SharePoint, Workflow, ASP .NET)

I have a question about a project we are planning to develop.
I will start by describing the project and later I will expose the possible approaches I see to tackle this task. I hope you can give me your opinion on them.
There are 2 main parts:
First part:
In our organization we want to create a kind central access point where users will log in (just one time) and from there they will have links (depending on their roles) to the different services we provide.
Approach:
We are using Active Directory to manage our users, so we thought to create this central access point with SharePoint Foundation.
Do you think that it is a good approach?
Second part:
We have services as a SharePoint were users can share documents, and also other web apps. The idea is to integrate all that in to the previously described central access point.
So far, so good. Now we were asked to develop a new web application. This application will be also part of our services; therefore will be needed to integrate it in the central access point.
Description of the application: It will be an application were 3 different roles of people will fill some information (in an specific order, 1st role will fill in, then the 2nd role, and then the 3rd role). After each step of filling information the next person will be informed by email that his/her part is ready to be filled in. The information to be filled in is an evaluation of a product (just for your information).
The managers of the organization will also want to have a control panel were they can have some statistic over the use of the application. There they can see thing like pending evaluations, evaluation per year, per role, …
Approaches:
As you will see our main doubt are about using
SharePoint Site <--> ASP .NET Pages (C#)
Workflow (SharePoint Workflow or just Workflow Foundation) <--> Using some flags in the internal code to control the workflow
We were thinking to:
1- Giving the idea that we would like to use SharePoint for our “central access point”. We would create the app as a SharePoint web (Using SharePoint Designer 2010 if possible). And apply the SharePoint Workflow to the process.
2- Create an ASP.NET Site and export it as a web part that we can integrate as an application in SharePoint. Try to use somehow the SharePoint Workflow on that. (We actually don’t know well how to do it).
3- Create an ASP .NET Site and forget about the Workflow tools, as our workflow is quite small and sequential, and control all that in the code with some flag.
What do you think about our ideas at the moment? Would you propose us something different?
Thank you very much for your help
Our SharePoint is the free version SharePoint Foundation.
Option 1 sounds the best fit for your approach as long as the web-app isn't aspiring to be something totally outside SharePoint bounds.
As far as basic workflow support goes, the SP Foundations should not be an issue. Refer this article for further details on workflow support in SP Foundations
Options 2 and 3 sound a little adventurous and will involve a lot of custom code which SP will provide you OOTB anyways.

Are there any real-world case studies on the ASP.NET Dynamic Data Framework (DDF)?

I just wrapped up an arch review and next-gen recommendation for a client of ours that needs about the deepest level of customization I’ve ever seen for an application. Their desire is to customize their enterprise web application from the UI to the back-end by customer (40+ customers needing control-level customization). The customization will even include special business rules engines and very complex logic involving the transportation industry. As much as is possible, they want developer nirvana by automating everything so customizations can be driven by their customers and have minimal to no involvement by their devs.
Based on my research, though there will need to be some additional plumbing built in as well as security, the DDF will get them closer to their goals more than anything else out there. However, they're requesting more detailed information than what I provided for them.
I really need a case-study or some other such testimony of an enterprise-level company that has successfully implemented the DDF and gives details as to the enterprise problems it solved for them. Any direction or help would very much be appreciated. Thanks!
Since it is now July, your question is probably OBE by now. However, I have designed and fielded a transportation scheduling web app (ASP.Net 4.0) currently in use by 15 facilities within the Army and Air Force using Dynamic Data. This is a single instance, scalable web appplication adapting to customer requirements through database resident configuration settings. I extended the field templates to use Telerik ASP.Net controls and be configurable by user role and facility.
I have found little in the metadata that was much of a hindrance in providing a flexible configurable UI.
Well at least one word of caution. One important aspect (and selling point) of DDF is the assignment of metadata attributes to help scaffold columns and tables and the use of new dynamic data controls to gain advantage of that metadata (like QueryableFilterUserControl or DynamicDataManager or PageAction). One aspect of metadata however is that it is assigned at run time, and cannot be manipulated once the application has started. Therefore different users would all be logging into basically the same metadata set, and customization based on user would be a nightmare. You can certainly set security and permissions based on group roles, but control level customization would be difficult. I hope this helps.

Creating collaborative data flow charts

I need a tool which can be installed on .aspx platform (on a intranet of a company) which can be used to create collaborative data flow chart diagrams (multiple users can edit the diagram by visiting the intranet webpage).
Have you tried gliffy? - I've seen it used on intranets before, not sure if it's .net or if you can share it, but I recommend it.
I am not aware of a collaborative diagram program that allows you to store the data on your servers. An on premise solution would probably be prohibitively expensive. These SaaS guys aren't really setup to provide that option. You probably would have to get an open source solution and build it out yourself. The company that I work for (Lucidchart) does have a flow chart maker that allows you to lock down the domain so you can't share it with third parties and allows license de-provisioning for someone who leaves the company.
Source: I works for a diagramming company.

Implementation of a ASP.NET based portal-like application

There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.

Recommendations on how to decouple services (RSS, REST API) from my UI (webforms) when they share a common model?

I have a web application that is arranged into data, business and UI projects. As the system evolves changes are deployed by building all three projects and deploying them in one package. This has worked well and has allowed the illusion of “three tiers” without tackling the communications, versioning issues of truly separate systems.
So along comes a request for XML summaries of some of the data and my thoughts turn to a fancy WCF service that, one day, could be my “Web API” (ahh… the mind.. what a evil little monkey it is). So, assuming this survives the “is that really the best idea?” test here is my question:
What structure have you had the most success with when posed with two
evolving “clients” serving content from a single evolving “model”?
James, your question is rather board as there are a large number of variables that go into choosing the right type of architecture for your needs. I would recommend reading the patterns & practices Application Architecture Guide 2.0 to better understand the options and pick the best one that suits your individual needs.

Resources