Does anyone have any suggestions for the best / simplest way to view all stories owned by a specific user (or specific users) inside a Rally workspace?
I gather there may be ways to do this (e.g. through a Custom Grid) if there were single "parent" projects at the top of each workspace, but I'm looking for something similar without having to make "dummy" uber-parent projects.
Thanks!
You won't be able to do it on a custom grid since you will be bound by the global project scope or a specific scope of your choosing in the settings panel. This should be relatively straightforward to write as an app though (which could then be run in a custom panel on the dashboard or in a custom tab).
The App SDK's RallyDataSource allows querying the entire workspace like so:
var rallyDataSource = new rally.sdk.data.RallyDataSource("__WORKSPACE_OID__",
"__PROJECT_OID__",
"__PROJECT_SCOPING_UP__",
"__PROJECT_SCOPING_DOWN__");
rallyDataSource.findAll({
'type' : 'hierarchicalrequirement',
'key' : 'myStories',
'fetch': 'FormattedID,Name',
'query': '(Owner = /user/__USER_OID__)', //Find items owned by me
'order': 'FormattedID',
'project': null //Query the entire workspace
},
onStoriesRetrieved); //Callback when data is available
It should then be straightforward to display those stories in a Table.
Related
I've been following the guide here where it gives an example of an editor using a ViewModel.
I'm looking to change this so that instead of a single editor that is rebound to each domain object for editing, instead each object will bring up its own separate editor.
I want to keep using the ViewModels as I like the separation they provide and the API they have (easy rollback / saving).
How should I handle opening an editor per domain object (especially in a TornadoFX way)?
The solution is to create a new scope for the new editor and inserting the relevant models into that new scope. If you're using the Workspace, this is done using built in functions like dockInNewScope:
workspace.dockInNewScope<MyEditor>(myModel1, myModel2, etc)
If you're not using Workspace, you can create a new scope manually, put models into it and lookup views in the new scope as well:
val newScope = Scope(myModel1, myModel2)
find<MyEditor>(newScope).openWindow()
MyEditor will in this instance see myModel and myModel2 in it's scope, so that it can inject them.
is there a way to save the columnsettings of a SAPUI5-Table?
if the user logout and relog again the table properties should be saved.
what i have to do is to save the column settings which can be manipulated by user interaction.
Property: showColumnVisibilityMenu:true
i'm using sap.ui.table.Table
var oTable = new sap.ui.table.Table({
title: "Table Example",
selectionMode: sap.ui.table.SelectionMode.Single,
showColumnVisibilityMenu:true, // those settings should be saved
});
actually i've found an example here to preview the selection of the columns (hide or show):
http://jsbin.com/ceduc/1/edit?html,js,output
So when the user decides to hide the column "Key1 Label" (figure below) and want to logout and relog again, the column shouldn't be visible. the configuration of the table columns should be saved for a user. how to do that?
It depends on how exactly do you want to persist the view settings and on what backend you have.
If you have an ABAP backend which has the unified shell services (delivered as part of Fiori), then you can use the standard Personalization controller / services to persist the settings. See this demo, the UI5 documentation and the unified shell service docu.
If you have any other type of backend or you don't want to use the personalization services, then you should save the visibility of the columns inside a (dedicated) model. Then you can save the content of this model on your backend (by simply sending it to a dedicated REST service and persisting it e.g. in the database). When the user logs back in, you can read this model and simply restore it.
Another possibility would be to save it in the local storage of the browser. You still need the model from above, but instead of sending the data to the backend via AJAX, you simply save it to the local storage and load it from there when needed.
You can make use of SAP's standard Shell personalization Service.
Here is how I would do it.
Use Personalization Dialog (sap.m.P13nDialog) for managing Table's options
Get standard personalization service provider
var oProvider = sap.ushell.Container.getService("Personalization").getPersonalizer(oPersId);
Connect your table with personalization provider and activate
var oTablePersoController = new sap.m.TablePersoController({
table: oTable,
persoService: oProvider }).activate();
This will automatically take care of saving and retrieving variants/personalization.
Launch the Personalization Dialog upon user cliking the corresponding button
You may use sap.ui.table.TablePersoController for sap.ui.table.Table
It is possible to define pagination on document library?
I have a document library with more that 10000 documents... when I open the library occurs an timeout.
Actually SenseNet already does this! They just don't deliver it in the standard list control. If you open up the PRC and navigate to /Root/IMS/BuiltIn/Portal you'll see a list control with paging. The code can be found at /Root/Global/renderers/UserExploreGrid.ascx as User Control portlet. You can copy the code and change it to meet your needs.
Our company prefers to create User Control portlets and use Datatables with calls to the SenseNet OData API using skip and top to deliver pages.
Finally, given that SenseNet Content is stored as a tree structure (in SQL!), you can move the Content after creation so that data is organized hierarchically. A common solution is to take the first letter of the DisplayName and create a sub-folder from that letter, thereby reducing the number of items at a single node.
Here's what the paging looks like:
The short answer is no. Right now there isn't a built in functionality for that.
The long answer is that you can make a pagination yourself. One of the core member of sensenet made a grid where you can use pagination. It won't work with the current free to use releases because they lack the js files she used. But the idea behind it, is using a custom view. Which you can achieve by adding a system folder named Views under a the Document library and adding your custom view there.
You can use this grid for Explore, just follow these steps:
Go to the Explore action page, and switch editor mode on the PRC.
Place a ClientContext portlet (this can find under the Portlets->Application section in the portlet picker dialog) to the Wide column. Set portlet (client context porlet) properties, Apparance to None. It is a technical portlet, which allow get the CurrentContext in javascript. This is a very important element to work with this grid. The Grid use the client context.
Place a UserControlPortlet (In the portlet picker, Portlets->Application section) to the Wide Column.
Set portlet properties:
4.1. Portlet title: <%$ Resources: PortletTitles, Items%>
4.2. User Control path: /Root/Global/renderers/UserExploreGrid.ascx
Checkin Page modification on the PRC.
Enjoy your pageable explore portlet.
Keep in mind that this grid is specifically designed for users, so they will miss actions in the top menu. These must be handwritten. Then I suggest you copy the UserControl ( /Root/Global/renderers/UserExploreGrid.ascx)
and then put the action list on it . You can read more info about action list here: http://wiki.sensenet.com/ActionList
Br,
maros
New to Backbone and wondering if any Backbone experts can lend their advice as to how to structure the following application:
Users log in to view the Dashboard. The Dashboard has 6 Panes and the Content of each Pane is determined by each User's Preference List (a Backbone Model with attributes panelone: contentA, paneltwo: contentD, etc...)
Above the Panes is a horizontal list of Content types. The User should be able to drag and drop the Content type over a Pane to save it and render the Content in that Pane immediately.
For example, if ContentF dropped on Pane3 then Pane3 saves ContentF ( Model.set('Pane3: ContentF' ) and updates itself with ContentF's template.
Specifically, How do I divide up this functionality between Router, Views and Templates?
Thanks,
AC
I can't consider myself a Backbone expert, anyway that's my two cents.
I suggest you to use Marionette, a framework built on top of Backbone that ease the things a lot.
You could setup your dashboard view as a layout, and each panel as a region of that.
This way you could update each panel's content without affecting the others and have all the events and stuff attached to your old view be cleaned up by Marionette's build-in memory management.
Also I don't think your router should be too affected by a change in panels content, it should just render the view assigned to that specific content, so it just has to be able to access the list model. Each of this views will have their specific template and that's all!
I have encountered a problem with the MVC pattern in ExtJS 4. At least, I think I have. Having approached multiple people with this question, and having posted numerous times in the Sencha forums, I am now turning to a broader audience in hopes of getting either a light bulb or a confirmation.
Problem
Your application has the ability to open many different views, some of which themselves are mini-applications. Additionally, a user may wish to have multiple concurrent copies of a view open.
This application is a single-page client-side Javascript application.
The ExtJS 4 MVC model expects you to define all of your controllers in your Application class. These controllers are then initialized when the Application loads. Controllers keep track of views, models and stores.
When you initialize controller A multiple times, say to create more than one copy of a view, you end up with two views that reference the same data stores, and functionally send duplicate events to the Application event bus.
I have refactored my application by adding new prototype methods to Component and Controller to allow for both a) sub controllers (some of my controllers were getting pretty huge) and b) defining stores specifically for the view they work with. The models can still be defined on the controller, just for ease of use by handlers if you need to do something like grab a record from the server.
Question
My understanding of MVC would lead me to believe that models more directly relate to the View than then Controller. I asssssume that ExtJS 4 decides to attach stores (which I think can be seen as wrappers to a more classic model) to Controllers for purposes of encouraging re-use of loaded data, and to optimize away from having many copies of the same class instantiated. It seems to me, however, that one cannot do this if one intends to have many instances of a view available to the user. To my thinking, having many instances is an important option in an OO framework, hence why I have bucked the trend and implemented prototypes on some of the Ext base classes. (Thank you Ext.implement!).
Is there any way to have multiple concurrent instances of a view with different data loaded into them using the out of the box MVC classes and making uses of the provided setters, getters, etc?
I was faced with a similar problem:
Consider a tabpanel for a CRM type application which opens new instances of a view for each client. And say that tab view contains 3 or 4 row-editing gridpanels for interacting with different collections of data relating to that client.
The solution I came up with was based on this from the Sencha forums. In a nut shell, almost all events that are dispatched from a view contain a reference to the view itself. The handlers in my controller's control function all use these to get a reference to the correct view instance.
For dealing with the multiple instances of the same store needed for this, I took this to heart from that post:
For the Store instance on the view or a global one... depends on the
needs. If you are going to use globally then make it global. If you
only are going to need it on the view then put it on the view. MVC is
not a law, you can change it to fit your needs. Technically the
Controller part of MVC is suppose to be the middle man between the
View and Model parts but sometimes that's just not needed. I create
the Store in the view 95% of the time. I'll give you an example...
If you have a Store for products, you probably only need to reference
that Store in your Grid. That usually isn't needed for other parts of
the application. However, if you have a Store to load countries, I
often need it globally so I only have to load it once and can then
set/use that Store in several views.
So I just created the needed store's that relate to a view instance specifically, inside the view's initComponent method. The application did have a few global stores that I created as store classes following the MVC recommendations. It worked out nicely to encapsulate the view instance stores inside the view. Then I only needed one instance of the controller.
To answer your question specifically, currently, there is no ExtJS official recommendation or config for dealing with multiple instances of the same view that use the same store constructor. I have spent some time looking for something like that and the best I have found was this recommendation from one of their forum moderators.
I don't think you ever need more than 1 instance of a controller, regardless of how many views/models you have. See functional example here:
http://whatisextjs.com/extjs-4-extension/fieldset-w-dynamic-controls-7
This can be done, reasonably easily. You need to follow a few rules:
load your controllers at app startup. Don't unload them. Don't worry about the memory or time, it's pretty small even for hundreds of controllers, as long as you minimize and concatenate your js.
Never use the refs or views properties of a controller. You are going to use one instance of a controller, but multiple instances of views, so you never want a reference to a view.
only use event listeners in controllers. You are only going to listen to events on your views. You can always get a (temporary) reference to a view in the event handler via the "cmp" parameter in the handler.
To "launch" a view, create it and add it to another view. To destroy it, destroy it. You don't use a controller to launch a view. You can use the afterrender and beforedestroy events in the controller to add logic.
In ExtJS' MVC the controller is a Singleton for you view. I like how DeftJS thinks about MVC. Each instance of a view has an own instance of a controller. In this way you can put all "controlling rules" in a controller for a particular part of your view, and this will be instantiated only when the view opens.
I did not have any experience how I could use multiple Defts JS apps in the same project.
Of course. What led you to believe otherwise?
Here is an example of creating a custom View which extends from a Window component. You can run this method many times from the same controller and each time you will get a new instance of a View.
"this" refers to a controller that code runs in:
this.getRequestModel().load(requestID,{ //load from server (async)
success: function(record, operation) {
var view = Ext.widget('requestEdit',{
title: 'MyRequest '+requestID
});
var form = view.down('form');
form.loadRecord(record);
}
});
How do you create your views? I see no reason why you cannot pass a different store or config data to every object. Some code samples would help for what exactly you are doing. For example, we have a similar sounding application, and everything is done with extensions. So, if we need a grid, we run
Ext.define('MyApp.grids.something',{
extends:'Ext.grid.panel'
//...
These classes are predefined. Then, when a controller or view is loading this grid, they are using
var grid=Ext.create('MyApp.grids.something',{id:'unique',store:mystore});
As you can see, we can pass in different config options to the same grid each time it is created. We can treat this exactly as you would treat
Ext.create('Ext.grid.Panel');
Except of course that we make some options predefined, and some non-override-able, and so on.
Hope this helped.
Check out this post. The idea there is to take some configuration (like store and itemId) from view config and put it into the viewport config:
// .../app/view/Viewport.js
Ext.define('MyApp.view.Viewport', {
// ...
items: [
// ...
{ xtype: 'testview', store: 'Store1', itemId: 'instance1' },
{ xtype: 'testview', store: 'Store2', itemId: 'instance2' }
]
});
The problem with store will be solved, obviously. Different itemIds will enable you to handle events properly.