> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > > Berin Loritsch wrote: > >>Your definition of Component is too flimsy. > >>Give me a set of rules, and let's stick to that. > > > > > > I could write a book on the subject (oh, yeah...). > > > > Let's just say that I am not going to put 20+ > > pages of spoilers on the list. You'll just have to > > be patient. What I gave you is what the component > > community can agree upon. > > Which is nothing ;-) > > Seriously, what about Cocoon using Serializers, Transformers, > etc as Components. Aren't they "information"?
No. The XML or SAX stream is the information. They represent different stages of how to create or manipulate that information. They also provide a nice abstraction so that you can easily understand how they relate to each other. > You wrote: > > Again, you have to have the proper abstraction. > > In this case, > > the Socket itself is the *wrong* abstraction. > > The container > > should not make up for your poor design habits. > > I this Berin or Peter Donald :-? I am in the process of refactoring software that was clearly not designed. It mixes OO and procedural concepts providing an incomprehensible mush. I *really* hate bad/no design. > Ok, se let's call it MyAbstractConnectionEndpoint. > And have Socket, MYSocket, WoolThreadEndpoint implement it. > > Would it be a Component, given the above premises? > > I think there is something plain confusing in all this. :) It would satisfy the technical requirements for being a component. But what does it do? Think of your system as a play. You have actors that perform. They have a set script, contracts so to speak. Whether it is Mel Gibson or Mark Hammel (I prefer Mel) playing Hamlet, the performance goes through the same mechanical aspects of the script. The performance is quite different, but the end effect is the same. Remember that actors interact with their surroundings. Unless you are watching mime or some avante guard neo classical crap they interact with props. Props can be just as important as the actor, esp. in murder mysteries. Try to break down your components like you would have actors tell a story. The story in this case is what your system does. If you want your system to be like a Saturday morning cartoon, then having animated props (like a talking blanket) is appropriate. However, don't complain to me if your Saturday morning cartoon doesn't scale up to the big screen. That is the general rule of thumb, and why we refer to components by their "Role". -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
