We have a bunch of databases with similar designs. All of them have some design elements which inherit from various templates. Many of them have a specific view that needs that needs to be updated, but is not marked to inherit from a template.
While I know that I could remove the view from the databases, I'm not sure how I would add just that view from my template to each of the databases without doing it manually.
How would I copy a design element from one database to another programmatically?
I'm not sure why you cannot just mark also these views to inherit from template. Anyway Views are also notes and you should be able to copy a view this way:
lotus.domino.Database db = session.getCurrentDatabase();
db.getDocumentByUNID(db.getView("myview").getUniversalID()).copyToDatabase(dbTarget);
You can not copy the NotesView directly. But you can do it by DXLExporter and DXLImporter.
This is just complex and waste of time.
We have one alternate way for doing this. Instead of copying the view. We can copy the viewColumn and Create a new view in all other databases. Paste these column into it.
Set notesViewColumn = notesView.CopyColumn( sourceColumn [ , destinationIndex& ] )
I know that it does not answer exactly your questions but i wanted to suggest a Different approach.
You can have the view in the template and in all databases.
Then you could add an Option in a Profile to enable or disable the view.
In the outline you can hide or Display the view depending on the Profile setting.
Related
The current CRM UI allows you to create relatively complex queries which you can even extend further with tools like FetchXML Builder.
However, when we get to select the columns in the View layout, the interface provides access only to the first direct related set of entities and does not navigate further down.
There are many cases where the column you want to include in the View is just "two-clicks" away and you cannot include it because is "too far". To make things worse, the FetchXML Builder allows you to re-write the join but it does not allow you change the the columns layout you started with when you opened the View initially. IOW, you can modify the query logic but you cannot include additional columns as required.
One possible solution would be to edit the solution directly and inject the FetchXML directly (I have not tried this though) but I would like to listen to the community opinion first or to other possible solution.
Regards and thank you for taking your time.
Unfortunately this is a long existing limitation. There is no supported customization workaround to circumvent this other than building a Fetchxml report or Power BI report to embed with the necessary layout.
From documentation:
You can include columns from the current entity or any of the related entities that have a 1:N entity relationship with the current entity.
You can tweak the layoutxml of any view, but still it has to be in supported zone to avoid failures.
I am attempting to create a WebPart in Kentico 11 that supports handling an n-length list of items. I found that creating a WebPart with property fields is pretty straightforward in Kentico, but I am having trouble finding documentation on how to best set up a WebPart that can lookup & output multiple model objects.
I've tried the following approach, but it has some drawbacks that I'm not entirely comfortable with:
Set up a Container page type to place instances of data objects inside. I restricted it to ensure that only my custom Page Type data object is available as a child of it.
Place a Pages DataSource in the template zone and direct it to the Container page.
Hook up a Repeater element to it and apply a transformation & content before+after to the Repeater.
While this works, it feels a little cludgey. Content editors have to be wise enough to know how to set up DataSources & Repeaters, plus how to bind them together and apply transforms, and additionally remember to fill in the content before and content after fields with the appropriate wrapping HTML markup.
This is not something that I expect a content editor should need to remember.
Is there a cleaner way to put lists of items inside of a template zone without needing to drag & configure a datasource and container page?
I did not see any way to set up a Page Type field in such a way that it would essentially model a one-to-many relationship with another Page Type. Did I miss something there? If I could do that, then I could write a transformation to handle the wrapping HTML markup, and the looping of children. Haven't been able to find a way to make this work though.
The best way to accomplish what you are asking is with a custom form control. In your case, the form control should be able to let users select multiple items.
You can actually use 'Sortable multiple object selector' marketplace item for this purpose. This form control will enable you to select multiple items based on a certain type (that you need to configure in code) and editors would simply use the select dialog to choose the items.
Is there a way to keep a design element (e.g View, Form, Agent...) in the template database and not refresh it to the inheritance database when I refresh design?
I have some views I want to delete from a database but keep them on the database template. I don't want them to "return" to the database after refresh design
Thanks,
Y
There is no way to prevent design elements from being inherited. I usually use another solution: Versioning.
Create a new copy of your template and give it another version in Title, Filename and Template name. Then remove the views from this new version and replace design of your database. That way you still have an "old" copy in the older template version.
The other advantage is: If something really goes wrong, you can switch back to the "older" version of the template at any time...
In my application, i would like to replace a viewpanel with a repeat control.
However, part of the functionality is there is a UI aspect that allows users to select certain fields (that correspond to the view), and only display the documents that match. The view is doing a filter that allows users to select aspects of the view to create a search (the code is under search of the view) that allows the view panel to be updated with the results of the search.
one of the things that is curious is that the viewpanel has a value of "#{javascript:view2}" vice an actual view name.
The viewpanel defines the search view and the ...
I'd like to be able to apply that same functionality to the repeat control. I don't see those attributes on the repeat control... Any pointers? Its been a while since i've worked with xpages... long enough that I've forgotten a lot already....
TIA !
Read this blog post I did a while back, it should explain what you need.
The view panel doesn't filter anything, it just displays rows from a datasource, same as a repeat control. Indeed you can add components to a ViewPanel's column, pulling from the current row by adding a var property to the dominoView datasource.
The view is bound to #{javascript:view2} (which would be better done by binding to #{view2} - there's no need to call SSJS here). view2 is a dominoView datasource somewhere on your page. The datasource is a wrapper that has properties to capture the settings for filtering and searching that you want to do. At runtime, they are calculated and changes the ViewEntries in the datasource.
Finally there's is the underlying Domino View object available also to LotusScript. This holds and will always hold all entries. The dominoView datasource queries that using the filtering and searching properties and retrieves a ViewEntryCollection or a ViewNavigator.
So whether you use a View Panel, Repeat Control, Data View or whatever else, those are just components to visually represent a collection of ViewEntries or Documents. All can be bound to a dominoView datasource. Where repeat controls and Data Views give you extra power is you can bind them to any kind of collection, not just a dominoView datasource (e.g. DocumentCollection, ViewEntryCollection, multi-value field, Java collection, etc).
I often find that doing the searches in Java and then passing the results to the repeat as a List work better and allow more options. I can get all the information I need in Java and load that into a Map or Tree. This gives me the ability to do custom sorting in the Java class and also to combine data from other views/databases easily. Since the data is now in memory it gets reloaded fast. The only thing you have to watch for is the size of the data. If you have a view with many entries (10K?) you might not want to load everything into memory...
Howard
I'm not sure if you've found a solution yet, but consider using jQuery dataTables. Oliver Busse wrote a very detailed blog post about integrating dataTables into XPages.
To get the specific formatting, I used a repeat control to include the "td", "tr" and "thead" attributes Oliver listed in his blog post.
Is it possible to associate a view with different documents (not simultaneously of course)?
What I want to achieve: the application can have multiple documents of the same type, that can be added during runtime, and set of suitable views, the main of which is CFormview-based. The user can choose the number of the document to show per combobox in the toolbar. The views then associate themselves with this document and update with data from it.
Is it possible to achieve with CMultiDocTemplate?
If yes, how? especially is it possible to retrieve a document by it order number?
If not I'll probably have to abstain from using the templates altogether, which of course means more coding (and more questions to friendly community), but it will do what I want it to do and not Microsoft thought I should be doing
Yes, you could but not out of the 'box'. Instead I'd recommend a different strategy. Rather than trying to attach a View to an existing CDocument derived class LOAD the Views CDocument with the information you want. That could done by adding a simple Copy method to the CDocument or you could move your actual data into a separate class then just point the CDocument to 'data' you want.
Trying to change the CDocument instance for a CView is going against the MFC grain which normally means lot of ASSERTS.