Using Apex version 4.1.1.00.23.
When saving a report and choosing Actions, Save Report, the resulting window has a "Public" check box to make the report Public. Is it possible to have the Public check box already checked ( resulting in Public being the default option)?
I read that it is not possible to have the option to only have Public reports without also having Private reports. Is this true?
Thanks!
It is not possible to have public reports without the private ones simply because of the way saving is set up. If you were to influence that, then yes, it would be possible.
You can not easily influence the 'Public' checkbox. The reason for this is that the html-region which pops up when you select an option from the actions list (such as 'save' in this case) is retrieved through an ajax call. This way it is not even possible to use some javascript/jquery to influence this as the item is not there as long as the option has not been selected.
If you really want to influence it anyway, there is one option only: study the ajax calls and reproduce them. For example, i've been doing this for filters. You will need to look through the ir javascript file, found in /i/javascript/apex_interactive_reports_4_1.js
Firstly, you need need a hook for the successful callback for the IR ajax. There are however no framework events. What i did is 'override' gReport._Finished_Loading: checking the executed action, trigger the original code, then hook in my own functions.
Once there, you could influence what happens: hide the checkbox, always check it, add items or change some. For example, with always checking the checkbox and hiding it you'd always generate public reports.
You could also study the save report ajax call, and mimic this behaviour, using your own small interface for providing parameters.
Related
I'm working in HCL Notes application. I have developed a summary view to show calculated figures to the user. Then the user clicks one of the action buttons and I open a detailed view, but for that view I setup Selection Formula on the fly so that it shows the records filtered specific to that button conditions. It was working almost fine for a few days, but now most of the time it shows some previously shown (filtered) data no matter what button the user has clicked. Means it doesn't set the Selection Formula of the view and shows the view with the old formula and it won't get back to normal condition even if they restart Notes application.
When the user is stuck in this particular condition, and they peep through the status bar it shows this message:
Document has been modified or corrupted since signed! (data).
The necessary code-snippet is as below:
*Set dtlView = db.GetView("Report_Dtl")
dtlView.SelectionFormula =formula
Call dtlView.Refresh()*
where formula is the dynamically built formula. Looks like the line
dtlView.SelectionFormula =formula
is unable to update the selection formula and then the line below generates the above error message:
Call uidb.OpenView(dtlView.Name,,False, False)
Please help!
Thanks
For "on the fly" modification of the view selection formula your user need "Designer"- access to the database, and that is never a good idea. The help document to the function you are using is explicitly stating that this is not a good idea (emphasise of mine):
This is not a good way to display a selected set of documents for a specific user. When you use this property to change the view selection, it applies to all users of the view.
There are problems with using this method to make a view display a new selection of documents for an end user:
Do not give end-users Designer access to an application.
If it is a shared view, users will interfere with each other's searches.
The Notes® client caches design information, and there's no way to tell it to update its cache (except for outlines). Exiting and re-entering the application usually works, but it's hard to programmatically ensure the user exited the application entirely.
In addition the modification of the view selection formula can break the signature of the design element and then other errors occur.
Better use another approach:
Use a Folder for every user and put the selected documents in there (after doing a NotesDatabase.Search with the formula
Use a separate view for every user and let a server agent manipulate its selection formula with a user that has access.
For having a separate view / folder for every user you could use "Shared, Private on first use"- views (they are not easy to maintain), or any process that generates them and is able to assign every view to the users they belong to... in both cases this needs some effort, but at least it will work.
I am trying to build a UI with left side bar having filters and right side having actual filtered data.
For loading data into the dynamic part of the UI(right side), which approach is considered better in terms of code quality and app performance ?
Use sub routes (for dynamic part of the UI)
Use separate components that load their own data (for dynamic part of
the UI)
There is not a direct correct answer for that; you can use both ways but here is a few things to consider and in the end I generally prefer to use sub-routes due to the following:
Waiting for UI to load: In case you are using separate components to load their own data; then you need to handle the loading state of the components. What I mean is; if you simply use sub-routes; then model hooks (model, beforeModel, etc.) will wait for the promises to be solved before displaying the data. If you simply provide a loading template (see the guide for details) it will be displayed by default. In case you use components, you might need to deal with displaying an overlay/spinner to give a better UX.
Error Handling: Similarly like loading state management; Ember has already built in support for error handling during route hook methods. You will need to deal with that on your own if you prefer components to make the remote calls. (See guide for details)
Application State: Ember is SPA framework; it is common practice to synchronize application state with the URL. If you use sub-routes; you can simply make use of the query parameters (see the guide for details) and you will be able to share the URL with others and the application will load with the same state. It is a little bit trickier to do the same with components; you still need to use query parameters within the routes and pass the parameters to the components to do that.
Use of component hook methods: If you intend to use the components then you will most likely need to use component hook methods to open the application with default filter values. This means you will need to make some remote call to the server within one or more of init, willRender, didReceiveAttrs component hook methods. I personally do not like remote calling within those methods; because I feel like this should better be done within routes and data should be passed to the components; but this is my personal taste of coding that you should approach the case differently and this is perfectly fine.
Data down, actions up keeps components flexible
In your specific example, I'll propose a third option: separate components that emit actions, have their data loaded by the route's controller, and never manipulate their passed parameters directly in alignment with DDAU.
I would have one component, search-filter searchParams=searchParams onFilterChange=(action 'filterChanged'), for the search filter and another component that is search-results data=searchResults to display the data.
Let's look at the search filter first. Using actions provides you with maximum flexibility since the search filter simply emits some sort of search object on change. Your controller action would look like:
actions: {
filterChanged(searchParams){
this.set('searchParams', searchParams);
//make the search and then update `searchResults`
}
}
which means your search-filter component would aggregate all of the search filter fields into a single search object that's used as the lone parameter of the onFilterChange.
You may think now, "well, why not just do the searching from within the component?" You can, but doing so in a DRY way would mean that on load, you first pass params to the component, a default search is made on didInsertElement which emits a result in an action, which updates the searchResults value. I find this control flow to not be the most obvious. Furthermore, you'd probably need to emit an onSearchError callback, and then potentially other actions / helper options if the act of searching / what search filter params can be applied together ever becomes conditionally dependent on the page in the app.
A component that takes in a search object and emits an action every time a search filter field changes is dead simple to reason about. Since the searchParams are one-way bound, any route that uses this component in it's template can control whether a field field updates (by optionally preventing the updating of searchParams in an invalid case) or whether the search ever fires based of validation rules that may differ between routes. Plus, theres no mocking of dependencies during unit testing.
Think twice before using subroutes
For the subroutes part of your question, I've found deeply nested routes to almost always be an antipattern. By deeply, I mean beyond app->first-child->second child where the first child is a sort of menu like structure that controls the changing between the different displays at the second child level by simple {{link-to}} helpers. If I have to share state between parents and children, I create a first-child-routes-shared-state service rather than doing the modelFor or controllerFor song and dance.
You must also consider when debating using children route vs handlebars {{if}} {{else}} sections whether the back button behavior should return to the previous step or return to the route before you entered the whole section. In a Wire transfer wizard that goes from create -> review -> complete, should I really be able to press the back button from complete to review after already having made the payment?
In the searchFilter + displayData case, they're always in the same route for me. If the search values need to be persistent on URL refresh, I opt for query params.
Lastly, note well that just because /users/:id/profile implies nesting, you can also just use this.route('user-profile', { 'path' : 'users/:id/profile' }) and avoid the nesting altogether.
Our Application has components which consume components with consume components of varying complexity. So i just want the input on the page, to validate when an object is set that the text is correct. The issue is that it is one of these subcomponents.
My colleague told me that there is 2 ways to do this, The first is to use Page Objects, and Chaining annotation to find it on my page, and then find the next id etc until my input is found. It requires me to look through another teams' Component Markup to narrow it down to the input i want to leverage. I dont believe I should have to go into another component definition, or a definition of a definition to get the appropriate chain to get this arbitrary input. It starts to create issues where if a lateral team creates changes unbeknownst to me, my PO will be broken.
The other option my friend asked was to use fixture.query to find the component. This would be as simple as:
fixture.query((el)=> el.attribute["id"] == "description",
(comp){
expect(comp.value, value);
});`
Using Query looks at the markup but then will automatically componentize it as the appropriate SubComponent. In this case, comp.value is the value stored in the HTML. So, if i did something like:
fixture.update((MainComponent comp) {
comp.myinput.value = new Foo();
});
Then I am setting and getting this programmatically, so i am a bit unsure if it properly would reflect what is on the screen.
Whats the best course of action? It seems PO would be better, but im not sure if there is a way around having to deep query for input boxes outside of the component i am testing.
Thanks
I don't think I have a definitive answer for you but I can tell you how we do it at Google. For pretty much any component we provide the page object alongside the component. This is twofold it is for testing that widget, and also so we can have this as a shareable resource for other tests.
For leaf widgets the page objects are a little less fleshed out and are really just there for the local test. For components that are shared heavily the page object is a bit more flushed out for reusability. Without this much of the API for the widget (html, css, etc) we would need to consider public and changes to them would be very hard (person responsible for making the public breaking change needs to fix all associated code.) With it we can have a contract to only support the page object API and html structure changes are not considered breaking changes. At times we have even gone so far as to have two page objects for a widget. One for the local test, and one to share. Sometimes the API you want to expose for a local test is much more than you want people to use themselves.
We can then compose these page objects into higher level page objects that represent the widget. Good page objects support a higher level of abstraction for that widget. For example a calendar widget would let you go to the next/previous month, get the current selected date, etc. rather than directly exposing the buttons/inputs that accomplish those actions.
We plan to expose these page objects for angular_components eventually, but we are currently working on how to expose these. Our internal package structure is different than what we have externally. We have many packages per individual widget (page_objects, examples, widget itself) and we need to reconcile this externally before we expose them.
Here is an example:
import 'package:pageloader/objects.dart';
import 'material_button_po.dart';
/// Webdriver page object for `material-yes-no-buttons` component.
#EnsureTag('material-yes-no-buttons')
class MaterialYesNoButtonsPO {
#ByClass('btn-yes')
#optional
MaterialButtonPO yesButton;
#ByClass('btn-no')
#optional
MaterialButtonPO noButton;
}
This problem has been bugging me for awhile and I can not seem to get around it. So I stripped it down to the most basic level.
1. created a new XPage and bound it to an exiting form
2. created a panel called 'displayPanel'
3. inside the panel create a comboBox and give it a few values and a default value of any valid value.
4. Set an onChange event that does a partial refresh of displayPanel
5. Add a computed field that simply displays the value of the comboBox.
6 added a button that does a partial refresh of displayPanel onClick.
Open the XPage and the computed field is blank, make a change and the computed field displays.
open the XPage again and click the refresh button and the computed field displays
Now this is a very simple example but what I need to do is actually more complex but the value of the comboBox (Does not need to be a comboBox) is not available until a refresh is performed. This is only an issue on a new document when it first gets it's defaults.
I have added this:
view.postScript("XSP.partialRefreshGet('#{id:displayPanel}')")
to every one of the page events but it does not appear to do an actual page refresh like clicking the button or making a change.
I'm at a loss as to how to make this work. If I could get this simple example to work the rest of what I need is easy.
Thanks
Fredrik is on the right track -- you should set the value manually during an event -- but I would add two caveats:
Call setValue instead of replaceItemValue (e.g. document1.setValue("myComboBox", "Default Value");). The comparative advantages might not be applicable in this specific case, but you should be in the habit of always calling setValue instead of replaceItemValue (and getValue instead of getItemValue) so that, when you've encountered a scenario where it makes a real difference, you just get that benefit for free... the rest of the time, the methods are equivalent, so you might as well just use the one that requires less typing. :)
You'll probably need to do this in afterPageLoad: the data source may not be ready yet during beforePageLoad; depending on why you're referencing the default value elsewhere in your page, beforeRenderResponse might be too late; and afterRenderResponse would definitely be too late...
...which leads me to why the defaultValue attribute does not behave the way we might expect it to, especially for those of us with experience developing Notes client apps.
The XPages engine splits the processing of every HTTP request into several "phases". Depending on the type of request (initial page load, partial refresh event, etc.) and other factors, the lifecycle will consist of as many as 6 phases and as few as 2.
This tutorial page provides an excellent description of these phases, but in the context of this question, the following are specifically of interest:
Apply Request Values
When an event runs against a page that has already been loaded (e.g. a user clicks a button, or selects a value from a combobox that has an onChange event, etc.), the HTTP request sent to the server to trigger the event includes POST data that represents the value of all editable components. This phase temporarily stores these values in the submittedValue property of any affected components, but the data source doesn't "know" what the new values are yet.
Process Validations
This phase runs any applicable validators and, if any fail, skips straight to the last phase (which means it never runs the code of the event that was triggered).
Update Model Values
If no validations fail (or none are defined), this phase takes the submitted values and actually stores them in the corresponding data source. Until this point, the data source is completely unaware that there has been any user interaction. This is intended to avoid prematurely polluting any back end data with user input that might not even be valid. Remember, not every data source is a "document"; it might be relational data that is changed via an UPDATE the instant setValue is called... which is basically what this phase does: it takes the submittedValue and calls setValue on the corresponding data source (and then sets submittedValue to null). This separation allows components to simply be visual representations of the state of the back end data -- visual representations that the user interacts with; our code should always be interacting directly with the back end data via the abstraction layer of a data source.
Render Response
Once all of the other phases have run (or been skipped), this phase sends a response to the consumer. In other words, it sends HTML (or JSON, or XML, or PDF, etc.) back to the browser. But the most salient point in the context of this question is that the prior phases are always skipped on initial page load. When the user first accesses a page, they haven't had a chance to enter any data yet, so there are no request values to be applied. Since no data has been posted, there's nothing to validate. And -- most pertinent of all -- there's nothing to be pushed to the data model. So a representation of the component tree (or a subset of it, in the case of a partial refresh event) always needs to be sent to the user, but until the user interacts with that representation, the data source remains in whatever state it was when the most recent response was rendered... which is why, if you want a specific property of the data source to have a specific value before the user interacts with it, your code needs to set that property's value manually.
In summary, components are visual. Data sources are abstract. Perhaps this behavior would be more self-explanatory if the component property had simply been called defaultClientValue instead of defaultValue, because that's essentially what it is: a default suggestion to the user for what data to send back to the data source. But until they do, the data source has not received that value. So if, on initial page load, you need a data source property to have a value that it wouldn't already have in its default state, you should manually call setValue to give it the desired value.
P.S. Ironically, if you'd called partialRefreshPost instead of partialRefreshGet, you likely would have achieved the result you were looking for, because the former sends all the form data, while the latter just asks the existing component state to be rendered again. But then you're forcing all of the form data to be sent just to update one data source property, so it's better to simply do what's described above.
I'm wondering about documentation to create a simple custom ribbon control for sitecore shell.
The problem i'm trying to address is that Admins should be able to force all subitems recursively to be approved to a certain workflow state (rather than approve each one manually), but we currently don't know any way to achieve that.
To solve this, we want to force items throught the workflow state (triggering the corresponding commands) programmatically, but we need a sane way for admins to interact with this, the sensible option would be a custom thingie in sitecore shell, but we aren't sure how easy is to achieve that.
any recommended readings for this problem?
Though this article claims to be written for Sitecore 5.3, the same steps apply for 6.x as well. Note: it requires access to the SDN: How to create a ribbon button in Sitecore v5.3
The high-level points from the article are:
Create a new class that inherits from Sitecore.Shell.Framework.Commands.Command
Mark the class as [Serializable]. It might not be necessary for simple commands, but add it now so you don't get problems later! Otherwise the button might not work correctly (this is related to pipelines - and the fact that pipelines might be stopped and resumed)
Override Execute() and possibly also GetIcon(), GetHeader(), QueryState(), GetClick(), GetSubmenuItems()
Add a new <command name="…" type="..."> tag to /App_Config/Commands.config file
Log into Sitecore and switch to the core database
Navigate to /sitecore/content/Applications/Content Editor/Ribbons and create (or copy) a command in the desired chunk
Enter your command name (the one from step 4) in the "Click" field (and supply a Header, Icon, Tooltip, etc)