The Xcelsius SDK as it stands today is a set of core functionality that provides developers with the ability to inject virtually any type of Flex application or component into the Xcelsius designer. The SDK offers a great deal of flexibility and essentially gives developers a blank canvas to start from.
With all of this flexibility available, which is what most developers ultimately want, the SDK can often times be a stumbling block for people trying to get started on custom component development. It never was for me personally, I took a look at some of the examples that came bundled with the SDK and was quickly off and running. However, I think that I picked it up faster because I had a lot of experience in Flex and Xcelsius, so there wasn’t a fundamental gap in my mind as to how all of the pieces fit together.
I think that the gap that causes a lot of developers who are new to the SDK to spend a lot of time up front, is trying to figure out how the entire platform fits together and how their component fits into that picture. This makes sense, because most developers want to know what’s going on in the grand scheme of things so they can make the right development decisions at the component level.
With the way the current SDK is set up, there’s no really, really clear path for even fairly talented Flex developers (that are unfamiliar with Xcelsius) to jump in and get started without first getting mired down in the technical minutia. Like I said, the SDK offers a great deal of flexibility. It’s the brick, mortar, wood and nails you need to build a house. My thought is; is there a way to repackage the SDK to where all of this flexibility still exists, but at an easier to use level? Instead of wood and nails, could we give people highly configurable frames and still achieve the same ultimate objective?
I think this is definitely possible and have started to spec out a framework that would enable a Flex developer to come into the SDK, drag and drop a few components onto a property sheet, and with absolute minimum customization, facilitate even the most complex of Xcelsius integrations. The goal is to bypass the finer details of boiler plate property sheet operations and integrations and instead focus attention on what matters most – the guts of the actual component and making a great UI for the property sheet.
My parting questions to developers invested in the SDK are:
- Do you like how it’s currently structured?
- What if anything did you find challenging?
- What would make it easier to work with?
- What are the top 3 features you’d like to see included?
I’m gathering this feedback for a labs project that I’m working on for the upcoming ASUG event and will be able to share the result with other SDK developers. All input is welcome.
Evan DeLodder is CTO at Centigon Solutions, an SAP Partner focused on the development of cutting edge mapping technologies in the Business Intelligence space. To learn more about him, please visit our Gurus page.
