Answers to Spry Comments

Hey Spry:fans

I thought I would periodically post replies to comments previously made.

Sammy asked: “You mentioned several of the teams goals, which all see worthwhile, especially from the developers’ who will use Spry point of view. Do you feel you’ve accomplished those goals, and if so, how?”
By goals, I take him to mean “easy to understand, easy to implement, clean code…”.

I would say that we are off to a really good start but still have room for improvement. I think we have found a good niche and I think our principles are sound. I think the region idea is unique in Ajax libraries and the attributes mirror common programming principles, making it feel like an extension of server side languages. But we have a ways to go. We have many new features we want to add and we can improve the way we code things. For example, we are making some changes to the way we code effects to make it easier to make cluster effects. But we only really know if we are on the right track if you tell us so, so let us know. Our pager sample is very cool, but we know that we should make it even easier to page data and create standard paging interfaces. We are working on that right now!

Ray is asking for API docs. They are written and we are trying to wrap up the editing so we can post them. I am really anxious to get them up, so as soon as they are ready, we will post them. Eventually, our docs will be ported to Live Docs so users can comment.

Colin is asking about the target audience for Spry and also about product integration. Our target audience is more on the designer side. The idea of using clean code, no custom tags and no injecting markup makes it easy for designers to know what the end result of the page is. Packaging the XML request into a simple, one line call, is pretty straightforward, even for those that aren’t JavaScript masters. There is a learning curve for Spry, no doubt, but we hope it’s easier to get started with than other frameworks. And since it is straight javascript, more advanced developers can leverage the work we have done and bend it to their will. As for product integration, we have stated that DW will support Spry. It’s too early for me to get into specifics, but it hopefully will make Spry development even easier. Some other parts of the company have integrated Spry in smaller ways, and I will discuss those when I can…

Phillip mentioned that our samples are too complicated, with too many examples of features. It makes it more difficult to get the big picture. I can see this. The accordion sample is quite guilty of this. But the samples are supposed to show off the features. In the Spry zip, we have a top level folder called ‘widgets’. These are the archetype copies of each widget: Just one example of the clean, basic widget. These might be better starting points. The samples are supposed to be more expository, but at the same time, we are trying to keep the samples clean, with minimal CSS. We have the demos for more real world, heavily styled examples.

And Bernd gives us thanks for the documentation and simple approach. We thank you for the kind words!

That’s it for this time. Let us know if there are features you would like to see, samples we should have. If you want to know the thinking behind some part of Spry, let us now.

Thanks,

Don