avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT][merlin][cocoon] blocks, auto-assembly, versioning
Date Thu, 17 Apr 2003 20:54:21 GMT
Stefano Mazzocchi wrote:
> Happy to see my RT picked up.
>>Inheritance already available in java
>>Stefano's bullet point number three is inheritance, where a block 
>>identified by a URL extends another block identified by some other URL. 
>>This is both potentially complicated to implement, and already 
>>implemented perfectly well with standard java inheritance. 
> As all avaloners so far, you fail to see that CoP approaches can be
> applied to things that are not, strictly speaking, code.
> Let me give you an example: suppose you have two jars
>  a.jar
>   +- foo.xml
>   +- bar.xml
>   +- images
>         +- logo.gif
>  b.jar
>   +- foo.xml
>   +- bar.xml
>   +- images
>         +- logo.gif
> you will note that the above two jars share one thing: the internal file
> layout.
> Now, suppose that you plug these jars into a system that expects this
> file system layout. This is the *contract* between the component and the
> system. This is a 'non code' interface.
> The above is polymorphic: I can plug in different modules and, as long
> as the file system layout and the file schemas are the same, everything
> is fine.


> But with this kind of inheritance, you have one *huge* feature: having
> b.jar extend a.jar means that all changes to a.jar are *transparently*
> reflected to everything that b.jar doesn't overwrite explicitly.
> This is only an example on how the same concept of polymorphic
> inheritance can be applied to many more things than simply code, in this
> case a file system.

I agree.  The D-Haven GUIApp framework has the same needs.  I think one
thing that has not been addressed here is i18n and l10n needs.  The
needs of a translater are somewhat opposed to the needs of a developer
in some senses.  For example, the way ResourceBundles work, they are
loaded into memory based on a classloader resource or the filesystem,
or some other method.

The thing is that translaters need all the lookup keys in one location
to make it easier for them to do their job.  In fact, I would like us
to address this issue as well.

In a componentized environment it is easier for developers to have a
unique Resource in for each component, each package, or even each JAR.
In GUIApp, I have the ResourceBundle unique to the JAR level, but I
am finding it is sub-optimal.

I would like my blocks and applications to inherit translations from
the core JAR and augment with only those things that are truly unique
to a block.  Currently getting this to work is somewhat troublesome,
esp. when some static utility methods need access to the resource
bundles as well.

>>has its use in COP, and I really don't understand why a different 
>>mechanism is neccessary.
> Because java inheritance just deals with code, we also need to apply the
> same concepts to others things like xml files, images and all types of
> resources that cocoon blocks will carry along.

And all Avalon blocks should address i18n/l10n issues as automatically
as possible, making it as easy for translators as possible.  This is
one area where inheritance of Block resources will work.

> Supposing that a work interface can remain the same forever is utterly
> utopistic. By providing revisions and the ability to have several
> different instances in the same environment, we allow an easy and
> smoother evolutionary path for both implementations and abstractions.

I think the reasons that Peter doesn't like versioning work interfaces
is partly because Java fights you every step of the way in doing that.
It is not easy to version interfaces without proper metadata in the
interface itself.

Also, when you significantly change a work interface, it may function
in the same "role", but it is essentially a new component.

> In order to scale and pass the test of reality, a CoP system must
> implement effective versioning for everything that can be used as a
> contract between two subsystems. This includes:
>  1) the block implementation
>  2) the block abstraction
> So, personally, I don't see the single interface to be versioned, but
> rather the URI that identifies the block that contains the interface.
> So, when we do
>  componentManager(Repository.ROLE)


>>Compatible with cocoon blocks needs?
> cocoon blocks extend avalon blocks. I'd be very happy to be able to
> reuse as much as possible from anything that avalon will provide, but,
> at least personally, I will not sacrifice the ability to do stuff like
> block-level inheritance because this is simply too important for the
> cocoon realm.
> At the same time, knowing how much harm cocoon has done on avalon, I'm
> ready to roll my own implementation if the cocoon block needs remind too
> far from avalon's.

Cocoon represents some real world needs, as does the D-Haven GUIApp
framework.  As much as possible, I would like to work with the Cocoon
and Avalon teams to come up with something workable for at least *most*
of the solution.

>>I also removed the concept of a "behaviour URI" from cocoon blocks, as 
>>behaviour is already specified by a work interface, and a work interface 
>>is already identified by a role.
> The behavior of a cocoon block is identified by:
>  a) the dynamic resources it provides (described in the sitemap)
>  b) the static resources it provides (described by their layout and
> their schemas/binary formats)
>  c) the avalon components it provides (described by their interfaces)
> NOTE: there is no general consensus on the need of both a) and b) as
> some would like to unify all resources as given by the sitemap only
> A cocoon block behavior *must* have at least one of the above, but it
> could well have all three!
> I agree that, in case the block specifies only c), this falls back in
> being a normal avalon block, but even in that case, it could contain
> several different components and thus there is the need to identify the
> behavior of *all of them together* and version that which can't be done
> at the simple classname level.
> This shows pretty evidently why I think that a cocoon block extens an
> avalon block.

Which is perfectly valid.  What is important is that the Avalon block
be extendable in a predictable way.

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message