We have inherited a web application in Lotus Notes in which we are trying to introduce XPages (we are new to both Lotus Notes and XPages, please forgive our inexperience).
We have a view that we are trying to swap with an XPage. The current view is called like this from the application menu (the view is being called from a form):
<a href="FRVWFACSPROVXEstadoAno?openform" target="ifat">
And we are trying to call the XPage like this:
<a href="Prueba.xsp" target="ifat">
For some reason, the link is expanded at runtime to this:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/Prueba.xsp
The page is not found because the database name is in uppercase (in fact, if we change TBS_AGORA_FIN.NSF to TBS_AGORA_FIN.nsf, it works). It is also strange that the current link is in uppercase, too, but nevertheless it works:
http://tbsdesa.es.lladro.com/FORMACION/CARLOS/TBS_AGORA_FIN.NSF/FRVWFACSPROVXEstadoAno?openform
We would like to know why the database is in uppercase. Could the Domino server be doing this?
I'm going to assume based on your question that you're calling your link from a form or page that's rendering as HTML. Since it's a relative link, you're probably navigating to it through a link that includes uppercase for the .NSF in the title. This can be solved either by fixing all your links so that .nsf is lowercase, or by calculating your XPages links better.
To do the latter, I usually do the following for XPage Links:
Link
Where XPage.xsp is the name of my xpage and the value of the Computed Text is:
"/" + #WebDbName + "/"
This will calculate the link based on what Notes wants to refer to the database as.
Hope this helps.
What OS is the server running on? If the server is running on Linux/Unix then you need to be aware that directories and filenames are case sensitive. The tricky thing, however, is that once they have been opened they are cached by the server - and will work without being case sensitive (for some time...). This can be really tricky to troubleshoot if you are not aware of the cause ;-)
I agree with the possible solution suggested by Aaron, however, it really should not be necessary... It should be better to leave that to the server.
If you are running on a *nix OS then ensuring that all paths and filenames are in the same case (I use lowercase) is a good practice...
/John
Related
At the moment when you go to select an image inside an entry using the EE default file manager, the default view is 'show files as a list'.
Is there a way to show the thumbnail view as the default?
At this point I would be happy with a core hack.
I don't usually use the file manager for sites (much prefer Assets) but this client had a tight budget
I've wondered about doing this in the past as well - turns out it's pretty simple. Open up ee_filebrowser.js and search for the first instance of a("#dir_choice").val(). Immediately after that add this:
; a("#view_type").val('thumb').change();
Make sure you include the leading ;.
I've only tested this in Safari but I can't see why it wouldn't work everywhere. Incidentally, JS beautifier makes this sort of thing infinitely easier.
I don't recommend hacking core for any reason and I suggest it should be avoided at all cost.
With that said, I will provide what I've found out just the same.
Looks like the following files, in EE 2.5.3, are what you'd want to edit:
/themes/javascript/compressed/jquery/plugins/ee_filebrowser.js
/system/expressionengine/libraries/File_field.php
I found these doing a file search in my text editor for view_type which was from the id of that dropdown. The javascript is minified so you'd probably want to un-minify it and then rewrite the part which handles the switch. I'm not the best JS/jQuery person out there, and un-minified js makes it a bit harder too so, I won't offer any more than what I've found so far.
Consider pulling out the parts parts from the two files if you aren't great with js and maybe start a new post tagged accordingly.
Also note: there might be more to this than just those two files so consider this answer a start and nothing more.
I have an XPage to display document data. To display RichText data I added a RichText control. What I found out is that database / view / document links are displayed with the appropriate icon but are converted to http-links. I would like to have these links being transformed to notes://-links to make sure that these links are being opened in the user's notes client rather than in the user's browser.
Any suggestions how to accomplish this from a technical point of view?
Many thanks in advance for your help.
Michael
Speak after me:
The web knows no RichText, it is a ghost of Christmas past.
There is only MIME. Now go and live with it!
Unless you build an hybrid application where RichText is used in the client and browser I recommend to select the option [x] Save as MIME in the RichText options. For hybrid applications it depends on the use case.
In your case it seems (?) that the datbase/view/document links are added using a client. It looks like a good idea to use mime in this case. Then is is just a simple string (of HTML) where you can before display (or save) use a DOM operation or a Regex to sort out the content. That works client or server side
You could have a custom control that contains a DIV and a XSP.addOnLoad() script that uses the RichtText url in an Ajax call and a dojo.query("a") to get a handle on all links and then sort out the ones you want to alter.
Let us know how it goes.
Xpage (listPostits.xsp) has a "View" container control, where one of the column is set "show values in this column as links".
Now, here comes "Strange behaviour".
When i work with this application on my own (developer) PC (Win XP, Chrome or IE), the Domino generate the link, which can't be really processed:
/servername/db/postit/postit.nsf/listPostits.xsp/onePostit.xsp?documentId=many_numbers&action=editDocument
Namely, the Bold-marked portion shouldn't be there ! This portion is the name of the XPage, where the View control is in.
When i work with the application from other PC (Mac, Firefox) then i get the correct link (the same as above but without the XPage name inbetween):
/servername/db/postit/postit.nsf/onePostit.xsp?documentId=many_numbers&action=editDocument
update: let us leave for the moment the differencies in generated links between two machines. The first question is - why the extra portion is inserted into automatically generated link?
After playing around i think i might have found the reason for this strange behaviour. Namely, the "Substitution" Rules on the server side. One of them is to substitute "*/postit/all" with "/db/postit/postit.nsf/listPostits.xsp"
If i switch it off, then the Links are generated properly. Still, it's pretty strange to me that these settings influence the way Domino generates the links. I thought it works on the fly with them and those settings have nothing to do with the way how Links are generated inside the application.
So, the help now is needed regarding Web Site Rule Topic, but for that, i guess, i have to create another topic. But in case somebody has some good Info on this, please share it with me. I'm a bit confused at the moment :)
Final Update: Spent some more hours of testing and the results confirmed the initial idea.
If i open the page with the standart URL, i.e.
http://servername/db/postit/postit.nsf/listPostits.xsp then everything is fine, links are generated properly. When i however open the same page with short URL http://servername/postit/all , then server adds the substitute URL (db/postit/postit.nsf/listPostits.xsp) to every single link he generates automatically to be used as the link to open/edit the underlying document.
Is it bug or feature ? Don't know.
As a workaround (because i want to keep simple URL's for the application) i have to manually generate links.
I want to add text to body element but I don't know how. Which method will work on the body tag?
Sorry for my english and thanks for replies.
In Watir, you can manipulate a web page (DOM) using JS, just like that:
browser.execute_script("document.getElementById('pageContent').appendChild(document.createTextNode('Great Success!'));")
I assume that the point of the question is:
All users are not just interacting by just clicking buttons and links on the web app, some of them are doing nasty things like altering http requests to make your system do something that it is not supposed to do... or to just have some fun.
To mimic this behavior, you could write a ui-test that alters forms on the web page, so that for example, one could type in anything into any field instead of a limited dropdown.
To do that, ui test has to:
manipulate DOM to set form inputs free of limitations (replace select's with input's, etc.)
ui test has to know, which values to use, in many cases it's pointless to enter random values. Your webapp has to provide some good "unwanted" options.
Why would you want to modify the webpage in Watir? It's for automated testing, not DOM manipulation.
If you want to add something to the DOM element in javascript, you can do it like that:
var txt = document.createTextNode(" This text was added to the DIV.");
document.getElementById('myDiv').appendChild(txt);
Or use some DOM manipulation library, like jQuery.
If you have not worked your way though the watir tutorial, I would suggest you do so. It deals with things like filling in text fields etc.
Learn to use the developer tools for your browser, Firebug for Firefox, or the built in tools for IE and CHrome. They will let you look at things as you interact with the site.
If the element is not a normal HTML input field of some sort, then you are dealing with a custom control. Many exist and they are varied and there is no one set solution for dealing with them. Without knowing which control you are using, and being able ourselves to interact with a sample of it, or at least see the HTML, it is very very difficult to advise you, we basically have to just guess (which is often a waste of everyone's time)
Odds are if you have a place you can enter text, then it is some form of input control, it might not start out that way, you may need to click on some other element, to make the input area appear, but without a sample of HTML all we can do is guess.
If this is a commercial control, see if you can find a demo site that shows the control in action. Try googling things like class names for the elements and often you get lucky
I have seen many somewhat similar questions, but nothing quite what I'm looking for. So at the risk of being told this is a duplicate... here it goes.
I've found that there are times I have a node that simply contains content that will be displayed somewhere else, but shouldn't be viewed directly. That is, no one should ever go to node/1234, but the content in node 1234 should be displayed somewhere else.
For example, I create an about page with tabbed content using views. So there are "About Me", "About Us" and "About Them" pages. All of these are displayed in a single page with tabs using Views. So I don't want people to get directly to the "About Us" node because then they wouldn't see the tabs for the other pages. At the same time, I don't want Google giving people a direct link to this node, I want to limit access so users can only get to it through the View (i.e., the tab).
So I need to restrict access to the node, remove it from the Drupal search results, and make sure Google doesn't pick up on it. Any suggestions?
---- Note ----
I've accepted the answer from mingos (thanks btw) because even though it's not a full answer / solution, it gave me some good things to think about. Additional answers are still welcome.
In Drupal 7 you can use: http://drupal.org/project/internal_nodes
Description: Some content/nodes should never be viewed directly; only visible be through something else such as Views or Panels. This module denies access to node/[nid] URLs while allowing the content to stay published and otherwise viewable.
Full disclosure: I am the creator and co-maintainer of Internal Nodes. I found this question while searching to see how the module could be found on Google.
Tough one.
If you want to have many nodes like this and do the "displaying elsewhere" dynamically, I can't think of anything right now (at 2:20 AM I rarely can).
If there is onne such page (or very few), I'd restrict access to it by any available means (Permissions, Nodeaccess, Content Access, TAC, whatever) and then create special themes for the pages where the restricted content should be displayed. The themes would contain database queries, fetching content from the restricted nodes.
Other possibility might include creating a special theme for the hidden nodes in question (perhaps all belonging to the same content type?). Make full node display nothing (or a message saying the access is restricted) and add a ROBOTS meta tag asking Google not to index the page. Make the teaser view available though - you can display it freely inside a view, but since /node/1234 is the FULL view, the actual content will be unavailable here.
Dunno if this solves your problem, hope it helps at least a bit.
I found this page after running into this same problem.
What I found worked for me might be part of the answer you need:
Take a look at the Page Manager Redirect Module http://drupal.org/project/page_manager_redirect . I just started playing with it.
It uses the Page Manager module of CTools to redirect one page to another. What makes this most powerful is that Page Manager uses Contexts. So, if you want to redirect all pages of a particular content type, you can do so.
I just started to use it (instead of Taxonomy Redirect and Path Redirect) to redirect (301 response code) my taxonomy terms for a particular vocabulary to particular nodes.
In your instance, you should be able to use contexts to filter for specific pages.
Of course this doesn't solve the problem of these nodes coming up in search results.
There is also another module Rabbit Hole which has a similar functionality like Internal Nodes but works for all entities, not only nodes.
I am having the same problem, and are currently thinking of the following solution where all the content of a node is to be displayed to certain users (permission based):
- unpublish node
- create a new published checkbox
- create a view with fields that shows alle the content
Haven't tested it thoroughly yet, but it seems to work.
The node is to be displayed to the creator (only one in permission 1), some of it to permission 2 and all of it to permission 3.
Any comments on this solution.
I assume this will also exclude it from search, but permission 2 and 3 needs to be able to search it. Still haven't figured that one out.
I used Rules module with an "entity is of bundle" and the built-in "Page redirect" action.
There is a really easy way to do this if you only want to show a content type through a view.
create a content type as and make it unpublished.
create a view and on the filter option set the filter to "Content: Published (No)"
the view will give anon users access to the content through the view but they won't have access to the unpublished content at the direct link to the content.