Wizard of X

One difference I've noticed when I create my bean in the XPage rather than having the server manage it, is that a managed bean seems to be created only once, while loading it up in a DataContext seems to execute the constructor multiple times. If you have a somewhat slow bean, like say it is compiling report data, this can be a significant performance hit. In the example I'm working on today, generating report data took 246 seconds as a DataContext and 117 seconds as a managed bean.

For a long time, every time I wanted to create a controller or model bean, I wrote it and then added it to my managed beans in faces-config. But this can create a very bloated faces config, particularly when these beans are only used by a single XPage. Then I learned about dataContext.

To future me (and anyone else who comes across it): WebContent/ is the root folder for resources. Not WebContent/WEB-INF/. WebContent/WEB-INF/ is actually protected and hidden from the browser, even if you explicitly include it in your URL. So put your /js/ folder and /css/ folder under WebContent/ and not WebContent/WEB-INF/. Future you will thank you for remembering or for checking here before spending several hours trying to figure out why this isn't working. Again. You're welcome. - Past you.

I'm storing this for review the next time I'm looking at buying a drive, but I also thought folks here might be interested:   https://www.backblaze.com/blog/hard-drive-reliability-update-september-2014/

I think by now many people are aware of the Design Definition you can set when creating a custom control. Here is a quick refresher if you are not. A design definition simply replaces what you see when you drop the control on an xpage. By default, it shows whatever is in your control, but this property can be used to replace that with: documentation about how to use the control, for example what custom properties mean or other requirements such as using a data source named "document1" A visual short-hand, for example a control could just show <Header Control> instead of everything inside. This is great for minimizing clutter in the designer and it can also speed up the loading/rendering of the xpage in designer. An interactive tool that allows you to drop additional controls inside  There are a couple of advanced features that can be tricky to figure out unless someone shows you. Here is one:

I ran into this issue today and thought I'd share: I created a custom control, and for that custom control I created a few custom properties. One of these properties was unfortunately named "size". There isn't any warning that size would be a bad name for a property, but that causes a problem. It causes a problem because compositeData is just a Map, and size is a method of Map. So what you wind up getting for some reason, is the entire javascript array instead of the value you are looking for. Something like this: {size=md, label={columns=2, text=test}, input={dataBinding=null, columns=10}} I haven't tested it, but I suspect it would be the same with properties named values and clear, among others. However, if you rename the size property, everything works just fine.

I ran into a problem that it took me a few hours to figure out, so maybe I can spare someone the headache. I'm creating a file using POI and streaming it to the browser. It was working great in Firefox, but in Internet explorer if I opened the file instead of saving it, the file name was xAgent_PrintForm.xsp and not the correct Form.docx . If I saved the file, it had the correct file name. Even worse, it had been working fine before and just started happening without any explanation. It turned out to be a header in my response writer.