My case is the following:
a. I've got some GWT library: extGWT or SmartGWT, for instance;
b. I've got a tree with lazy loading;
c. On expansion I load node children;
d. I've got millions of children nodes so I don't want them to load at one go on node expansion.
I would like to know if it's possible to use lazy loading not only on node expansion but also on tree scroll, for instance.
I'm considering the use of extGWT / smartGWT for my project (never worked with them actually), so don't know if my question is kind of obvious. But I wasn't able to find the answer myself yet.
Thank you in advance
There is a topic http://forums.smartclient.com/showthread.php?t=16946 on the smartclient forum about pagination of smartGWT treegrids that isn't old. As I understand, pagination is not implemented for treegrids as "it's just not a very good UI".
I'm not an expert in smartGWT treegrids but I think you can use "lazy loading" on node expansion with the datasource, but not on tree scroll.
As for extGWT, I really don't know. Hope it can help you a little bit.
Related
Goal: View multiple scopes(file tree) at once.
I'm modifying a little old web node application, the view folder and logic handling are written in different places, but I need to see each other.
So, I would like to have multiple file trees in the same project for easy navigation.
However, since the folders are so far apart from each other, I set up a scope and try to switch between them each time.
Sorry, my English is not very good, so I use a little translation. I'm attaching a picture just in case.
Thank you.
I was able to find a few solutions.
It is the Favorites window.
Maybe the scope is not available, but I was able to increase the number of project views to two.
I can't open more than three of them, so if there is a convenient way to do this, please let me know.
Thank you.
screenshot
I find, even when assigning the decorator #singleton(false) to the view-model, that while the view-model does then persist as a singleton across activation/deactivation, the bindings and components, etc do not.
(I assume this is because they are stored in a container that is disposed on deactivation.)
The result is that upon every deactivation/activation of a view with a singleton view-model, the view is un-bound and then re-bound.
Is it possible to cause the bindings to persist across deactivation/activation?
This one stumped me for a good while. It also confused me as to why implementing it was not a higher priority for the Aurelia Team.
This takes a fair amount of code to get working. I have put the code in a Gist here: https://gist.github.com/Vaccano/1e862b9318f4f0a9a8e1176ff4fb727e
All the files are new ones except the last, which is a modification to your main.ts file. Also, all my code is in Typescript. If you are using Javascript you will have to translate it.
The basic idea behind it is that you cache the view and the view model. And your replace the router with a caching router. So when the user navigates back to your page, it checks first to see if there is a view/view model already created and uses that instead of making a new one.
NOTE: This is not "component" level code. That means I have tested that this works for the scenario that I use it for.
I got my start for making this change here: https://github.com/aurelia/router/issues/173 There is another user (Scapal) made something that works for him and posted it there. If what I am posting does not work for you, his may help you out.
i'm also interested in an answer to this.
maybe i'm now making a complete fool out of me but why not use aurelia-history navigate(..) command?
I wanted to implement a walkthrough tutorial but to do that I realised I needed to be able to select HTML elements from a property value (eg. name or id), ie get the value of a property from an HTML node. I think there currentlyis no way of getting an element's name in elm: could anybody please confirm? Does that mean I need to add something to virtual-dom package?
No, there is no way to really read a tree of Virtual DOM in Elm. If you look at the source for VirtualDom.elm, you'll see that nearly every function is implemented in native JavaScript, in the Native/VirtualDom.js file.
Sure, you could write some kind of native API to cheat the system and inspect the html like you're talking about, but the Virtual DOM was never meant to be used or queried in that way. The model with which you build your view should be the source of truth. Perhaps if you tweaked your design a bit, you would find that you don't really need this requirement after all.
I want to evaluate my content blocks before running my test suite but the closures' property names is in bytecode already. I'm ooking for the cleanest solution (compared with parsing source manually).
Already tried solution outlined in this post (and I'd still wind up doing some RegEx/parsing) but could only get it to work via script execution engine. It failed in IDE and GroovyConsole. Rather than embedding a Groovy script in project's code, I thought I'd try using Geb's native classes.
Is building on the suggestion about extending Geb Navigators here viable for Geb's PageContentSupport class whose contentTemplates contain a LinkedHashMap of exactly what I need? If yes, would someone provide guidance? If no, any suggestions?
It is currently not possible to get hold of all content elements for a given page/module. Feel free to create an issue for this in Geb's bug tracker, but remember that all that Geb can provide is either a list of content element names or a map from these names to closures that create these elements.
Having that information isn't a generic solution to your problem because it's possible for content elements to take parameters and there are situations where your content elements will be available on the page only after some other actions are performed (for example you have to click on button to reveal a section of a page that uses ajax to retrieve it's content). So I'm afraid that simply going over all elements and checking if they don't throw any errors will not cut it.
I'm still struggling to see what would "evaluating" all content elements prior to running the suite buy you. Are you after verifying that your content elements still work to get a faster feedback than running the whole suite? I'm pretty sure that you won't be able to fully automate detection of content definitions that don't work anymore. In my view it will be more effort than it's worth.
I would like to gain a full understanding of how events work in Dojo. I am actually interested in the way Dojo 2.0 works -- I am using 1.8 now, but I am only really interested in using/documenting features that will not be deprecated for 2.0.
Now... in _WidgetBase.js I read:
on: function(/*String|Function*/ type, /*Function*/ func){
// For backwards compatibility, if there's an onType() method in the widget then connect to that.
// Remove in 2.0.
This basically means that in the near future a widget's on will basically do:
on: function(/*String|Function*/ type, /*Function*/ func){
// Otherwise, just listen for the event on this.domNode.
return this.own(on(this.domNode, type, func))[0];
Which is fine. Now... in the release note for 1.8, I see:
"Widget events, including attribute changes, are emitted as events on the DOM tree"
The release note point to this: http://livedocs.dojotoolkit.org/quickstart/events#widget-events-published-to-the-dom Which "sort of" explain things, although the document seems to be outdated (it still talks about aspect for "plain object").
So, my question: is there a spot/bunch of pages/tickets that would describe the current updated way in which the whole events thing works?
My current understanding (for Dojo 2.0):
on: 100% delegated to on.js
emit: when you run randomWidget.on('something', function(){}):
-if randomWidget has 'onsomething', it will simply run that; <--- will this go away with 2.0?
-Otherwise, it will delegate to on()
So, it's all about understanding dojo/on. That's when I get confused: reading the source code, on.js seems to delegate functionality to the widget itself (which... I just wrote above, will simply delegate to dojo/on from 2.0...?!?). Unless the bit that delegates to the object is destined to disappear...?
Also, I am used to writing widgets with templates, and then add items where I do data-dojo-attach-event="onclick:_click" where I make sure a function is called when somebody clicks on it. With the new on() system, will this change? (I mean, is all events propagates to DOM, is the opposite also true?)
So, can somebody shed some light on this? I feel a little uneasy at the moment, adding events and doing things, because I am not 100% sure of what is going on.
Thank you!
Gosh that was a while ago...
Since then, I wrote this:
https://github.com/mercmobily/writeups/blob/master/dojo/widgets_containers_on.md
Which explains pretty much the whole lot!
Merc.