good thinking - Comments

Comment From Henry Newberry

Henry Newberry — Thu, 2 Sep 2010 01:37:23 PM -0400

@10 Daniel - We do not hvae a canned demo database of these techniques. Heck we are only now developing them the first time. And the number of mega sized speed bumps have been incredible.

But, send me an email (newbs@teamsol.com) and I may be able to throw one together as I need a sample to prove a bug I have identified.

Newbs

Comment From Daniel Friedrich

Daniel Friedrich — Wed, 1 Sep 2010 11:02:09 AM -0400

Hello Henry,

I wanted to do something similar with my repeat controls, but for some reason, I can't get it to work properly. When I add a new document to the list of documents of the repeat control and save it, the fields are empty.

You don't have, by any chance a sample database were it works that you could send me?

It would be highly appreciated.

Thank you

Daniel

Comment From Henry Newberry

Henry Newberry — Thu, 19 Aug 2010 05:29:18 PM -0400

All right now, using the suggestions of all of you (@Jeremy, @Paul, and @Tim), I got it to work for new and old documents.

I built the dialog panel as part of (inside) the repeat control which uses an array of objects stored in the viewScope which includes the UNID of each of the documents being shown. This panel is setup with dojoType="com.ZetaOne.widget.Dialog" per @Jeremy suggestion. I also built the CSJS file as suggeted which performs the move back into the form element flawlessly!

I then used @Tim's suggestion of embedding another panel inside the dialog and defining a data source specific to that panel based on the UNID element of the Repeat control's object.

Then I added a standard table of fields as @Paul suggested but instead of leaving them unbound, I bound each to the dlgDoc data source.

Finally I added XP Buttons to do the save and cancel. The save button does SSJS to dlgDoc.save(); and remove the top object used by the repeat control from the viewScope. It then does a full page refresh which recomputes the repeat control and reloads it from the newly created or saved documents. The cancel button does the dijit.byId('#{id:editDialogPanel}').hide(); in CSJS with no page refresh.

Only issue left (yeah right) is that the dialog is positioning with its middle point left to right on the left margin of the window. But that's a UI issue that I can get Scott to figure out when he gets back next week.

Since I got it working in one place, time now to make it work in all 10-15 places we are doing similar things... Thanks for all of your help...

Newbs

Comment From Scott Good

Scott Good — Mon, 16 Aug 2010 10:51:11 AM -0400

@7 Tim...that is excellent. Thanks for the detailed instructions. Not only are they easy to follow, they sound like they'll actually work, too! I'll give this a try this afternoon. MUCH appreciated. I owe you a beer or two.

Comment From Tim Tripcony

Tim Tripcony — Thu, 12 Aug 2010 04:17:24 PM -0400

@6 - Scott, we've done what you're describing fairly often. It's a bit more involved a process than just slapping a table into a div, but here's the gist of it:

1. Put a panel inside the dialog box
2. Cut a hole in the... oops, wrong list.
3. Define a data source that is specific to that panel and set its ignoreRequestParams to true (NOTE: making the data source panel-specific is optional, but highly recommended)
4. Calculate the documentId of the panel-specific data source dynamically, pointing it to a viewScope variable (i.e. "selectedDialogDocId")
5. Set the action of the "Edit Me" link/button for each member of the repeat control to set that viewScope variable's value to be the NoteID/UNID of the corresponding document
6. Set the refresh Id of that event to target the panel inside the dialog
7. Set the onComplete of the event to call .show() for the dialog
8. Set the refresh Id of the OK/Save button to target the repeat control
9. Set the onComplete of that event to call .hide() for the dialog

So... again, a bit more involved, but here's what happens:
- When the user clicks to edit any member of the repeat, it actually changes the data source to be bound to that specific document
- Because you're delaying the .show() of the dialog until the onComplete of an event that's targeting the dialog contents, by the time the dialog displays, all the controls inside it are now bound to fields on that document and will show the correct existing values
- Since the button that writes back the data is targeting the repeat, and you're delaying the hide() until the onComplete, by the time the dialog closes, the repeat will already be reflecting any changes that were made (including not displaying the associated document if any of the changes caused it to no longer qualify for the repeat collection). Another handy side-effect of this is that you can even include server-side validations on the dialog fields, because if any fail, the onComplete never fires, so the dialog will still be visible but will now show the appropriate validation messages to the user.

Hope that helps...

Comment From Scott Good

Scott Good — Thu, 12 Aug 2010 03:58:40 PM -0400

Thanks Paul (and others) for your different cuts on this...but here's the question. Well, OK, the NEXT question:

I can get this to work just fine with new documents. For instance, I used Tim's method around a table with a set of fields connected to a particular form and I can pop it up as a dialog, enter some values, submit it, and everything works great.

But (there's always a "but"), we're trying to do things that are more complicated than that. For instance, I have a repeat object which contains many of these addresses. I want to be able to put any one of those addresses into Edit mode and update information in it using the dialog.

I suppose I could work up a way to click on an "edit me" link of some kind and have that link then divert to an entirely new XPage to do the editing in, and then return back to the XPage I was originally on but that seems like a hack. I have huge resistance to the idea of having to load yet another page for every little thing that has to happen in the UI. What I want to do is just click on the link and have the individual address pop up in a dialog like it did when I created it originally.

The way we're doing this with my CSS-based dialog is pretty easy. We use a computed field to show the display version of the data and below it, but still inside the repeat object, are the actual fields which are inside the dialogForeground area and hidden. When I want to edit I change the edit mode of the document in the repeat and unhide the dialog area. When the dialog closes, I also refresh the repeat object so it picks up any changes. Works well and it's pretty fast.

The way I'm trying to do this with Dojo does not seem to work because, I think, I'm calling the dialog with the Client-side script before calling the Mode Change in server side. The dialog appears for a moment (not in edit mode), then disappears.

Am I just missing something obvious here or is this not possible for some reason?

Thanks very much for your help,

Scott

Comment From Paul Calhoun

Paul Calhoun — Thu, 12 Aug 2010 02:33:56 PM -0400

Dojo can be implemented programmatically or declaratively. If the panel you add to the XPage's dojo type is set to dijit.Dialog, then put the fields inside the panel then they are automatically part of the form and you don't have to fuss with any additional code.

So the panel control source looks like this
id="exampleDialog">

value="updateCName();">

and the updateCName client side script looks like this.

function updateCName(){
//The first three lines read the Edit Box controls that were added to the Panel control
//that becomes the Dialog Widget and concatenates them into a string.
var cName = XSP.getElementById("#{id:fName}").value;
cName += " " +XSP.getElementById("#{id:mInitial}").value;
cName += " " +XSP.getElementById("#{id:lName}").value;
//This code writes the value of the string variable to the Edit Box control that is bound to the data source.
XSP.getElementById("#{id:contactName1}").value = cName;
}]]>

Then just have a button or some other event that opens the dialog.

exDlg = dijit.byId("#{id:exampleDialog}");
//Display the Dialog
exDlg.show();
]>

My approach anyway.

Comment From Scott Good

Scott Good — Thu, 12 Aug 2010 01:30:53 PM -0400

Thanks Tim, I'll give it a try.

Scott

Comment From Tim Tripcony

Tim Tripcony — Thu, 12 Aug 2010 12:02:32 PM -0400

Scott, the primary problem with the standard dijit.Dialog implementation is that on load, Dojo moves the div surrounding your dialog contents outside of the form element... hence, all events are broken because fields are no longer posted back to the server.

However, this is surprisingly easy to resolve: add a scriptBlock tag with the following value:

dojo.addOnLoad(function(){
dojo.query(".dijitDialog").forEach(function(eachDialog){
document.forms[0].appendChild(eachDialog);
});
});

This simply moves any dialogs back inside the form so that their contents will be included in any post events.

Jeremy's approach is an elegant way to address other issues with dialogs, but simply by adding the above code, at least you can just use the standard dijit implementation without it breaking server-side events.

Comment From Scott Good

Scott Good — Thu, 12 Aug 2010 11:15:52 AM -0400

Hi Jeremy,

It may very well have been your article I read. It's been quite a while now, so I'm not sure. I'll have to try this again the way you've described. Somehow I never really managed to get it to work before.

Thanks for the tip!

Scott

Comment From Jeremy Hodge

Jeremy Hodge — Thu, 12 Aug 2010 11:05:27 AM -0400

I assume you are referring to the dijit dialog solution I posted to the XPagesBlog ...

There is no requirement to load anything on your server file system ... you can just as easily add the com.ZetaOne.widget.Dialog.js file as a client side javascript library and include it on your XPage as a resource.

Then, all you need to do is set the dojoType, and have your button call the show() method ... Dijit.Dialog is modal by default btw....

Its actually much easier, and you can set the size of the dialog using the width/height style of the xp:div/panel ... and no partial refresh is needed, and you won't run into issues with values getting not saved/not validated if the contents of the dialog are part of the underlying form, but aren't rendered when the save occurs.

Jeremy

Comment From David

David — Tue, 27 Jul 2010 08:33:00 AM -0400

1956 Alfa Romeo Giulietta Sprint Veloce
1968 Alfa Romeo Spider Duetto 1750

Comment From Vitor Pereira

Vitor Pereira — Wed, 21 Jul 2010 10:16:34 AM -0400

Best wishes for both. Go get 'em!

Comment From Scott Good

Scott Good — Tue, 20 Jul 2010 08:44:48 AM -0400

Thanks Joe!

Comment From Joe Deater

Joe Deater — Mon, 19 Jul 2010 09:58:43 PM -0400

Good Luck, drive fast (on the track)!

Comment From Scott Good

Scott Good — Mon, 5 Jul 2010 02:11:16 PM -0400

Great idea!

Comment From Mike Kinder

Mike Kinder — Mon, 5 Jul 2010 12:30:41 PM -0400

Hey Scott,

I read this with great interest as I have been in a position where this was necessary before. However, we solved it a bit differently.

Mind you, I was using a tool I wrote in the 4.6x days that managed record locking for applications. So we wanted to stop users from editing a document that was being edited - on the web. With a simple bit of @Formula and the tool I wrote we were able to accomplish this quite well.

Essentially what happed was, when a user tried to switch a document to edit mode on the web (whether directly by the URL or using a provided button) code ran that checked to see if the document was locked. If it was, we layered a div over the entire screen that told the user it was locked and could not be edited. Then with an auto refresh meta tag we sent them back to a read only version of the document 5-10 seconds later.

With the div overlaying the whole document they could not change any values nor save the changes, thus no harm in letting it open in edit mode. Also, the message told them who had the record checked out/locked and when they locked it. So if it had been some time they could contact that user and see if they could "unlock" it by saving and getting out of the document.

So we, in one solution, came up with effective record locking for the web and a way to control rep/save conflicts.

But this solution is a good one too, just wanted to mention that there was a way to, sort of anyway, "get state" of a domino document on the web.

Mike Kinder

Comment From Scott Good

Scott Good — Mon, 28 Jun 2010 01:41:48 PM -0400

@mdmadph, yep, Vipers, Corvettes, at least one Panoz, a bunch of Mustangs...

Comment From mdmadph

mdmadph — Mon, 28 Jun 2010 12:02:41 PM -0400

I've always loved watching these -- are those Vipers on that track?

(Could be Vimeo just compressing the video way too far down when _they_ stream it, maybe?)

Comment From Garvey Hyundai

Garvey Hyundai — Wed, 16 Jun 2010 08:59:40 AM -0400

Garvey Hyundai !!!Since its my first car it will always be special and my favorite :)

Comment From Scott Good

Scott Good — Thu, 10 Jun 2010 08:31:21 AM -0400

The only weird thing is the quality of the video coming out of the camera (and on my SD card) is WAY better than that you see here. I need to find a better way to convert from one format to another, apparently.

Comment From Eric Peterson

Eric Peterson — Wed, 9 Jun 2010 07:05:53 PM -0400

Thanks for the info. Looked at the ChaseCam site, interesting stuff.

Comment From Scott Good

Scott Good — Fri, 4 Jun 2010 07:23:47 PM -0400

It's a ChaseCam lipstick camera mounted on the roof. Records on an SD card so there's nothing to vibrate.

Comment From Eric Peterson

Eric Peterson — Fri, 4 Jun 2010 11:25:44 AM -0400

Looks at times more like "drifting". What are you using to film? A camcorder mounted to roll cage? Surprisingly good and vibration free video.

Comment From Eric Peterson

Eric Peterson — Fri, 4 Jun 2010 11:25:43 AM -0400

Looks at times more like "drifting". What are you using to film? A camcorder mounted to roll cage? Surprisingly good and vibration free video.

Comment From jeff

jeff — Sat, 29 May 2010 05:21:13 PM -0400

meant brake not break

Comment From jeff

jeff — Sat, 29 May 2010 05:16:10 PM -0400

I've been lfb street driving since highschool (35 years). we were taught that the left foot can stop quicker than moving the right foot off the gas and then onto the brake. i never think about it as being weird or wrong as it is how i drive. it is no different than how we do anything when we drive as we are not born to drive with certain feet positions for driving. in a panic stop, i can physically stop hundreds of feet less than a right foot braker. its basic physics. it takes less time to push my left foot down than someone that has to move their foot from the gas pedal to the break.

Comment From harakudoshi

harakudoshi — Fri, 14 May 2010 10:33:10 PM -0400

Race car, id have to say mitsubishi starion 4wd. (Rally car) street car, its a 3 way tie between a 71 ford falcon gtho phase 3, a 74 ford falcon gt coupe, and a 68-69 holden monaro gts 327/350. (If the street cars don't sound familar, its cause they're aussie muscle cars.)

Comment From Richard Moy

Richard Moy — Wed, 12 May 2010 11:07:50 AM -0400

Scott,

Cool. I have been in a simulator once for a plane and also a simulator for train with 200 cars. You really feel it when you crash a train with 200 cars. You really get a sense of the real thing.

Comment From Tom

Tom — Wed, 5 May 2010 01:14:18 PM -0400

The closest thing to what you have done was to try the jet fighter simulator at the Smithsonian Air and Space (the 2nd one at Dulles airport - not many people seem to know about this Museum). It was pretty exciting but don't do this on a full stomach!

Tom