Posts in Category "Uncategorized"

It’s been a while…

Hi Spry:fans,

The weeks just zoom by.

The Spry team has been ‘heads down’ on the 1.6 release.

A couple things to note: We (well, our documentation team….) pushed the Spry 1.5 LiveDocs to the site. They are at

One of our Community Experts from Germany has just written an article on using Spry and PHP:

Kin and I have been looking for some new things to do with Spry, pushing the envelope a bit. Yours truely spent some spare cycles making a periodic table using HTML Data sets and some fun CSS. I wrote a case study for it, describing the thinking behind the code. Check it out here:

A short one this time…


Schedule, Widget, Styling and Source

Good morning spry:fans,

This part of the Spry team is back at his post in California, busy with the next Spry release. I wanted to pass along a couple Spry developments here.

First, the Spry team has decided that we wanted to get some more features into the zip before we could really call it gold. To us, a gold or ‘production’ release not only means that is it stable code, but also that the package includes all the big features that users will need to use Spry robustly. Since are working on additional features that will make a more complete release, we decided to hold off on the gold release until we were all happy with the feature set.

So the next version will be Pre-release 1.6 and we are expecting to release at the end of the summer. We will be dealing with HTML fragments, unobtrusive Spry and a slick CSS selector utility.

But in the meantime, we just posted a widget that we couldn’t quite get in for 1.5. We are happy to preview our new Tooltip widget. You can find that and additional links, including the overview doc, on the Preview page:

Also, we have had many questions lately about styling the Menu Bar widget. Towards that, we posted a few more styling samples on the samples page:

Lastly, I just found this toolkit for IE7. It does many things, but mostly, Spry developers finally have a way to View Generated Source for IE7. Of course, I presume that everyone already has Firebug installed for Firefox…


Hi Spry:fans,

It’s been a while. This part of the Spry team is in Europe, splitting time between vacation and visiting Adobe offices and attending user group meetings. I wanted to talk about some Spry 1.5 things, now that it is out in the world.

First, we are happy that we finally got to release our JSON and HTML data sets. That’s a big advance for the data portion of the toolkit. People have been asking for Nested data sets for some time now and we are pleased to get it out there. The effects got a nice boost too, with smoother action and more transitions. Check it out of you haven’t already.

One thing that has come up since the release is Spry 1.5 and Dreamweaver CS3. People are asking how to update Dreamweaver to use Spry 1.5. Let me explain the DW/Spry products and workflow.

First, a note on timing. Dreamweaver CS3 was released with Spry 1.4. This is because the DW team have to ‘lock down’ Dreamweaver well before the April release date. So they had to lock the Spry features this past winter, therefore Spry 1.4. In the meantime, the Spry team continued to work on its next release. It so happened that Spry 1.5 was finished shortly after the DW release date.

The Spry team develops our features as we see the need and in response to customer requests. And having a much shorter release cycle, there may be 3 or 4 releases of Spry between the next release of Dreamweaver. But since Dreamweaver supports Spry, the Dreamweaver team and the Spry team will work together to add Spry features to Dreamweaver in subsequent releases. So Spry will always be ahead of Dreamweaver, feature wise. This may be frustrating to Dreamweaver users but both teams are looking into ways of updating Spry support in DW.

But by taking advantage of Dreamweaver’s extensibility layer, we can do some things to let Dreamweaver keep up in some ways. We can update the Spry source files used in the sites and update the code hinting for new features. To do so…

Dreamweaver has 2 sets of files: One set of files are the actual Spry files that are used in the browser. It is these files that DW copies to the site folder and are uploaded. There are also a series of ‘design-time’ Spry files that DW uses to work with Spry IN Dreamweaver. These files allow the widgets to render correctly and show the different panels/states. You don’t need to worry about the design-time files. Those will never change.

There are a couple ideas about updating Dreamweaver sites to Spry 1.5.
First, there is updating the Spry files in your site. If you download the Spry 1.5 zip, you can simply copy the new javascript files (and CSS if you need it) to the local root folder and upload the new files and the widgets and data should work as expected.

The second idea is having Dreamweaver copy the Spry 1.5 files to your site when you use Spry components. To do this, we need to update the Spry files in the Dreamweaver configuration folder.

Keep in mind, only the Spry widgets and data that Dreamweaver supports may need updating. Also, not all uses will need or want to update Dreamweaver. If your Spry files are working well and you have no need to update, then no problem.

The Dreamweaver team is working on an extension that will help users update files and copy the new features over to the site. We expect to have that ready for the Spry production release, which will be released this summer. Until then, we are thinking about releasing a simple extension to Labs that would update the Spry source files in Dreamweaver. It would also provide code hints for the new functions and data sets. While we finish this extensions (it takes some testing before we release anything), there are ways to update Dreamweaver to use Spry 1.5 files. For now, it takes a bit of manual file moving.

In short, the Spry files exist in: ‘DW application folder/Configuration/Shared/Spry/’

If you want to update SpryData.js to 1.5, copy the new file and replace the file in DW/configuration/Shared/Spry/Data/

Repeat for the other files you want to update. Spry team member Kin has posted a detailed list of files and instructions on how to update here on the Spry forums:

It’s a wise idea to make a copy of the Shared/Spry folder before hand, in case something goes amiss…

Only the files that currently exist would ever need to be updated.

The Dreamweaver team is however, looking into the idea of providing extensions that will add additional Spry support in DW. This would allow DW to keep with Sprys quicker release schedule. Nothing final on that yet; there are still questions to be answered there…

To be clear: these new files (other than the code hinting) will not add any new functionality to Dreamweaver. It will simply allow DW to copy over new files to your site when you use the features.

Also, DW will detect if you have, say, SpryAccordion.js in your site. If it already exists, it will not copy over the new file. It doesn’t know the file is new. You can just manually copy the new files to your site folder..or, more tediously, delete the Accordion files (or whatever component you are using) from the SpryAssets folder and then insert an accordion onto a new page. DW will then copy the new files to the SpryAssets folder again.

So, more on this later. We have some things in the works that will help with this scenario.

Thanks for reading,


Latest Spry News

Hi Spry:fans,

Quick notes from the Spry world.

First, tomorrow is Spry’s 1 year anniversary on Labs! Thanks to everyone that has joined our Spry community. We appreciate your interest and all the feedback we have gotten over the past year. Spry is better because of it.

Second, the Spry team is busy putting the final touches on the Spry 1.5 Prerelease. We expect it out next week.

Have you seen the Spry LiveDocs?
LiveDocs allow you to post comments and questions that we use to improve the documentation. The idea is that LiveDocs will have documentation that has had time to settle. Features like the new 1.5 stuff will exist on Labs and in the zip. Once those are out for a few months, we will move them to LiveDocs. We also incorporate the suggestions into the next rev. Check them out.

We also now have a Spry Developers Center. Check out the articles there. Let us know if you have ideas for new articles or even if you want to write one yourself!

An example of Spry for those of you with Adobe CS3 products. If you open the Help Pages and do a search, the results are done with Spry!

Due to user demand, the Spry team put out the SpyURLUtils.js file last week or so. Once included on the page, you can set up a variable that gathers either the URL parameters or hashes and populates the var. Now you can easily use them throughout the page. The samples we wrote show how to use them to have a particular Tabbed Panel tab open. This grabs the panel number from the URL and uses it in the constructor. There is also an example of how to specify a specific row for a detail region with Spry Data and URL params. These will be in the Spry 1.5 release and on the Labs site once we go live.

And a final note, at the end of the month, there are going to be a couple Spry seminars in Europe. This humble member of the Spry team will be presenting an overview of Spry. If you can be in Rome on May 29th, or in Milan (Pavia) on May 31st, please come by and check it out.

Next stop: Spry 1.5.



Spry Widgets and Tab Index

Hi Spry:fans,

It has been a big week here at Adobe. We announced CS3, so we can finally talk about Spry integration into DW. While I will jump into that topic in more detail later, I just wanted to quickly discuss a point that has been brought up in reference to widgets, accessibility and standards.

We are using tabindex in our widgets, like on the Collapsible Panel and Menu bar, to enable keyboard navigation. It has been pointed out by some that this doesn’t validate as it is an improper use of the attribute.

We are taking the tack of favoring accessibility and usability over validation in this scenario. Both IE and Mozilla-based browsers have implemented the tabindex to work on most page element just for this reason. We feel that this usefulness for accessibility outweighs validation concerns.

Of course, our widgets are set up to also accept tags in the tabs, which will allow it to get focus. Choose either method.

While tabindex will fail current W3C validation, the standards are catching up. Note that Tab Index is discussed in W3C specs, including the WAI-ARIA:

The Spry team will be discussing standards and accessibility more in the near future.

P.S. Note on the 1.5 Preview: We just added the Effects Migration doc that explains the changes that will be required to go from 1.4 to 1.5.

Spry 1.5 preview is live!

Hi Spry:fans,

I am pleased to announce that we just pushed the Spry 1.5 preview to Labs. This is a sneak peak at some of the new functionality that will be available in the Spry 1.5 release. There is no new zip today. That will not be ready for a while yet, but we wanted to show you what we are up to.

This is an opportunity for the community to see major new features and to provide feedback. We want to make sure that our thinking matches your thinking in the way we implement complex new features, like Nested Data Sets.
The preview materials can be found at
So, today, we are happy to present, finally:

Nested Data Sets – You can access data in nested XML structures. This lets you make the nested lists. We also have a way to do advanced flattening. This takes the nested information and flattens it into the main data set. We want your feedback on our implementation of this.

JSON Data Sets – Per your requests, use JSON data as your source.

HTML Data Sets – My favorite new feature: use HTML tables or other HTML structures as data sources. This will go a long way towards javascript degradation and search engine optimization.

Session Handling – We created a method for detecting session timeouts during the XMLHTTPRequest. Samples for different server models show how to handle the reply.

Form Submission – Samples on how to do form submission via the XMLHTTPRequest.

Paging Data sets – We made some good enhancements to the Spry Pager.

Effects rewrite – As noted in my previous post, we changed the way effects work. Check out the new methodology. No need to change your code yet, but I wrote a document talking about how to change over to the new code.

Radio Button Validation Widget – Cristian whipped this one up in response to use requests this week!

Auto Suggest Widget – Our first data/widget hybrid, set up a suggest text field with data set suggesting.

Spry API – Finally! It’s pretty close to final, but we need to get it out to you all.

Plus a couple more items for you…
Let us know what you think.

Some changes in Spry 1.5

Good morning, spry:fans,

I wanted to talk about one of the changes we are making for Spry 1.5. This is just some information so that you will be better prepared for Spry 1.5. In my previous post, I mentioned the March preview- May release timetable. We are still on track for that. JSON support is now working and we also have some samples on form submission and session handling ready to go.

I wanted to give a brief overview of the changes we made for Spry Effects. For those that upgrade to 1.5, this change will impact existing pages with effects. The changes that will need to be made are simple and straightforward, and we will have a document specifically outlining the changes that will need to be made.

The main idea is that we changed from using functions to using classes to enable the effects. This mirrors how widgets work today.

For instance, in Spry 1.5, a basic effect will now look like:

<a href="#" onclick="theEffect.start();">Start Effect</a>
<div id="effectMe">The content to effect</div>
var theEffect = new Spry.Effect.Fade("effectMe",{duration:500, from:’100%’, to:"0%’});

We have also changed some Effect names to be more straightforward. For instance, “AppearFade” is now “Fade”.

We are also including some wrapper functions that will still run the old versions, but these will take a small change to the code to enable, but less so than moving the functions to objects.

An example:
<a href="#" onclick="Spry.Effect.Shake("theElement");">Start Effect</a>
would be:
<a href="#" onclick="Spry.Effect.DoShake("theElement");">Start Effect</a>

where we added ‘Do’ to the effect name. Then they will work as normal.

This was done for consistency reasons. Now all effects, single and cluster, work the same way. It also was done so that clustering was easier to control, with stopping and toggling being smoother.

And now it fully supports the observer notification model we use for Spry Data.

We think that this change will make using Effects easier in the future. We are always reticent to force changes to existing pages, but in this case, we think it’s worth it.

And of course, if your page is working properly and you don’t want to upgrade, then no changes need to be made!

So that is it for this time. Just some Spry foreshadowing.
We should have the preview up in a few weeks.


Where’s Spry 1.5?

Hi spry:fans,

Thought I would pass along an update on where we are with the next version of Spry. We have some really good stuff in the works.

Kin has been working on the hornet’s nest that is nested data sets. It’s almost done. As we went through different use cases, it confirmed our fears that it was a beast and there are many ways to slay the beast, each with its pros and cons.

A small ‘ferinstance’: Because of the way we flatten, generating something like:

  • Artist 1
    • album
    • album
    • album
  • Artist 2
    • album
    • album

is very different in a data set way of thinking than:

Artist 1 album
Artist 1 album
Artist 1 album
Artist 2 album
Artist 2 album
Artist 2 album

What happens when you sort the ‘album’ column? It depends on how you break up the data. Right now, we are using the idea of Spry.Data.NestedDataSet which is a derived from a standard data set. We also have this idea of a ‘join’, or advanced flattening, where columns from the nested XML are appended to the parent data set.

The point is, there are many issues that needed to be solved for this to work in most (I hesitate to say ‘all’) scenarios. We will have good documentation when this comes out and samples as well. I will discuss it here before and after we release it.

Continue reading…

Why Spry? Part 2

So last we left this question, we had decided to build a toolkit and had some guidelines in mind. These guidelines took into consideration the need of our users, the desire to make Ajax easier to implement and some ideas about markup.

Early on, we started with the data set/region idea. It seemed flexible and easy to build, once the basic concepts were understood. We liked the idea of data references. We didn’t want to needlessly invent things either. XPath was the obvious way to traverse XML files for the data set We tried to stick to conventions with naming data references, etc.

We started with using the class attribute to denote regions (It wasn’t called “Spry” yet….but I will call it such here.). We could do things like: <div class=”ds1″>. Spry would search through the classes and find those nodes with the data set name and know to process them. And then we could do things like <div class=”ajaxrepeat”> and Spry would know to loop over the data set.

But we quickly ran into issues. Loading the class attribute makes for tougher management of both CSS and Spry stuff. Then we thought about Dreamweaver users and the way that class management works. It could lead to trouble. We also were flummoxed when it got to things like if/then statements (today’s spry:if and spry:test). How to do that in a class or id attribute? We were overloading the class.

There were also some other issues to deal with. We tried to use XSL/XPath for real time transformation, but the browser support wasn’t there for it.

We tried using comments to contain the Spry logic, but Safari strips out comments when it loads the page.

We were a bit reluctant but we went to custom attributes. This gave us the freedom to do what we wanted to do. It also freed up the class for just CSS. It also made the page much easier to follow. The attribute stuck out and it was easy to look at the page and parse the flow, not only visually, but in the actual computation as well.

So we went with custom attributes. That let us get into the bulk of the Spry development, as we proceeded to our first release. We had many brainstorming sessions, debating the merits of one workflow over another, running into stumbling blocks and having to change things around. At this time, there were only 3 of us on the team, working on the side as we worked on Dreamweaver. We tried to identify the 80% cases for certain features and work flows.

It was nice to see our concepts come to life. We were leveraging CSS and HTML for template foundations and peppering them with attributes to kick off the Ajax functionality.

But now that we had our handy little attributes, we had new concerns, standards being the first of them. We were loath to break validation. We knew we could name space for validation concerns. The standards part was tougher. Was this innovation worth not being standards compliant? The pull between standards and innovation is a tough one. On one hand, as Adobe, we have a high standard to follow. As a small team trying to do something new, we needed room for flexibility.

The accessibility issue is tough too, not just for us but for all ajax frameworks. In a nutshell, the XML data doesn’t show up as part of the markup. This means that screen readers don;t have anything to read. Part of the trouble is that we are dependent on 3rd party applications for accessibility. Users will seek out the application with the best support, but knowing the state of these apps, it puts a burden on us to develop with accessibility high in mind.

We will cover these ideas in the near future.

But in our narrative, we had the basics of what would be Spry pretty well developed. Kin was heads down, cranking out code, building all the new functions needed for a robust toolkit, or at least the start of one. We still needed a name…

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.