In Designer 8.5, we thought long and hard about whether or not to allow preview of custom controls. In many cases, it "just works" fine. But then we got a serious case of the "what ifs" - what if the custom control takes parameters, should we just preview without the parameters, or do we have to build a framework for sending parameters on preview (and there was no time to fit that part in)??? We don't preview subforms, and that really isn't possible, so symmetry would also say custom controls should not preview. So not previewing them won (at least so far...)
So now looking ahead, I find myself rethinking that... We've had some recent feedback that not being able to preview them is a problem. It's not a huge code change to allow it (unless we start asking for parameters). Should we allow preview of custom controls? Should we just warn if the control has parameters and allow the user to continue or cancel the preview (that's my current leaning!) Sanity check, please!
Subscribe to:
Post Comments (Atom)
5 comments:
hmm, how about a way to supply parameters for preview? that way, the developer can hardcode values for the preview of the custom control? if parameters are involved, don't do a preview until sample params are set?
yes to = Should we just warn if the control has parameters and allow the user to continue or cancel the preview
Palmi Lord
isn't that what default value are for? You could extend the dialog with one value:
"Preview Parameter Value"
If that is empty then the "Default" value kicks in. If that is empty then the parameter is empty - which also could be the case when you embed the control.
I'm not sure if it would work under all scenarios, because parameters are not the only thing made available to a custom control from its XPage. I have applications where a header custom control is used across various XPages and also adds in all my stylesheets or script libraries. All my other custom controls just reference the functions and styles. Previewing these custom controls may then fail, because it's trying to run a script that it can't find.
Also there may also be script running on e.g. a beforePageLoad event on another custom control that set scoped variables which are needed.
For the first scenario, using a theme may be a resolution, but I id quite a bit of XPages development before getting to grips with themes. And I can envisage scenarios where I don't want to load all my script libraries for a read only XPage, and want a different stylesheet for edit mode.
It's a great idea, but if the preview generates unexpected errors that will not occur if the whole XPage is previewed, it might cause frustrations.
I agree with just a warning for parameters (though a future release probably should handle the params during a preview).
Having said that, I hope that this is an overall minor consideration for time being spent.
One of the major drawbacks to xPages is the lack of coherent documentation, particularly in light of the rather large learning curve. As far as I can tell, exactly one book came out of IBM that talks about xPages at all. One chapter and barely a mention of it.
The new designer also seems to have quite a few issues with crashes and providing java errors when problems occur, which is much more often than is expected to be happening with a r8 product, even if the underlying technology is brand new.
Experienced Domino developers who aren't also experienced Java developers definitely don't need to spend hours determining what the error means when Designer bails on something. No one does. We want a product that works and helps us accomplish our jobs. RAD environments should heed all three letters in that acronym, the first of which is Rapid. The new Eclipse-based designer isn't always that.
Post a Comment