Stefano Mazzocchi wrote: > Hunsberger, Peter wrote: >> Stefano Mazzocchi wrote:
>> I don't think I will! However, when doing architecture you always >> have to ask if inverting a control flow makes sense; sometimes >> abstractions suddenly become obvious or new use cases jump out. > > Oh totally. That's why I take time replying to your messages even if > they might sound too "devil's advocate"-ish to many here. ;-) Who moi? Never... ;-) I guess there are two things that drive me to spend the time worrying about how the Cocoon architecture will shake out in the long run: 1) Our commitment to using Cocoon. Even though we're pretty careful to use only standard XSLT it would still take a lot of work to rebuild our application as a normal Servlet. We've got working code that doesn't use Cocoon but it would be a lot of work to extend it to do all the things that the Cocoon version does and it's likely that the subsequent maintenance costs would also be high. 2) A general interest in data driven architectures. I think this makes us somewhat different than much of the regular Cocoon community (which is probably much more procedural logic driven). As such, it's worth while spending time trying to determine if and how much the two sets of requirements can merge. To many people the whole idea of data driven architectures is so foreign that they immediately think that they can't scale; but ultimately computing is computing and all logic is data, it's just the algorithms that exploit the data that differ, so I do hold out some hope that our requirements can fit with the rest of the Cocoon communities. >> If one was to do such a thing >> with the Cocoon sitemap obviously you'd have to allow the current >> semantics to continue to work so you'd introduce some complete new >> concept (what's the inversion of a pipeline?...) > > Not only that. Everytime you add a new construct you are not adding just > *one*, but you are adding all possible combinations of that construct > with everything that was there already. > > This is why I'm always *very* careful about adding new functionality. Well, I don't think it's always N! combinations: there are restrictions on which components can be used with other components. But I understand your concern, in particular since when you invert a control flow what was formally a many to one mapping now may become a one to many mapping (but also the reverse may happen, which is one reason why you look at it in the first place). <snip.../> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
