The Edge : DRK : The Secret of Developing Components

The new EDGE newsletter is out and among other things has an article about the DevNet Resource Kits (DRK), and the development process and steps behind the components on the DRK.

You can read the article here.

[via greg burch]

14 Responses to The Edge : DRK : The Secret of Developing Components

  1. zeh says:

    Just an offtopic comment regarding the right-hand column of the main page.Advance Wars for the GBA is teh bizomb.But it’s not “Advanced”.:)

  2. Phillip R. Cargo says:

    I was hoping to read about how they made sure all the components are extendable.FRichTextEditorClass has some problems in this department, I suspect because it attaches the Class to _global for reasons which I do not understand ….

  3. That EDGE newsletter implies that Macromedia made components are bug free. Or, at least, that some people are hacks and you don’t want to use their components. I resent that implication for two reasons: no programmer is perfect, therefore MM components sometimes have bugs; and, other components are not necessarily buggy. Saying “With so many third-party components and extensions, it’s hard to separate the good from the buggy.” is not really fair–I don’t think.Thanks,Phillip

  4. Greg Burch says:

    Phillip I haven’t looked but I bet the problem is that it has author time assets. To make sure the code is extensible this is on of the main things that should be avoided. All assets should be attached. When I make components I keep this in consideration. Also I make it normal practice to extend the component (if even just a little bit) as a test. On DRK3 you will see that most of the sample files extend the component in some way.

  5. Greg Burch says:

    Hey Phillip,Reading the writers comments I don’t think they were saying “Macromedia’s components are bug free and third party components are buggy” but I think it was the opneing to the article. The article outlined some of what macromedia does to try and make stable components, where-as with third party components (and macromedia’s) you can never be sure until you use them. So this article is meant to explain what Macromedia does to try and set their components apart from others. It probably could have been worded differently but I don’t think the author meant to sound as if to bash third-party components.

  6. The article does use the phrase “bad news” to describe using third-party components. Yes, it probably should have been worded differently if they didn’t mean to bash third-party components.

  7. mike chambers says:

    Here is the exact quote:”First, the good news. Macromedia Flash, Dreamweaver, and ColdFusion are eminently extensible, which means that a slew of creative components can help you increase product functionality and expand the ways you develop web applications. Now, the bad news. With so many third-party components and extensions, it’s hard to separate the good from the buggy.”That is a true statement. In most cases, when using third party components, you have no idea about the quality of them before you use them. You don’t know if they are documented, have been QAed, or if they are even complete.That is not bad mouthing third party components at all.mike

  8. Doug says:

    still waiting for the “secret”… spec->dev->QA->beta seems pretty normal to me. This is a promo piece rather than a tech article I guess.

  9. We can argue about what the author meant, but I definitely inferred the point that MM components are supposed to be good and third-part components bad. In fact, the MM are designed well, tested, and documented. (I do wonder why many don’t use updateAfterEvent() to smooth movement–but that’s a different story.)Anyway, my suggestion is only that such slants in articles be considered. Not everyone will have the same reaction as me–I can accept that. But I’ll bet I’m not the only one who read it that way. With all the effort you all made to create great components, I’ll bet you’d rather not present them as bug free.

  10. Jphn Dowdell says:

    One of the things that surprised me in the Exchange was how the Macromedia badges increased download rates… what I came to realize that there are both discovery and evaluation costs in evaluating resources:– it can be hard to find something which seems to do what you want– then it can be hard to figure out if it really does what you want, or if there’s some better path to the same goalI agree that company-labelling doesn’t mean something is perfect or unimprovable, but what I came to realize was that it was useful for large numbers of people to realize that the company stands behind a particular resource, and is willing to bet part of its reputation on that piece.I can understand that “it’s hard to separate” part on these grounds. (And Phillip, you already know how painfully subjective I find that term “buggy”… people will still use it to describe things they don’t like, though.)

  11. I wasn’t aware there were badges given for stuff on the exchange… Sheesh, if you read the disclaimer when you install ANY components (via extension manager) you’d think a virus that clears your disk was possible. Okay, I know that’s just the lawyer’s going wild.Thanks,Phillip

  12. 1stpixel says:

    Ok this might be crosspost but as i read here about QA, and how this should ensure there’s no major bug in a component, how comes, that there’s such a simple bug possible:Color Picker Component in the DRK 2:put an instance of it on Stage (Stage.width = 320, Stage.height = 240).position it horizontally in the middle and vertically at the bottom.test it. See ?Solution:add 1 line to the function “layout”:(this.popUpPane._xI wonder how this has come through QA ???1stpixel

  13. Greg Burch says:

    My comments were geared toward DRK3 everything has been QA’ed in the past but I know for a fact things were put in a higher gear for drk3.

  14. 1stpixel says:

    I haven’t bought this one (DEVNET-subscription), cause the ones before were too ‘buggy’, needless for me or there have been opensource alternatives, … or did my own.1stpixel