Marcus Crafter wrote:
In the documentation of that block behavior.>Eh, that would be nice indeed, but the block interface is *JUST* a URI. >Nothing more. There is no contract descriptor and this paragraph >explains exactly why: because it would be too difficult to know where to >stop describing the contract!hmm.. perhaps I missed something then. If I want to write a block that implements a particular interface (eg. myskin block which implements the skin block interface) where is that interface described ?
Consider this: a java compiler checks for method signatures to be compatible with the class that implements an interface. Great. But there is no validation on whether or not the class implements this interface *correctly*, that information is included in the javadocs and it's by run-time tests that you really find out if two classes the implement the same contract behave the same. There is no way to tell at compile time.
For blocks we have the same problem: how can we describe a URI space? how can we know how a particular service works? staring with HTTP actions, parameters, session, cookies. Can you imagine the complexity of a descriptor file for such a thing? It's WSDL++++ and WSDL is a nightmare already.
That's why I proposed we ignore the issue alltogether and just write in documentation what we need.
I know it sucks and I know people will soon forget to document and things might fall apart without tools enforcing practices, but hey, I really don't know how we can solve this.
If you have ideas I'm all ears.
I would need to know what services are exposed so that my implementation is complete - and I thought perhaps we could have a tool that generates a skeleton block implementation based on the description of these services. >> It would be great if there was some synergy between Avalon & Cocoon >> to develop/improve one/both of these containers to be suitable for >> use in Cocoon, rather than implement our own. >> > >I think everybody agrees here. I also think it would be great to count >also Phoenix into that, althought I'm not sure on the issues there. >Peter, what do you think? Including Phoenix would be fine with me - I'm not as familiar with it as the other containers and will have to dig a bit deeper there - over to you Peter :) >> Merlin offers better support for the meta-info approach to >> managing components and container hierarchies, whereas Fortress >> offers >> better ECM style compatibility. Both don't yet handle package >> level dependancies but I don't see any problems adding that. >> >> The choice of container is important though as a lot of what you >> describe could be container concerns rather than application >> concerns >> (eg. package validation, versioning, classloader management, etc). >> > >I'm fully aware of that. > > >> Having most of that at the container level makes it much easier >> for Cocoon which would then become the essential core, blocks, >> and perhaps any required container extensions, etc. >> >> This is where 2.1 has suffered IMO, as the 2.1 codebase includes >> features that IMO should really be handled at the container level >> (eg. extra avalon lifecycles, configuration file monitoring, >> sitemap/subsitap -> container hierarchy management, etc). >> >> Perhaps we need to investigate a bit deeper into what the >> container should do for us. This will allow selection of which >> container to be a bit easier. >> > >Easy here. The difference between Avalon and Cocoon is that Cocoon has a >bigger and more focused community. Avalon framework is great. But >everything else, well, it's fragmented like hell. It's mostly a tons of >one-man shows. I hate that. > >Until this situations remains, I don't feel confortable with moving more >stuff over to Avalon even if this makes sense architecturally. > >Please understand that 'much easier' highly depends on the POV: Oh, no offense intended there, I see your point regarding the current situation Avalon is in. What I wrote above was just based purely on my looking through the current 2.1 codebase and my understanding of the newer Avalon containers. Nothing negative intended there. In fact, a lot of newer features implemented in these newer Avalon containers can probably be accredited to developments in Cocoon. My point (which I'm sure you're fully aware of) was more to outline that container migration could result in us decreasing parts of the core codebase because many things we've implemented in 2.1 that essentially extend ECM are natively available at the container level - if possible, and where it makes sense, I hope we can capitalize on that. >> Once I get our admin app up and running here at the bank I'd be >> happy to look deeper into this. > >Great! That would be *very* helpful! No problem. Once I get this admin app up and going (soon) I'll take a look at it. Cheers, Marcus
-- Stefano Mazzocchi <[EMAIL PROTECTED]> -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
