I have a customer who likes to do some basic stuff in Domino Designer in a specific database. He only works with Forms, agents etc and never do any Xpages stuff. I have done all the xpages stuff in the Database.
This morning when I opened designer I can see that almost all of the xpages design object has been signed by him. but he has not opened any of the xpages design objects. (only forms) and have not signed the application.
When I look at the webpage I can see that the designn changes I did from a few days back have disapeared, so I seem to be looking at an older version of my webpage.
If I go in to the application and Build the application with my id everything is back to normal.
This scenario seem to repeat only a few times a week even though my customer do changes to the application every day.
Image show the xpages time stamp this morning which seem to be about the same time my customer opened the application in designer.
Currently we are both using 9.0.1 FP10 but I have also seen this problem before FP10
ps.
Not sure if it is related but my customer also have another version of Domino Designer (8.5.3 Swedish) which he use when signing agents as signing them with v9 cause them to not work.
What can be the cause of this behaviour and how can I avoid it.
thanks
Thomas
Open Designer. From the top menu, select Project > Build Automatically and ensure it is disabled (not checked).
For additional reading, refer to Nathan T. Freeman's wonderful article "Taming Domino Designer" https://nathantfreeman.files.wordpress.com/2013/04/tamingdesigner.pdf
I am pretty sure that it's the 8.5.3 Designer that does the rebuild when opening the database in Designer. So this happens when the user just wants to sign some agents.
This problematic behaviour has been fixed in 9.0.1 (or perhaps in a fix pack release of 9.0.1). See this IBM technote about the problem: http://www-01.ibm.com/support/docview.wss?uid=swg1LO80591
Related
When we debug an MVC5 application, links are provided to access the running scripts as shown below. This is for a basic MVC5 application that has had absolutely no modifications:
If we simply refresh the screen 3 times on the home page, the list displayed gets longer as shown below:
I've never really tried to debug a script yet. I have used the html links to view pages and I understand I can open one of the .js files, set a breakpoint and try to debug a script. But why are there so many links?. I would have thought I only need a single link for any given script or page that is in progress; that the links would go away when the script or page is no longer active. Clearly I'm missing something about the constantly growing list.
Could someone provide a brief explanation of this feature and how I will use it. My book on Visual Studio mentions this feature, but doesn't provide enough text for me to get a handle on this aspect of the feature.
This looks like a bug in the Edge debug adapter. Specifically, the adapter is supposed to send an event when the page refreshes (or a navigation occurs) to clear out old scripts that are no longer valid for the new execution context (here's a link to the event description in the debug adapter protocol if you're curious).
We've opened an issue on the GitHub project where you can track the progress of the fix.
For a workaround in the mean time, if you click on the bottom-most duplicate script in the list, that should be the latest loaded version, and should work without error.
*EDIT:
We've got a fix for the issue which should be out with 16.2 Preview 2 of Visual Studio.
I've replaced my old dev laptop with a new one, and my Siebel 7.8 Tools aren't enjoying the change: the applet web layout editor gets frozen when I try to scroll.
The applet loads fine, I can add controls, move them around or remove them... but if I try to scroll, it only does so for a moment and then it gets frozen: everything inside the web layout pane (including the scrollbars) stops responding. I've also noticed a visual glitch when it happens - half of the "InfoButton" placeholder and half of the "Elemento" field are duplicated:
The rest of the Siebel Tools keep working however, I can just close the layout editor and open a new one, which will work without problem... until I try to scroll again.
It happens also if I try to show a bigger applet area without using the scrollbar (for example, if I hide the object explorer with Ctrl+E to have more room), or if I click on Preview. Only in that case, instead of a glitched layout, it shows all blank (and freezes).
It doesn't matter if it's a list applet or a form one; whether I'm connected to my local DBF database or to the server repository; if I run the Siebel Tools with or without administrative privileges...
To make things even weirder, the first time I edited an applet web layout in the new computer, it worked fine (a lot of scrolling included). The issue started with the second applet I tried to edit (but now it happens with the good applet too).
The new computer is running Windows 7 (64bits) with IE8. The old computer had exactly the same, only the 32bits version. Siebel Tools have been properly installed (I didn't just transfer my old folder to the new PC). And I've checked the tools.cfg file, specifically the WebClientSiteDir property, which points to the right folder, C:\Siebel_7.8\Tools\PUBLIC\ENU.
Any ideas, other than reinstall the Tools? Has it happened to anyone before?
Solved! I tried a lot of different things, including a full reinstall of Siebel Tools. In the end, it was much easier to fix: I just needed to enable the option "Run this program in Windows XP compatibility mode", in the Tools shortcut.
I'd swear I didn't have it enabled in my previous computer and it worked just fine, but anyway... that fixed the issue for me.
I've been wondering if anybody knows why the Presentation Details (stored in the Renderings field) are shared across all languages and versions by default?
I had confirmed this was the intended behaviour of 'shared' field with these links:
This SO post:
In Sitecore, when adding a field to a template, there's a checkbox called "shared". What's it for?
And this SDN resource:
http://sdn.sitecore.net/sdn5/reference/sitecore%205,-d-,3/field%20reference/field%20properties/data%20properties.aspx
The situation
As an author, I have created a new page and pushed it through workflow approval. Everything is great, and the page is published. The next day, I want to make some changes so I open up Page Editor, a new version is created, and I start adding and removing components on the page.
The problem
As soon as I hit save, the approved and published version of my page is also affected. The history of my previous layout is gone. As soon as a Site Publish is executed by somebody (or a scheduled PublishAgent executes) my page in the Web database will be updated.
Sure, the datasource of my new components that I added may not be published yet, but what if I added an existing datasource that was already approved? My removals also are immediate.
The desired goal
I'd like to be able to version these changes, and changing the field to no longer be shared seems like the right way to go. In my case, with a unilingual site, this won't impact the multilingual aspect of it.
Does anybody know why this field is shared across versions? If I unshare it, am I completely breaking the upgrade path?
I've just been "having a chat" with Sitecore support on this very issue. The concensus seems to be - paraphrasing what they said a bit - "We think it'll be fine if you change it. You should test it thoroughly, rendering deltas, page editor Work and so on".
I can add a few comments of my own; unchecking "shared" on __renderings, does appear to Work. At least at the initial glance. I've heard about this being done in solutions before and I've never heard any ill effects come from it.
And yet; whenever you mention it; you get a LOT of nervous responses and comments like "you really shouldn't be messing with Sitecore standard setup". And while a valid point indeed, I'd like to add a point of my own to this debate:
Given that, from an API perspective, there is very few things that are different when reading a field value from a "shared" field as opposed to a versioned one - I also believe there are very few potential cases where "unsharing" it would pose a problem.
Or in other words - I consider it low risk. But I've never had a real life solution running in a live environment either, with this setting changed :-)
I'm sorry, but I don't have a direct answer to your question - WHY Sitecore set it up like this, I belive to be part of Sitecore's heritage: The idea that multiple language versions of a site should be just "layered" versions of the exact same pages and therefore presentation details might as well be shared - presumably for some performance gain. I am not entirely convinced this vision still quite holds today - where editors daily "page edit up" new components on new versions, and set up special sale banners and related content weeks in advance.
I completely agree with and am thankful for the Mark Cassidy March 3 2014 answer to this. Since then, in Sitecore 8.0 they added "Versioned Layouts".
See:
https://dev.sitecore.net/en/Downloads/Sitecore%20Experience%20Platform/8%200/Sitecore%20Experience%20Platform%208%200/Release%20Notes "Versioned layouts – a different presentation set on different versions of different languages for the same item".
nice post: http://jockstothecore.com/sitecore-8-versioned-layouts-mixed-feelings/
This is the default behavior of sitecore as you mentioned in the post. Its not always good practice to change that. This topic has been dicussed earlier which might help you
Setting __Renderings field not shared in Sitecore consequences?
Here is a blog post about considerations for doing this:
Unsharing the Layout field in Sitecore - a multi-language strategy
That said, I've worked on a project where our client went in and did this themselves. It caused problems. As I recall, they unshared the __renderings field and all prior versions lost their presentation settings. Also, other languages other than the selected one also lost their settings. We had to do a DB restore and get things back and told them never to do that again. If you are considering this, read the blog post about, and do some isolated dry runs as it may expose issues you weren't aware of (e.g. impacting other languages, old versions, etc.).
I have recently implemented some data visualisation using d3.js, I'm now trying to get this to work for Internet Explorer browser versions 7 and above. The common suggestion to get this to work, is to combine d3.js with raphael.js, which is a cross browser graphics library.
There already seem to be some implementations of such libraries such as
r2d3.js :
d34raphael.js :
I'm trying to understand if these existing implementation already have d3's capability of data binding and the physics implementation of the force layout to implement something as simple as this d3 example : http://bl.ocks.org/1095795
I have been looking into this too and a number of options came up.
Chrome Frame - A browser plug-in that actually uses chrome underneath, meaning SVG just works. This is great if you're able to deploy plugins to the browser, for a real commercial environment however this may not be possible.
SVG Web - The aim is it bring SVG to all browsers. It looks like a fairly large project, one that's had Google's input. This doesn't however work out of the box with D3 though I don't know much about the issues.
D34Raphael - You've mentioned this one, I found again it doesn't work out of the box. Check the project out on GitHub, there hasn't been any commit activity in months and there's some pull requests "first pass on trying to get support for .on() required for event binding". If it doesn't support events, is that an issue to you? I'd generally keep away from this one.
R2D3 - Again another one you mentioned. I took the Sankey example from the D3 website and had to make a few changes to get it working. The main things I couldn't get working (Drag Events, Groups - though can use an alternative). It took about a day of effort to get the example working in IE8 and I believe is in a useable state. The project on GitHub is also much more active, the developer is committing, pulling work in and is very active on discussions etc. This gets my vote.
Time was when you set file associations in:
HEY_CLASSES_ROOT\<.ext>
However, that seems to be possible, but an incomplete solution anymore. There are additional associations throughout the registry. For example:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\KindMap
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer\Extensions
And all of the above, but by HKEY_USERS\
And Microsoft added their Set Default Associations control panel applet, which controls... what?
I'm looking for a white paper, or discussions on:
"How is a modern, Windows XP-Windows 7 compatible application written in C/C++ supposed to register and manipulate its file associations without interfering with Explorer, User-Settings, or the Default Associations cpl"
EDIT: I'm trying to further this investigation with more questions here:
How to delete ProgIDs from other user accounts when uninstalling from Windows?
Alas, this documentation still seems current, and it's all about the registry: MSDN
Maybe someone's created a nice wrapper for this? Time to hit Google...
I believe Microsoft wants you to do this through an installation package rather than on-the-fly, since you need elevated permissions to do so.
Edit: See this previous StackOverflow question for how this might be possible.
How to change file association without UAC confirmation?