Good WPF TreeList control for real time data - wpf-controls

I'm looking for a good WPF TreeList control (free or otherwise), that behaves reasonably well with lots of cells changing in real time.
Do you have any recommendations?
ps: By TreeList I mean a grid with hierarchical rows that can be expanded/collapsed.

I've tried extensively Telerik's RadTreeList control and Syncfusion's GridTree control.
My assessment is that Telerik's controls are in general better documented and better Architected, but their grid is quite slow doing the initial loading of data, especially with lots of columns. Once ItemsSource is binded the real time update works fast. Therefore if you are going to be switching ItemsSource often I don't think Telerik (as of today) is your grid (e.g. a master detail screen with two grids, one for master records and the other for details... not good because the details grid needs to change everytime the user clicks on a master row)
On the other hand, Syncfusion is very fast for both, loading data and for real time updates. Their documentation is not great though, so you rely on their customer support for answers.
Both Telerik and Syncfusion have very good customer support.

Related

Wireframe for every single screen/page

I am an automated-test engineer and call it occupational hazard, I keep thinking towards making automated testing efficient and easy.
Couple of weeks back, I was thinking, in fact just wondering, if we could introduce a new process where I force designers/developers to provide me a wireframe for every single or unique screen in the web application.
Example: In a hypothetical web application, if home page displays differently for different profiles like associates, approvers, auditors and managers, I want a wireframe for each of those profiles. But if there are 2 managers (data combinations) in the organisation, I don't expect wireframe for these 2 managers as just data is changing and structure would remain same from automated-testing perspective.
This helps in automation in the following manner:
Say a sprint starts and it's decided that 2 new features shall be developed in this sprint.
Wireframes for these 2 new features shall be provided to the whole team at the begining of the sprint say in sprint-planning meeting.
Using these wireframes I would automate my testcases and when the actual screens are deployed, I would just run my automated-testcases. Of course they will fail due to some minor issues but they will be easy fixes. This is way better than not starting automation until the actual screen are deployed.
If this approach is possible, I will later demand for id and name properties of user controls (like links, buttons, edit boxs, check boxes, radio buttons etc) along with wireframes. I am aware that some teams are already sharing id and names properties of user controls with their automated-testing team upfront so that they can automate the testcases even before actual screens are deployed. You could say my idea is little enhanced version of that.
It sounded impractical so I stopped thinking towards it but later felt like I should ask the community if it's possible? if yes, what's the overhead on the overall design/development team.
Some developers reading this might think that pffhhh... we are packed with stuffs already and this would be an overhead. But trust me. Early collaboration with testers and automate-testers would really help the quality of the application. So if the overhead is well within the limit, we could think towards introducing this process.
Please let me know your views.

Xpages design elements, managed bean limits

Sorry not a coding question, not sure if I should be posting it here.
I struggle with the concept of what is 'large' in Notes nsf application design elements as opposed to the amount of data or records stored. For example it is stated that we shouldn't have too many views, but 'too many' does not give any scale whatsoever, is it 10,50,100,500 before it 'slows down'. I realise it also based on the view design but some idea of 'too many' would be beneficial. In this instance data and design elements are in the same nsf.
Is there a recommendation regarding number of elements such as XPages, Custom Controls, Managed Beans, Java Classes etc. What would be deemed excessive? In this instance I have data and logic in separate nsfs.
Any guidance would be greatly appreciated.
Thanks
There is a limit on the number of design elements. But unless you're importing a whole JavaScript framework into an NSF, uou're not likely to hit it.
As has been mentioned, view performance is dependent on many factors. 500 decently designed views are fine. 50 badly performing views can be bad. Lots of resorts on columns impacts the number of indexes that need to be created and managed. Using #Today or #Now in a view selection formula or column formula will be a big problem. Having lots of documents that rarely change, smaller numbers of documents that are updated every 30 seconds, lots of users regularly updating - these will all be impacts on performance.
Performance in code will also impact and XPages Toolbox or agent profiling will give an idea. DocumentCollection.count() is slow, but sometimes is needed. NoteCollections may be quicker. There are various blog posts covering this.
A managed bean that has a Map that grows and grows will impact Java memory.
But there are always performance enhancements being made on the server side. gRPC in Domino 10 will be extremely performant. So always try to be on a recent version and keep up to date with sessions at conferences etc so you know what TCO improvements are being made.
The bottom line is without an intimate understanding of your architecture and code, no one will be able to give you a definitive answer.

Lotus Notes Development (Composite App? Or not?)

I am a new Lotus Developer looking for some advice. I am working with Lotus Notes 8.5.2 and using Designer to develop my applications.
I am designing a new application based on one existing database - the 'People' database. This contains all information on all Employees in a certain environment. Some employees are secretaries to other employees, and this is indicated in the employee record, as each employee (along with name, phone, etc) has a field called 'Secretary'.
What I need to do is be able to click on a record (Person) in one frame, and subsequently load the information on their secretary in a seperate, smaller frame. I understand how to target frames at each other and can load information on the selected person in a new frame.
However I cannot load information on that person's secretary in a seperate frame.
If anybody has any ideas, it'd be much appreciated.
If you have the time to learn the technology, XPages would be the way to go, even in the client. A composite application will work also but for a new developer there is more activity around XPages.
I would avoid spending too much energy learning the composite application architecture. I don't believe this is the real future direction for IBM. You could implement a similar design using XPages and taking advantage of the built-in AJAX functionality. (You can have a page with a section which refreshes to show the Secretary details when you change the employee selection). If you have worked with ASP, the XPages approach will seem very familiar.
There are different levels of coding when it comes to compApps. You can have simple interaction through lotusscript which is reasonably high level, to low level Java/RCP development.
From your description it sounds like you are doing high level actions. So I recommend looking at "My First Wire" tutorial.
http://www-10.lotus.com/ldd/compappwiki.nsf/dx/ibm-my-first-wire
I wrote some time ago but still works. It should explain how to have your code action on a wire update.
As with the others I concur on learning XPages. Later versions allow you to send wire updates to an XPage. A sample is here.
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/XPage_Components_in_Notes_851_Videos.htm
Looking at what u want to make i personally would go for xpages and not for comp app.
And since you said you are new at developing in Domino Lotus Notes i believe your best bet is to go for Xpages.
You will a lot of info,tips, ticks, reusable code and more on:
openntf.org,
planetlotus.org,
xpages.info,
xpageswiki.com,
IBM.com,
and more just google
Advantages are in the already given in above answers:
-
To summarize
- Xpages is for the web and for the notes client
- Far more possibilities than comp app offers
- You will have more control on have the app looks and feels, due to HTML(5), CSS(3) javascript
- A very big online community, on the above sites, in twitter here( Stackoverflow)
- A steep learning curve if u have no knowledge of jvascript, java, html and css, but u will progress in no time.
Here are some books u want.
Mastering Xpages
Xpages the extension library
Xpages portable command guide
Buy number 1 and 3 immediately. Or let your office buy them. Let the admins read Xpages portable Command guide, mm beter order two copies, It has a wealth of info on server settings for xpages, so it is for admins a must read as well.
Considerations:
Like Ben Poole said be aware for complex stuff in regard to
performance
LN client needs to have the extension lib installed if you used it to
develop a App.
The first time u start a xpages i the notes client (XPiNC) u will
have a long load time can be minutes deepending on the application.
This is because the xpage engine is not loaded at NC startup. after
that it wil be faster. First run loadtime say 20 secs, closing it and
starting it approx 2-4 secs.
One other thing if you go for xpages dont try to rebuild it so it looks like it was in the Notes Client.
And since u already have an notes app with views and forms you already have the groundwork.
And u can keep it simple, Ed just gave you a glimps of partial refresh of a page.
Hope it helps

Newb: WPF custom graphic control - where to start

Apologies if there is a thread for this already, I couldn't find one that I could get my teeth into.
Anyway, I'm new to WPF and want to create a custom control that will be a sort of graphic control. The graphic will always consist of a circle, containing a matrix of several squares (from several hundred to several thousand actually) The squares need to respond to mouse click and mouse over events (and ideally be possible to navigate/select via keyboard.) Each square will represent an object I've coded.
In the past I've used a grid control to display the coloured squares (with VCL in CBuilder) but I would like to make a graphical version. (Actually, another question I'd like to ask is, is there a WPF grid control where I can set the colours of individual cells?)
The question is, where to start? Do I start with a canvas and draw on it? Do I derive from an existing object? I'm just a little lacking on ideas on implementation so any pointers or advice you can offer will be greatly received.
BBz
First off I would suggest getting a decent handle on WPF and how it approaches the problem set. It is vastly different from previous .NET Desktop technologies such as WinForms. Once you have a decent understanding in regards to the separation of logic from UI and how WPF approaches the problem then you can dive in and begin making the right decisions based upon what you encounter.
The problem you mention can be solved in multiple ways. In regards to your question about making use of a Grid, that could be done as that is a layout type. It is vastly superior to the Canvas in terms of arranging your visual structure. The defined rows/columns are nothing more then containers which can hold varying UI objects. Therefore pushing a Rectangle into the Grid and coloring as desired would give you the effect you are looking for. This Rectangle could then become a custom control which would allow you to define varying properties on, as well as specific triggers for mouse overs, etc...
At a higher level you will want to encapsulate this logic as a UserControl which will also hold your custom control. Perhaps the UserControl contains the Grid which will make use of your custom control.
Hopefully this gives you some ideas around how to get started, however getting a better understanding of WPF will help you immensely in achieving your goal.

Web Interfaces: What is a good way to display many static fields?

My web applications have pages that display many static fields.
I know that poor layout invariably leads to information overload and poor readability.
My Question:
Are there any best-practices or heuristics for laying out a screen that contains many static fields?
Ordinarily, I would reference Bill Scott and Theresa Neil's excellent book, but I can't seem to find any guidance for this issue.
Here are some guidelines that I'm inclined to follow:
Group related fields.
Position the major (or parent) fields towards the top and the left. Position the minor (or child) fields towards the bottom and right.
Don't feel obliged to fill every pixel. Consider white space if it will improve readability.
Favor progressive disclosure wherever possible.
Consider an accordion control.
Perhaps a Details on Demand approach would work well. Ask yourself which data are absolutely and immediately relevant to the user and group those, while hiding the other data. You can always provide an 'Expand' link or control that would allow a user to view the details if desired.
(It's good to see that you're looking at interface design patterns. They are often overlooked!)
I work on HR software and have faced this problem many times. One thing that we keep seeing in feedback when we introduce collapse controls or any progressive disclosure pattern really is that our users don't like the way those types of "web 2.0" (their words lol) pages don't print out. So just a reminder if your user base still insists on printing large pages of data include a print media stylesheet.
Depending on how large your set of data is I'd seriously consider a some search functionality or a sorting mechanism. Many times when the data set is large different users have different priorities and allowing customization is the only way to satisfy a wide audience.
I think you pretty much answered your own question, especially the grouping of important fields tied to progressive disclosure.

Resources