I'm making good progress on creating a generic javascript to build a task list/tree that ultimately be run on a wiki. The challenge is that I would like to have multiple instances of this script running pointing the various subprojects that are layered under different projects in a workspace. Is there a way to pass the context parameters (Parent Project,Project, Iteration, Release etc.) via the Rally.launchapp/bootstrap? That way there is a quick common spot to tune this via the wiki markup. Thanks! Mark
Rally.launchApp('CustomApp', {
name: "RallyGrid",
parentRepos: " "
});
});enter code here
Related
I am trying to write a script that launches an app if not running or activates the window if already visible in the current activity.
Using xdotool or wmctrl I am able to get the list of windows and activate them. If they are not open, then I can launch them. But the problem comes with KDE Activities. These tools list windows from all the activities even if they are not visible in current activity.
I am going through various qdbus methods but not finding anything close.
have anyone created such scripts? how one could get the windows visibility with respect to the activities?
Edits:
as shown in the picture below , I was able to see the activity IDs that the window is attached to. But I am not able to find any way to get it programmatically.
An alternative aproach was given in kde forum. But it is not completely clear if it can help solve your issue.
The recommendation is as follows:
On the activity level you can make use of URI > Activity relations and
query dbus for further scripting. For example:
Link a directory to an activity in dolphin.
Add an application "dolphin-directive" to application launcher and make it run a custom script to conditionally start dolphin instances.
Set "dolphin-directive" as default filemanager
A similar workflow is possible for each filetype via File Association
Settings
As far as I could figure out through experiments it is not possible to link windows to activities and query relations via ActivityManager. I guess the multiple-screen-workspace-uri-activity-window-rule architecture is supposed to setup workflows to solve the problem in a more holistic manner. But hopefully someone can give a better answer here.
I wrote a script to regex inspect the whole session bus tree for related and usefull methods. You can simply use it by ./query-dbus.py --pattern "^.*activit.*$". So the answer is work in progress.
EDIT: some services do have the method isMonitorActivity, isOnActivity
"org.kde.konsole": {
"/Sessions/1": {
"org.kde.konsole.Session": {
"method": [
"setMonitorActivity",
"isMonitorActivity"
]
}
}
}
"org.kde.kate": {
"/MainApplication": {
"org.kde.Kate.Application": {
"method": [
"isOnActivity"
]
}
}
}
}
Did you already file a feature request?
In my application code, there are a lot of calls (like 100+) to the "top object" referring to window.top such as top.$("title") and so forth. Now, I've run into the problem using Cypress to perform end-to-end testing. When trying to log into the application, there are some calls to top.$(...) but the DevTools shows a Uncaught TypeError: top.$ is not a function. This resulted in my team and I discovering that the "top" our application is trying to reach is the Cypress environment itself.
The things I've tried before coming here are:
1) Trying to stub the window.top with the window object referencing our app. This resulted in us being told window.top is a read-only object.
2) Researching if Cypress has some kind of configuration that would smartly redirect calls to top in our code to be the top-most environment within our app. We figured we probably weren't the only ones coming across this issue.
If there were articles, I couldn't find any, so I came to ask if there was a way to do that, or if anyone would know of an alternate solution?
Another solution we considered: Looking into naming window objects so we can reference them by name instead of "window" or "top". If there isn't a way to do what I'm trying to do through Cypress, I think we're willing to do this as a last resort, but hopefully, we don't have to change that, since we're not sure how much of the app it will break upfront.
#Mikkel Not really sure what code I can provide to be useful, but here's the code that causes Cypress to throw the uncaught exception
if (sample_condition) {
top.$('title').text(...).find('content') // Our iframe
} else {
top.$('title').text(page_title)
}
And there are more instances in our code where we access the top object, but they are generally similar. We found out the root cause of the issue is that within Cypress calls to "top" actually interface with Cypress instead of their intended environment which is our app.
This may not be a direct answer to your question, it's just expanding on your request for more information about the technique that I used to pass info from one script to another. I tried to do it within the same script without success - basically because the async nature of .then() stopped it from working.
This snippet is where I read a couple of id's from sessionStorage, and save them to a json file.
//
// At this point the cart is set up, and in sessionStorage
// So we save the details to a fixtures file, which is read
// by another test script (e2e-purchase.js)
//
cy.window().then(window => {
const contents = {
memberId: window.sessionStorage.getItem('memberId'),
cartId: window.sessionStorage.getItem('mycart')
}
cy.writeFile(`tests/cypress/fixtures/cart.json`, contents)
})
In another script, it loads the file as a fixture (fixtures/cart.json) to pull in a couple of id's
cy.fixture(`cart`).then(cart => {
cy.visit(`/${cart.memberId}/${cart.cartId}`)
})
If I download a chat software on word press, it is called a Plugin. In Zend Framework it's called a Module, but there is also plugin's for Controllers.
What's the difference between modules and plugins in Zend?
A module in zf2 is similar to a plugin in wordpress yes! They are a collection of different classes that can be loaded into a project and allow either for reuse of generic code in other projects (this would be using composer in zf2) or modules can simply be used as groupings for similar code in a project.
zf2 is itself modular (I could just load some of the modules in my project, they are designed to work standalone) but lets not do that here
composer.json
{
"name": "myApp",
"require": {
"php": ">=5.3.3",
"zendframework/zendframework": "~2.3.0",
"zf-commons/zfc-twig": "dev-1.2rc1"
},
"autoload": {
"psr-0": {
"Application": "module/Application/src/"
}
}
}
providing composer is installed I can just run:
composer update
from the command line. If you haven't had much experience with composer, the docs ain't bad https://getcomposer.org/doc/ but it is a must have for zf2 development!
Then in the root of your app you can then add to config.application.config.php your modules
return array(
'modules' => array(
'zfTwig',
'MyCustomModule',
),
}
Now these modules are available in your project. For more information see
http://www.michaelgallego.fr/blog/2013/01/21/some-tips-to-write-better-zend-framework-2-modules/
and
http://mwop.net/blog/267-Getting-started-writing-ZF2-modules.html
You can also add modules yourself at the application level (as I said previously these are more for grouping features or whatever you fancy together).
You can use this to help build your personal modules
https://github.com/zendframework/ZendSkeletonModule
Just place the ZendSkeletonModule in the module folder of your zf2 app and update all the namespaces and the root folder of the module to match. In the case of the application.config.php I have above you would rename it all "MyCustomModule".
A controller plugin is something quite different, they are just a class which is registered to be injected into a controller basically
They can be called in your controllers to perform certain tasks.
The FlashMessenger plugin for example allows you to register a message in the flash messenger within your controller that will be displayed on the next page load.
From the zf2 docs
$this->flashMessenger()->addMessage('You are now logged in.');
return $this->redirect()->toRoute('user-success');
see http://framework.zend.com/manual/2.0/en/modules/zend.mvc.plugins.html for more detail
Modules
A module is a self contained collection of code that provides similar functionality within an application.
This means modules can be anything you desire them to be (one file or your whole application!).
'Modules' are not new terminology in ZF2; "Modular Programming" has been around for a long time. By having logical groups of code functionality it will promote code reuse and the 'open close principle'.
Modules in ZF2
Modules are first class citizens within Zend Framework 2; this means that the framework was designed specifically for the purpose of being able to add and remove modules with ease.
There are many examples of ZF2 modules online - Most of which would require minor configuration changes and you can begin using them (code reuse!)
Plugins
Again a generic term that will have different meanings in different frameworks. You may have heard of 'pluggable software', this answer summaries it nicely.
[A design for when] you want a system to work in straightforward and predictable ways, with very specific points of variation.
The 'points of variation' are areas of your code that are likely to require changes or different logic. A system that allows for external sources to be injected without the base code being modified is thought to be 'plugable'.
Plugins in ZF2
A 'Plugin' in ZF2 is actually known as a 'Controller plugin'
They are classes designed to add functionality to Controllers (any class extending Zend\Mvc\Controller\AbstractActionController), without the need to extend the controller class.
Some examples of this are the Zend\Mvc\Controller\Plugin\FlashMessenger which allows you to add a message to session and display it on the reloaded page. This can be reused in all your controllers without needing to modify them.
I'm creating a workflow app with pyramid and i'm searching how to make the application modulable : meaning create a core app with sqlalchemy models, base forms with wtforms, and some base templates with mako.
The basic structure of the "Core" app is:
App_Core/core.ini
/setup.py
/...
/App_Core/
/__init__.py
/models.py
/forms.py
/utils.py
/templates/
/templates/base.mako...
/static/
/static/staticfiles...
My goal is to create 1 application per workflow which will be included in the Core app : it seems possible to do that via the includeme function provided with pyramid.
I want to include each workflow via the core.ini file, for example:
pyramid.includes =
workflow_app1
workflow_app2
workflow_app3
...
I defined an new app called workflow_app1 with the following structure:
worflow_app1/
/setup.py
/...
/workflow_app1/
/__init__.py
/models.py
/forms.py
/views.py
/templates/
/templates/workflow_app1.mako
/...
And the _init_.py file will contain the includeme function and will define new routes:
def includeme(config):
config.add_route('route1', '/route1/')
config.add_route('route2', '/route2/')
config.scan()
When i'm writing a view for the worflow_app1, i'm rendering to a template included with that app, but when i'm calling it from the core app, it can't render the template and gives the following error:
TopLevelLookupException: Cant locate template for uri 'workflow-app1.mako'
This error quite logical cause the mako.directories directive is given with the path App_Core_PATH/templates so my template should be in the same folder.
Question1:
Is it possible to make mako searching in each folder of modules the wanted templates?
Question2:
Is it possible to make the workflow-app1.mako inheriting of the base.mako from the core app?
Thanks by advance for your answer.
The solution that I would recommend is switching to asset specs for your templates. They are explicit, allow overriding, and provide better control over your template hierarchy. This means that you would stop using mako.directories and instead use 'workflow_app1:templates/workflow_app1.mako' in your inherits or include or renderer arguments. Given this, it's obvious that you can inherit from your base.mako in your core app, whereas managing the mako.directories option is more difficult.
If you're deadset on mako.directories then you can add a line to it every time you add a package to pyramid.includes.
mako.directores =
App_Core:templates
workflow_app1:templates
workflow_app2:templates
Another option is to switch to jinja2, as its plugin has the ability to add search paths after the fact. Thus your included modules can config.add_jinja2_search_path(...) throwing themselves into the lookup order. Pyramid's mako integration does not offer this option right now.
Does anybody know what if direct update updates everything that lives in the common directory structure. I used the same code base for multiple apps, the only change being certain settings within a js file that tells the application how to act. Is there a directory i can put that js file that would be safe from the direct update feature?
I cant seen to find any specific information on IBM's website.
I think you guys need to be careful which terms you are using in order to not confuse people who may be looking for similar help.
Environments are specific to the OS you are using. iOS, Blackberry, Android, and etc. environments.
Skins are based on the environment, and aren't generic to all platform. When you create a skin you must choose which environment you are running in.
So to correct some, direct updates will update all skin resources in targeted environments.
For example: You have an app with Android and iOS versions
When you create skins, you are creating essentially a responsive type of design to your parameters. For instance, if you have a 2.3 vs 4.2 Android OS, you can set a look and feel for both. However, these utilize a single web resource base. The APK would be the same for both versions of the app (by default) and have 2 available skins. On runtime utilizing IBM Worklight's 'Runtime Skinning' (hence the name) it goes through the parameter check for the OS and loads that skins overriding web code.
You could technically override all of the web code to be completely different for both skins, but that would be bulky and inefficient.
When you direct update you are updating all the resources of that particular environment (to include both skins), not the common folder/environment.
So an updated Android (both skins) would have updated web resources (if you deployed the android wlapp) and an iOS version would stay the same.
If you look at the Android project after build (native -> assets -> www -> default or skin) you can find the shared web resources generated by the common environment. However that is only put there every time you do a new build.
In the picture, I have an older version of the Android built for both skins on the left. On the right is a preview of the newer common resources after deploying only the common.wlapp. So you can see that they are separate.
Sorry if it was long winded, but I thought I would be thorough.
To answer the original question, have you thought of having all the parameters of the store loaded from user input or a setup? If you are trying to connect to 3 different store, create some form for settings control that will access different back ends or specific adapters. You could also create 3 different config.js that load depending on the parameters that you set so that you set. The other option is to set different versions of your apps specific to the store.
Example. Version 1.11, 1.12,1.13 can be 3 versions of the same app for store 1, 2, & 3. They can be modified and change and have 3 sets of web resources. When you need to update, jump up to version 1.21, 1.22,1.23. It seems a bit of a work around, but it may be your best bet at getting 3 versions of the same app to fall within the single application category. (keep 3 config.js types for modifying for the 3 stores).
To the best of my knowledge Direct Update will update every web resource of the skin you're using (html, css, js). However, I'm no expert with it.
If you're supporting only Android and iOS applications and need a way to store settings I recommend JSONStore. Otherwise look into Cordova Storage, Local Storage or IndexedDB.
Using a JSONStore collection called settings will allow you to store data on disk inside the app's directory. It will persist until you call one of the removal methods like destroy or until the application is uninstalled. There are also ways of linking collections to Worklight Adapters to pull/push data from/to a server. The links below will provide further details.
the only change being certain settings within a js
Create a collection for your settings:
var options = {};
options.onSuccess = function () {
//... what to do after init finished
};
options.onFailure = function () {
//... what to do if init fails
}
var settings = WL.JSONStore.initCollection('settings',
{background: 'string', itemsPerPage: 'number'}, options);
You can add new settings after initCollection onSuccess has been called:
settings.add({background: 'red', itemsPerPage: 20}, options);
You can find settings stored after initCollection onSuccess has been called:
settings.findAll({onSuccess: function (results) {
console.log(JSON.stringify(results));
}});
You can read more about JSONStore in the Getting Started Modules. See Modules: 7.9, 7.10, 7.11, 7.12. There is further information inside the API Documentation in IBM InfoCenter. The methods described above are: initCollection, add and findAll.
Since version 5.0.3 I think, direct update will not update all the webresources, only those of the skin you are using.
say you have skin def and skin skin2
you are on def
make change to def on the server -> you will get a direct update for
def only
make change to skin2 on server-> no direct update for you.
you are on skin2:
make change to skin2 on server -> direct update for skin2 only
make change to def javascript which also resides on skin2 ( and therefor end result is def+skin2 concatination), update only skin2
make change to def,just to a picture(also checking pic extension from application-descriptor: ") -> no direct update
Thats how direct update works.
Please also share some more details about what is the problem, I see you use a js file, where do you change it? what do you mean excatly, give a better (simplified) real life example, because it is unclear what you are trying.