I am using JDeveloper 11.1.2.3.0
I am facing a strange behavior here. I have created 2 AppModules and in each AppModule I have DataControls from the same View Object (not only but also). When I create a new row using Page1 for example using DataControl from AppModule1 and then navigate to Page2 that uses DataControl from AppModule2, the Commit and Rollback buttons are enabled. Even if I redeploy the application in this case I have to Commit also in Page2. If I do this, then the problem will not show any more.
So even through I commit in the first case, I have to commit also in the second page. As I said the EO and VO are the same, just the AppModules are different.
Does anyone know why this happens and/or how to fix this?
If anyone knows that this is a known bug please tell me.
Well I hurried a little, I just found the solution (the problem actually). Apparently different app modules are completely ignored one by other and have their own db connections. The explanations is here:
http://www.jobinesh.com/2010/03/what-you-may-need-to-know-about-nested.html
Related
Yesterday, the person in charge of adding content to our OrchardCMS website suddenly got this error when trying to access the Content section in the Dashboard and we can't add any new content any more.
I've imported a bacpac of the database in production and started locally debugging. When trying to access the Content an exception is thrown right here:
And, if we look in the database, the Orchard_Framework_ContentItemVersionRecord table contains a duplicated item with the same version Number, both are "latest version" and they both have the same ContentItemRecord_id.
My concern now is how should we fix this without causing any side effect somewhere else, since I don't fully understand how Orchard manages relations between items, parts, and versions.
Solution proposal:
It seems natural and obvious to manually update the "is latest version" of one of the items to false and increment the version number of the latest one.
Is this solution right or will I cause a side problem?
Have you experienced this before?
Do you know if this is caused by a wrong way of defining the model or something I can do to prevent this from happening again?
Quick answer: it is probably due to double clicking the publish button... Small tip and hack: hide publish button on click...
I remember that happened to me once before, it was ugly situation and a lot of debugging had to be done to find the cause.
The only fix I could find back then was to alter/edit/fix the db data manually.
I must ask
did that error happen once or does it happen all the time?
I have deployed a document library hook which includes many jsp files under custom_jsps.
Recently, I wanted to change folder_action.jsp, so I changed it and deployed it normally in document library portlet.
As it was expected, a folder_action.portal.jsp was created containing the original file.
However, I've noticed something strange. After stopping Tomcat both folder_action.jsp and folder_action.portal.jsp are deleted(this is not happening for the other files that come from the hook), and when it is up again a really strange thing happens. The folder_action.portal.jsp contains the changed file and the folder_action.jsp is the original file.
Has anyone met something similar ever? Any help would be appreciated.
You might run into a very nasty issue: You must only override a particular jsp from exactly one hook. If you override the same jsp from two different hooks, the scenario that you describe might happen (on undeploy). Worse: Order is not maintained, you might have some "wrong" files left over.
Find the two hooks that override the same jsp and determine which you like better (or merge the two). Find some more horror in this answer to a similar question
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.
EDIT: might be fixed in latest Xcode 4.0.2 (just released) - I'm downloading this out now, and will re-edit once I've tested it.
Create two entities (call them "Manager" and "Employee", to stick with Apple's docs).
Create a relationship, "worksFor" from Manager (1) to Employee (many), and mark it as "not optional". (you'll probably need to create 2 relationships, mark 1 as inverse of other)
Hook up an interface using IB, according to Apple's original docs (NB: these don't work any more, but here's an almost exact recreation of the basic setup in Xcode4: http://rgprojection.blogspot.com/2011/04/xcode-4-and-core-data-macos-x.html) and use Bindings (as described in the linked post) to create/add/delete the objects.
Now try to save. ERROR: "worksFor is a required property".
In previous versions of Xcode, this worked as expected: you'd told Xcode that there was a bidirectional relationship, you told it that it was required, and so when it added the "Employee" to the "Manager", it automatically hooked-up the inverse.
Has anyone else worked out how to make Xcode4 do what it's supposed to? Is it an Xcode4 bug? I know that some of the CoreData support in Xcode4 has been deleted, with no replacement (yet), so I'm wondering if this has been deleted too?!
EDIT: here's another project, one I made from scratch, same problem. Although (xcode4 bug, definitely!) this time I created the Relationship in the "grid" editor view rather than the "tree graphical" view... and the generated source code for objects was different (should not be the case, obviously)
second project screenshot
EDIT2: StackOverflow was showing the screenshot above, but has now removed it, you'll have to click on the link. Sorry.
I haven't seen the problem you describe and I've created several data models under Xcode4. It appears to work just like it did in previous versions in that regard. I think you've got something else going on.
Xcode 4.0.2 seems to have fixed the problem - everything works as expected now, with no changes to code :)
I see this referenced a lot: http://ajaxify.com/run/crossframe/
And I noticed now it's no longer working for the IFRAME (child) to change the parents hash.
I've been spending a few hours trying various things wondering why this isn't working anymore -- then I finally realized that the example I originally based it on was down too.
Can anybody confirm?
-
-
I need to use a cross domain iframe to take care of an order upload form that our shopping cart doesn't support, and I need the form to return an order ID to the parent, so that I can associate the data between the two servers.
Any recommendations or directions to head in would be appreciated.
I'm not looking for a shortcut or somebody to do my work. I've been reading all day... I just need a nudge in the right direction.
Thanks!
It is partly browser-specific. For instance, some browsers don't allow a nested child frame (iframe within an iframe) to change its parent's fragment. See this blog entry. But the basic functionality still works in recent browsers. This demo, which has an iframe change its parent, and vice versa (single level) works fine in Firefox 3.5.9 and Chrome 5.0.375.99.
The demo you gave also works both ways in that version of Firefox. It doesn't allow the child to change the parent in Chrome. The main difference seems to be that the working one uses parent.location, while the broken one uses parent.window.location.hash.
The best solution for recent browsers is postMessage. If necessary, you can also use a server proxy.