31. Documenting JavaScript is Hard function() { myUtility = function() { if (arguments.length == 2) return arguments[0]*arguments[1]; else return Math.random(); } }(); Non deterministic Might be read as anonymous() Should be myUtility(n1,n2); myUtility();
55. Spry Effects var fadeEffect= new Spry.Effect.Fade(’myElId', {toggle:true}); fadeEffect.start(); Simple Interface Chaining via Observers unFade = function(element,effect) { fadeEffect= new Spry.Effect.Fade(element.id,{toggle:true,finish:unFade}); fadeEffect.start(); }; var fadeEffect= new Spry.Effect.Fade('thanksDiv',{toggle:true,finish:unFade}); fadeEffect.start(); var fadeEffect2= new Spry.Effect.Fade(’myElId', {duration:2000,from:0,to:100}); fadeEffect2.start(); var growEfct= new Spry.Effect.Grow(’myElId', {useCSSBox:true, growCenter:true}); growEfct.start();
64. Spry Data Set API var myFilterFunc = function(dataSet, row, rowNumber) { // Filter out all rows with paths that begin // with the letter 's'. if (row["@path"].search(/^s/) != -1) return row; // Return the row to keep it in the data set. return null; // Return null to remove the row from the data set. } // Filter the data. dsPhotos.filterData(myFilterFunc); // Remove the filter. dsPhotos.filterData(null); Programmatic Filter
Thank everyone Quick summary of everything Developers / designers?
My career thusfar has been really concentrated on javascript development, although I am a fan of some other platforms. To give you a sense of my javascript background and what I’ve been doing with it Ive prepared a few slides Senior Web Architect, Foresee Results Used to build JavaScript components (Nitobi) Creator of RobotReplay – sold to Foresee. Couple books Other interests: iPhone dev, RC aerial photography..
For a long time worked for a Canadian startup making JavaScript and then “ajax” components. Rich ajax Components a lot like what you see now in YUI or EXT but with fairly comprehensive back-ends in ASP.NET, PHP, Java, and so-on. Heavy-duty industrial mini-javascript applications as opposed to lightweight widgets.
To summarize the point of all that.. JavaScript has become enormously powerful. Its no longer a tool people who people who couldn’t cut it in other kinds of programming – and adobe and other big players like microsoft, and IBM are taking responding to that shift by providing powerful tools for us to develop better code more easily. Got some major customers. If you’ve seen the Foresee logo on a website in recent months and answered a survey you’ve probably been recorded without even knowing it.
I’m not here to sell you anything but if I were it would be this red book on the left. However if you care at all I’ll probably just give you one at the end of this talk. I have a few for that purpose. The red on in particular is decent.. Fairly comprehensive reference Talk about some of the topics covered Offline storage HTML5 Flash and silverlight communication Performance.. Hardcore tricks Browser differences One of the few comprehensive API references around. For the love of jebus DON’T brag.. Self deprecating Free books at the end of the preso
This is the point of my talk today. I use the word rock star basically to refer to that kindof irritating group of developers just know the browser inside out to a level where they have become irriplacable in their organizations because nobody else can understand their code or what exactly it is they do. If you do or want to do a lot of JavaScript development, you should be aware of what tools are available in the DW stack .. And how to use them. I’m also going to talk about why developers should start to change the way they think about JavaScript as an argument for getting into the habit of using CS4. The basic idea Im trying to convey with all this is we’re moving towards a day where there will be no JavaScript or CSS rock stars and a lot more people will be able to operate on roughly the same level because all of the people who make tools are providing better solutions: Better and easier javascript frameworks Better CSS frameworks Better debugging tools Better IDE’s that tie all these things together.
Mention dreamunit Main point of today is that by the end of it I want you to begin to recognize that the toolset that adobe is providing around dreamweaver can actually be of enormous use to even experienced JavaScript developers in particular, but in particular development teams.
I want to try to communicate where I think JavaScript and Web development in general is at from a technical and cultural perspective – to try to communicate a bit about where I think it might be going… how that relates to the tools we use. Will talk about the pain points are at
Here we’ll talk about some specific attributes of CS4 that make our lives considerably easier and how you should be approaching JavaScript development where DW is concerned. I’ll try not to bore you too much with slides and show you some things. I’ll also highlight a couple things you might encounter that would cause you pain.
Then we’ll spend some time looking at the spry framework. I’m going to try not to do anything resembling reading whats in adobe’s documentation to you, and instead highlight a few features and uses that you might not have considered if you’ve only looked at spry quickly or not ever used it. We’ll do a development demo and decorate a form with some spry widgets. I should qualify now that I’m not a heavy spry user by any stretch of the imagination, but I have an opinion it anyway.
When you get to Firebug mention: Every EVERY javascript developer in the universe. Not just the world but other planets most likely use firebug on a daily basis. Its that important. Has helped promote Firefox downloading actually. And probably why Firefox is the leading browser for developers. I put Firebug on here because its germain to what we’re talking about today because its an example of how good tooling can change the quality of products being produced by developers. Which unfortunately I cant prove to you, but its self-evident that when you have better tools you build better things because it makes repetitive tasks like inspecting the DOM and facilitating logging fast and easy.
Shows the increasing sophistication of tastes. People are seeing the value in working with higher-level abstracted frameworks like jquery and such vs pure JS.. Cuz JS is hard! Interest in ajax vs javascript sortof offset one another in my mind, but the late jump in jquery searches shows that it’s beginning to take the place of pure homegrown javascript and reflects a maturation in that part of web development.
Jquery taking off
What’s scott’s background I think the last time MS Integrated with someone like this, it was crystal reports and they paid a tonne of money
http://web.mac.com/alexander.atallah/Mac/Development/Entries/2007/9/9_Introducing_KitMate:_TextMate_+_WebKit.html You can set breakpoints, inspect variables and evaluate expressions all from within Eclipse. The screenshot shows the debugger in action stopped at a breakpoint.
Remind people that strictly speaking, JavaScript is a kind of trademark that defacto belongs to the mozilla foundation and when you say JavaScript 2.0 to somebody from mozilla what they think you mean is a very specific version of the language as implemented by mozilla browsers. (ECMAScript 5) Why ECMAScript 4 was a failure EcmaScript 5 will form the language that is JavaScript that you will be using 5 or 10 years – not next year. Don’t break the web – preserve backwards compatibility for features that 3 out of 4 browsers currently support Brittle scripting language doing big jobs. Stigma of being 1 st language for a lot of developers. Interdependence with DOM, CSS, and HTML This is why the process unfolding with ECMA and standardization is so important to the language THE POINT of this history lesson is not just for fun or curiosity, but to illustrate that Javascript as a development platform has been evolving rapidly from a state of chaos to one that is organized and supports rapid development. If the development community were like a country, I might say that it has been evolving from something that resembles maybe a third world country where people are trying to live and do business but nobody gets along or trusts each other and all that and sortof managing, to a state that looks more like maybe the United states where people still don’t really trust each other exactly but there’s a lot more infrastructure and people don’t have to struggle as much with basic needs so they can focus on building things. And I think this is being driven by the desire to no longer rely on rock stars such as yourselves to get anything done so that we can focus on innovating. building
So where does that leave us? Really if you want to be employable as a web developer of any sort its hard to omit javascript from your skill set At the same time people do not have the interest or patience to become a javascript hacker, or become familiar with hundreds of obscure tricks and patterns in order to implement rich functionality across an array of browsers. This explains partly the huge interest in frameworks like Jquery, Dojo, and in even higher-level tools like Ruby on Rails, GWT, ASP.NET Ajax, and to a limited extent rapid prototyping tools like cappuccino and visual studio design mode.
So what are the things that make javascript hard? [zip through these things]
Talk about stages of a javascript developer
Talk about stages of a javascript developer
Historically the tools of a javascripter consisted of two basic components.. A text editor, or if you were really fancy an IDE like Visual Studio but also more likely Dreamweaver – something with code coloring and all that – AND a browser for testing. Some people still code this way, and that’s fine, but the result of which is that this is holding back the progress of web development as an industry and making developers a lot less efficient than they could be. What about Step-through debugging. What about variable watches, and what about testing. There’s been a lot of progress in this area and we are now beginning to get some really good tools like Firebug for firefox, and Fiddler for proxying, but there are lots of strings attached to these tools: Firebug only works with firefox, although there is a version being developed for chrome as I understand, Generally you use a different set of tools for each browser you test with. On the mac again you have another set of tools available to you. Instead of Fiddler you use Charles or something like that. still there is generally poor integration between all these tools. So you do a lot of switching back and forth. It’s a lot learn and pick up.. Particularly if you have nobody to help you.
The essence of this complaint is that the language and webpages in general do not lend themselves to elaborate modularization and abstraction of your code so it’s easy to maintain and share. So what you get are a lot of maintenance problems, regressions, etc. Spaghetti code. Advancing browsers. God help you if you’re developing javascript API’s for other people to use.
The essence of this complaint is that the language and webpages in general do not lend themselves to elaborate modularization and abstraction of your code so it’s easy to maintain and share. So what you get are a lot of maintenance problems, regressions, etc. Spaghetti code. Advancing browsers. God help you if you’re developing javascript API’s for other people to use. A lot of readily available resources from framework vendors like YUI, and Jquery, and of course adobe’s JavaScript framework Spry.
When you’ve got DW open click on the application bar and choose the extensions button. From here you can jump to Adobe Exchange where there are lots of what we call web widgets (more on that in a second) but also to the extension manager itself which is the place you go to install, and uninstall 3 rd party add ons to DW. One reason you might want to do this even if you are an experienced JS dev and don’t want prepackaged widgets on your site is to make use of some of the community provided API extensions for frameworks like Jquery and Prototype What are these. – code hinting, code coloring, code snippets Some of you who are famil. With VS, Eclipse, or past versions of DW know that these IDE’s have a limited a ability to introspect, or read the sourcecode of class libraries and whatnot to automatically provide code hinting (“intellisense”). With JavaScript, this can be somewhat difficult.
Some of the features of JavaScript that make it very appealing are also ones that make it tough to read. In particular there is the problem of documenting JavaScript libraries like Jquery for example that use techniques like ambiguous overloading and code generation as seen in the example here. (explain briefly what each of these are). Also note that this function doesn’t even specify its arguments. It uses the automatic arguments object to do a kind of forking in the code to do a kind of overloading. In the example there, there is really two functions, and what is the true API that the IDE should provide code hinting for.. Is it the on the two argument version of this, or the no-arg version. Then we have the additional problem that this example uses a kind of code generation to facilitate one of the compression schemes which are popular these days with javascript. Any introspection tool has to actually execute this code to see what the resulting API is. That’s why Adobe has provided a convenient way for not only partners like framework vendors to document their API’s but really anybody like you and me who wants to release some code, either internally to their organization or to world at large.
http://help.adobe.com/en_US/Dreamweaver/10.0_Extending/WS5b3ccc516d4fbf351e63e3d117f53d62b7-7fff.html When writing your own extensions you can provide your own CodeHints.xml file that elaborately defines both HTML entities and JavaScript API methods that use pattern matching to spawn suggestion menu’s.
Definitely point out that the capability to do this has been around for a while, but the community support and the quality of the extensions available have recently exploded. So in addition to code hinting or intellisense is the ability to provide convenient snippets or think of them as recipies for common tasks using the framework. Dreamweaver provides a number of these for general JavaScript coding already for stuff like string manipulation, preloading images and whatnot, and the Jquery and prototype libs do something similar.
Point out how useful this can be to developer producing widgets or behaviors that they want either other developers in the wild, or even other internal teammembers to use.
The essence of this complaint is that the language and webpages in general do not lend themselves to elaborate modularization and abstraction of your code so it’s easy to maintain and share. So what you get are a lot of maintenance problems, regressions, etc. Spaghetti code. Advancing browsers. God help you if you’re developing javascript API’s for other people to use.
The first three things are supported by Visual Studio studio directly. Profiling is something you can easily do in any of the browsers using plugins like the IE dev toolbar, firebug, or the built-in tools inside safari. Unit testing nice to have Part of the problem here may be that if you’ve ever looked at the webkit source code and compared it to say, firefox, or even the api provided by Internet explorer when you develop with it, you’re instantly shocked to find that it’s actually a very thin API with most of its features ‘stubbed in’. I’ve not spoken to any DW engineers but this may be slowing down progress a little.
Talk briefly about this failed project
Firebug lite
There are of course a lot of JavaScript frameworks serving a variety of audiences. Some are called “full stack” like DWR, GWT, or Nitobi or Infragistics, and others focus exclusively on JavaScript and what some people call “thin client” frameworks. Spry is one of these. Not a “ME too” copycat framework. Key differences that set it apart and make it really well suited for certain types of projects. Has a lightweight widget set that is extremely customizable with CSS http://labs.adobe.com/technologies/spry/samples/ Of course it supports ajax, and in fact has an extremely powerful set of tools for taking remote datasources and converting them into markup
Here’s another view of this data. This is probably an oversimplification of things. Certainly there are LOT of other features that give value to a framework, but to me, these would be among the building blocks. http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
First of all let me just say that I am not on the spry team and don’t have any investment one way or the other if you use it, so you can take this to be my honest opinion. Spry is immature: Its been around since CS3 and has had several substantial updates. A lot of work has clearly gone into dialing both the spry javascript library as well as the toolset for dreamweaver. Beginners: Spry uses a lot of advanced concepts in JavaScript like Xpath, datasets, observers and so-on that are not at all beginner concepts. The engineers that wrote spry are not beginners themselves and they’re of course aware of what other frameworks are doing.. Which leads me to my next point Your thought process around spry should not be “oh we have someone on the team who knows jquery, so we don’t have to use spry for this.”. Spry is not a 1:1 replacement for other frameworks and when you hold them side by side you see that there are clear advantages to one over the other, depending on your situation. I cant build x: spry is very modular. Its possible to take the things from it that you would like to use, possible the datasets or templating features, and mix and match with outside components or frameworks. Furthermore, its all just Javascript at the end of the day. If a framework gets you 80% of the way there on something, you fill in the balance with some of your own code and move on. Once you begin to understand the underlying mechanics of this framework you’ll see that there’s really very little you can’t do. Wall: like when a bird hits a window – I think that when people look at frameworks like Spry, they worry that while yes its easy to get a tabstrip on the page, once you begin getting feedback from a client you’re not going to be able to tweak or solve issues that come your way. Its all JS and with a moderate amount of skill you can customize to your heart’s content, just as you can with other frameworks. Last one: No Spry is just a JavaScript framework. There are tie-ins to dreamweaver that help you get off the ground faster but it is in no way necessary to be using DW to do this.
Spry isn’t for everyone. Just like Google Web Toolkit sometimes doesn’t even appeal to google developers writing ajax apps for google. Spry is ideal for teams that share responsibility for javascript coding across more than one person. Tight timelines: you can get a lot going with spry in a relatively short period of time. For most things you don’t really need to go outside the framework or to the community for widgets and whatnot. It’s pretty much all in the box.
Now we’re going to look at three of the more significant features of spry that might make it interesting to even heavy-duty web dev. Widgets, Effects & Observers HTML Datasets
There are a lot of spry widgets that come bundled with dreamweaver, and also ones you can download. The level of integration with dreamweaver in terms of their customizability and so-on is really something else. To illustrate, let’s go back to our contact form and insert a widget for validating a phone number.
http://livedocs.adobe.com/en_US/Spry/SDG/index.html?lang=en_US Most effects benefit from standard modifiers like duration and from and to iterators. Effects usually support a toggle of some kind so you can easily turn something on or off in a sense. Some effects have some pretty speciaiized modifiers: growCenter Growing and shrinking direction of the element. The default value is true (grow and shrink from center). If set to false, the element grows or shrinks from the top left corner. useCSSBox Modifies the border, margin and padding proportionally to the element’s inner content box. Default value is false. Observers are basically events that fire when certain conditions are met.. Most effects come with two observers: setup and finish Before effect start - onPreEffect Each step of the animation - onStep After effect end - onPostEffect Effect was cancelled - onCancel The chaining example would basically put the whole thing into a continuous recursive loop. Explain why.
Can even be used in the live preview mode of Dreamweaver Shows computed styles Unlike firebug it provides a very intuitive view of object properties, separating out the instance methods from other attributes. Explain why you might want to use this. Use cases
http://labs.adobe.com/technologies/spry/samples/ Spry Datasets are a great augment to just about any framework and can be used outside of the rest of the spry framework with jqeury or dojo
http://blogs.sanmathi.org/ashwin/2006/08/03/why-i-like-spry/ I was reading on a blog the other day about dojo presentation at Fidelity last year where they wanted to show people how to make better use of XML datasets with DOJO, and they used Spry to handle the data layer. Alternative to XmlStore in dojox Export data from Excel to XML - Put XML on webserver - Use Spry to create a dataset from the XML - Use Spry loops to read the data and conditionally print it to the screen http://www.dojotoolkit.org/forum/dojo-core-dojo-0-9/dojo-core-support/xml-dataset
These are somewhat typical, except for the bottom two. http://livedocs.adobe.com/en_US/Spry/SDG/index.html Paged View data set (or Spry Pager), is a data abstraction mechanism that provides paging capabilities for a standard data set. A nested data set derives its data from another data set, referred to as the parent or master data set.
imageDS is my dataset Point out that you do not have to use these special region types to take advantage of drill down or any of these xpath capabilities.