PHP: Not being a snob GMail released to all. Now time for IMAP? :)
Feb 18

The case for high level components

Ruby, Tech, Web Frameworks Add comments

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

One Response to “The case for high level components”

  1. Michal Says:

    Components make sense everywhere. If in some domain they are not seen as something useful -
    this is just a sign of immaturity of that domain rather then something to be proud of.

    IMO the question “what should be generized, what shouldn’t” does not make much sense.

    The most common mistake which people make when they think about components is when they think that they are for resubality and therefore they are trying to write “swiss army knife” components which can solve all their problems.

    This works bad in practice. For our cars we have summer and winter tires, which are just much better then all-season tires.
    And we are prepared that we will have to change tires every 60 000 KM.
    So in place of trying to make something which works in every possible situation – it is just better to make highly specialized things which are going to solve well our current problem. But to make them in the way which will make changes in the future simpler.

    So components are not about reusing the same thing all over again, but about having possibility of replacing this thing with something else when it is needed. This does not imply that we have to replace with something better or newer -
    during winter winter tires are the best, during summer they are not and vice versa.

    But the main reason why we want to replace is that technology and standards are constantly changing.

    Michal

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: What are the first four letters in the word British?

Feb 18

The case for high level components

Ruby, Tech, Web Frameworks Add comments

David Hannson, of Rails fame, writes a case against high-level components.

Although we have definitely seen components NOT be successful in areas such as EJB (yeah, we can buy SO many vertical components), the web tier (apart from the displaytag ;), I don’t think we should write off components in general.

There are many places where components make sense. They make sense in GUI development. Tapestry components work out great. In my experience, it depends on the contract and what you are trying to do. There are some items which you really don’t need to tweak much, and if you do, it is there for you. However, it is hard to have ONE reusable component for “new WebCommunity().start()”.

It is an art to choose what should be generized, what shouldn’t, and how to give enough hooks to allow you to tweak the component.

One Response to “The case for high level components”

  1. Michal Says:

    Components make sense everywhere. If in some domain they are not seen as something useful -
    this is just a sign of immaturity of that domain rather then something to be proud of.

    IMO the question “what should be generized, what shouldn’t” does not make much sense.

    The most common mistake which people make when they think about components is when they think that they are for resubality and therefore they are trying to write “swiss army knife” components which can solve all their problems.

    This works bad in practice. For our cars we have summer and winter tires, which are just much better then all-season tires.
    And we are prepared that we will have to change tires every 60 000 KM.
    So in place of trying to make something which works in every possible situation – it is just better to make highly specialized things which are going to solve well our current problem. But to make them in the way which will make changes in the future simpler.

    So components are not about reusing the same thing all over again, but about having possibility of replacing this thing with something else when it is needed. This does not imply that we have to replace with something better or newer -
    during winter winter tires are the best, during summer they are not and vice versa.

    But the main reason why we want to replace is that technology and standards are constantly changing.

    Michal

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'