I need to setup a quite huge Application with arround >20 main views plus forms. A mainview will at least contain one grid but can contain upto ten grids. There are also some mainviews that contains a Portal-Panel.
Now it comes that it take quite some time till a mainview opens which don't happends as I tested it with just one instead of >20. The Application lays within a Viewport with fit layout which holds a container with Borderlayout. The Mainview always render within the center while the other regions are used for navigation.
My first approach caching things within a tabpanel
My first approach was to got with a Tab-Panel with hidden tabs. Parallel to that I manage a MixedCollection where I make lookups if the View has already been inserted into the tabpanel or has to be created. If it has already been inserted I fetch the positon from the MixedCollection and run the setActiveTab(). But it seems worthless cause it takes all the same time to insert a new mainview or to activate a existing with setActiveTab().
So what I am doing wrong and how can I make this better?
Edit
The problem seems to come from the rendertime and that the component seems to get reredenred each time setActiveTab() is used. It takes up to 2-3 secs to render a view into the center panel. Therefore I thought I can be speed it up by caching a already created view so that the rendering and sizing didn't need to be done. I guess I should mention that in the north region a menu is also rendered each time, which not get's chached but that shouldn't matter, shouldn't it?
How the views are switched
I have a extra controller that manages the menue-view and the main-view changes. For that the menue gets removed from the container and the new menue is added and for the main-view a lookup is done in the mentioned mixed-collection if the view has already been created and if so the tab-index is received and the tab activated. If not the view get added as new tab and is afterwards added with it's ident and index to the mixed collection.
It may help you to take a look at suspendLayouts() and resumeLayouts()
You run Ext.suspendLayouts(); before you begin changing the views and Ext.resumeLayouts(true) after you are done with all views.
You should also check for overnesting, meaning you have nested to much components into each other.
Example:
If a grid is the only component within a tabpanel then it would be overnesting if you place that grid in a extra panel and then into the tabpanel.
Firstly what I found that non active tabs will be populated anyway. I don't know why. But my stores for not active tabs loaded anyway.
Second, it is really doesn't matter the size of your app. We have a lot of views and everything works pretty fast.
In most cases it is depends:
First is nesting - review your code. Less nesting more speed. For example instead of panel if you dont need all stuff that panel provide- use container. Because all this stuff is add more divs to your dom.
Depends how you create your view. Without your code it is really hard to say, why it is slow. Maybe you create your view every time when you open tab, or go to another view.
As mention #sra try to use suspendLayouts - it means that your browser will render your stuff only resumeLayouts, instead of rerender everything everytime when you add any component.
If you use windows - use closeAction:hide instead of destroy.
Not use Ext.getCmp(). I also hear that refs can slow down application because they start searching your component from the body. But it not proved info :) Use component.down('id'), component.up('xtype') it will search only from your component not from the body.
Not create your view from controller everytime when you do something using Ext.create('Panel'). It means it will created everytime.
Use less global events because this is also slowdown your app.
It is really hard to say what is the issue in your case without code. This is only few point that can help you. But my suggestion to looking to nesting and how and where you create a view.
Related
My app shows long lists of containers and when the user edits the content one of them, the whole list must be refreshed since the content in the other containers may change (they may also change size).
Currently I do this simply by getContentPane().removeAll(), followed by recalculating all the containers, and then revalidate() to show the updated form. However, when I do this the list scrolls back to the top.
How can I keep the same scroll position in the list, eg that the new instance of the just edited container stays in the same place on the screen as before? I know scrollComponentToVisible(Component) but as far as I can see it doesn't allow me to place a container in exactly the same spot on the screen as before the refresh.
Since you rebuilt the position might change so calling setScrollY() directly probably won't provide the same position I don't think that's doable since you need functionality that's closer to scrollComponentToVisible.
You know, like in CCleaner app where main activity is on the left side of the app and the right side area is changeable fragment.
http://cache.filehippo.com/img/ex/3049__ccleaner1.png
How to do it? I imagine I could do it by putting all fragments in the same place and just change their visibility to show just 1 at the moment, but that would make the code a whole lot of mess.
I've done this in the past by using UserControls. It's worked nicely for things like choosing payment methods (cash, cc, cheque...).
There are a couple of options for changing the display, either have all the UserControls present on the form and hide or show them as required or have an empty placeholder panel and use a factory to construct the appropriate UserControl as needed. I've done both and it really depends on the complexity (and expected longevity and users) of the project as to which is appropriate.
Using a Model-View-Presenter pattern helped with managing all of this.
What you don't want to end up with is a massive switch statement that changes the visibility of dozens of manually positioned controls individually. I've seen it and that way lies madness.
I am optimizing my application. Originally, it's a Ext.TabPanel but I decided to use only a Ext.TabBar docked at the bottom and change the views above, so it requires a lot of add/remove actions from my main Ext.Container.
So my question is: in what way I should do to add/remove items from my Ext.Container effectively? I mean: fast, not cause memory-leaks, and also, not cause error like this: the view with a button in it, firstly added, all handlers (which are define through refs and control in a controller) work well but the second time (i.e it's removed and added again later), all handlers die.
Thanks in advance!
You have to ensure that you destroy the panel is destroyed otherwise it would be sitting in the dom.
Generally to remove a component from a container you use the Container remove() function which takes in the first parameter as the item to be removed and the second one is a boolean which instructs for it to be destroyed or not. You should ensure you set it to true to make sure you keep your DOM as lean as possible. Unless you're going to be reusing that component in the near future and do not want to render it again, then you do not need to destroy it.
http://docs.sencha.com/touch/2-0/#!/api/Ext.Container-method-remove
My aim is to make a editor behave similar to MS-Word.Wpf RichTextBox is a wonderful control for it.By placing it inside a ScrollViewer,we can make it editable.(Like a notepad).But I need MS-Word like pages.One effective way probably is to apply style to scrollViewer such that we create a look and feel of multiple pages on richtextbox but I dont know how to do it.What we are doing in the project is to use a documentViewer. Inside a FixedPage,create a Header(Canvas),Body(WpfRichTextBox),Footer(Canvas). And thus create multiple pages,and by subscribing to RichTextBox sizechanged event, we are manually doing the pagination i.e move the blocks from one page to another when height has changed. Do you see any better approach in doing this? Does using multiple richtextboxes hamper my performance?
#WpfProgrammer This is the good approach I would say. Say if you have 1000s of pages then, there will definitely be a performance problem. For avoiding that problem, you need to do demand paging.
Virtual Paging :
1. You need to construct a page table, which will contains pages. Each page will contains information about the controls, images, their positions, dimension and Styles for the page. [All serializable data]
2. Virtual Pages - You need to
de-serialize all the data for the
page and create a page with
RichTextBox. Virtual Pages are
nothing but, pre-cached pages that
are going to be rendered. Say for
example. If I'm in 1st page. Then,
I'll de-seriealize next 3
consecutive pages and have them in a
collection. Then, repeat this
procedure for consecutive page
movements. Adding some logic using
Most Frequently Used collection. It
will be fast enough. In the case of
1000's of pages. You can collapse
those non-dirty or never visited
pages. That could yield little more
performance. If performance is far
more concern for low hardwares.
Then, you should consider
cleaning.
3. Cleaning -
Cleaning is the process of
identifying LFU pages and remove
them. This would be very helpful if
performance is more pronounced.
Hi Tameem
Set the min height,width of the richTextBox to A4 size(lets say). Subscribe to RichTextBox Size Changed event.As soon as the content exceeds,this event gets fired.Then I take the last block of previous page and push it to the first block of next page.(Remember if page doesnot exist, you need to create new page then add it as first block).And also the focus should be changed to the new page.(because if you press enter at the last RTB, you expect the focus to be there in the new page.).When the user deletes a block in some page(say 2nd),then you need to add all the blocks of bottom pages to this page,so that our pagination logic will push the blocks down again and adjust. I can share some piece of code if you need further help.
I'm trying to save and restore the position of the document within a FlowDocumentReader to create a bookmark feature. There doesn't appear to be any seeking or search feature build in that is publicly accessible, leaving me with the following options:
Use FlowDocumentPageViewer instead,
saving the page each time the window
is resized and restoring it as soon
as the app is reloaded.
Loop through all the elements in the
Document property of
FlowDocumentReader, looking for the
first one that passes an on-screen
hit test, then using reflection to
use the internal search features to
bring that text back into view at a
later time.
Serialize the entire control.
Write my own document viewer control.
No. 1 is annoying because I'd have to forfeit the two-page and scroll viewing options of FlowDocumentReader. It also means seeking to the saved page before the user has a chance to resize the window. This is fragile and would probably break if the user say, switched resolutions between sessions.
No. 2 is a garish hack that would probably work, but be slow and break completely if the internals ever change.
No. 3 is looking like my best bet, but it only lets me save/restore the current position, not set arbitrary bookmarks.
No. 4 is just too much work. These controls are utterly fantastic, I just need this one feature...
Is there any other way to go about this?
This seems to work well for page views, but not for scroll view, which is okay.
reader is of type FlowDocumentReader, and document is the FlowDocument within it.
Set the bookmark:
var paginator = ((IDocumentPaginatorSource)document).DocumentPaginator as DynamicDocumentPaginator;
var position = paginator.GetPagePosition(paginator.GetPage(reader.PageNumber - 1)) as TextPointer;
bookmark = position.Paragraph;
Restore the bookmark:
bookmark.BringIntoView();