On 9/21/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 9/21/05, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > > I would like to hear what a component is. Definitions can differ. > > ... ... > below, I'll quote a couple of references that might be the beginnings of > research for your own investigations of the subject -- but this list should > by *no* means be assumed to be an exhaustive analysis of the available > information. Here, as everywhere else, Google is your friend :-).
Thanks, Craig. Actually, I already did some research on terminology about a month ago when I was preparing an article. I was looking mostly for definitions from Sun and Microsoft. > There is *lots* more information available to the casual web searcher ... > but the key factors that distinguish a component oriented approach should be > pretty clear. Note that this is not a binary world (you do *either* COP or > OOP), nor is one or the other the perfect answer for every problem. But my > experience recently has been that it is much easier to teach someone the > basics of "program by assembling components" versus "program by creating > object hierarchies" ... and the difference is dramatic enough that the > potential target market for a component oriented technology (simply measured > in the number of users who can grok how to use it well) is substantially > larger than the number of people who will understand a technology that is > built around elegant employment of object oriented design. Right. Composition, aggregation, drag-and-drop, run-time and design-time properties, property editors, interfaces, COM/VBX/ActiveX... Take Delphi or Visual Basic and get the picture. The concept itself is not new and is easy to understand and to use, no arguing with that. I guess everyone played with Erector or Lego in their childhood. > Does that mean COP is "better" than OOP? Don't be ridiculous ... the > question is totally meaningless unless you say better *for what*. I did not want to start argument about what is better. I did not want to argue at all :-) I simply wanted to point out that components (well, sort of, if you squint) can be created in Struts Classic too. And that ASP.NET component approach relies on massive IDE and backend support. I wonder how to encapsulate one component into another with JSF or ASP.NET. Visual tools help to drag the component on the screen in an IDE, but how a JSF page would look like? The same old tags inside tags? Or different? When AmiPro 3.0 allowed to put a table inside a table, this was considered a huge achievement ;-) On the other hand, how many people used it? Struts Classic is still "good enough" for me, but I would agree that writing Struts apps is kinda like coding HTML in a Notepad. The result can be good but takes quite some time. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
