At 07:37 22/4/01 +0200, Leo Simons wrote:
>> >We have yet to define _explicit_ contracts for many parts of
>> >the framework. We currently provide default implementations
>> >of some parts of the framework (DefaultContext), and not for
>> >other parts.
>>
>> Which other parts don't we do.
>
>Some stuff to choose:
>
>- Factories / utility classes for everything, Factory / utility
>outside the framework and integral static methods outside, or all
>functionality within classes.
This was what I wanted to do ages ago. Namely create Factories and have
Mutable* versions of all the objects .... however I couldn't come up with a
good enough reason to warrant that. (And thus the move was vetoed;]).
>- contexts are built by writing to DefaultContext. This means
>people with access to DefaultContext can make them writable
>again (simple cast). Not good for security; the configuration
>way is better (my personal preference would be an anonymous
>inner class inside a factory cast to an interface, but hey =).
Same with config and cm - and any services passed in CM. Automagically
generating proxies is the only way to do it safely.
>There is more (real shame I lost my list...). Like not all interface
>methods taking the correct argument (some upcast too much, some
>downcast). You may have fixed this in the last few weeks (I'd have
>to check =), but there are some things.
I was told to not sub-class to get type safety so I have been gradually
making it a requirement to cast things based on expectation. Other things
(like casting hints to configuration in cornerstone.blocks.masterstore) I
don't like but hey - we can't everything right ;)
>I'll go and hammer nails into excalibur and avalon if you are
>finished there for now (are you?).
slowwed - never finito ;)
>> >This leads to some unclarity of what is the framework, and what
>> >isn't.
>>
>> Easy if it has to do with any of the following it is definetly framework
>> * lifecycle relationship (ie activity, logging, context, CM, config)
>> * container-component relationship (ie camelot)
>> * kernel-app-component relationships (ie atlantis)
>
>=) That's still an "has to do with any of the following" which again
>leads to unclarity. It is not that I can't see what is framework and
>what isn't (heck I've been staring at 3 different setups the last few
>weeks =), it's that it may not be clear to outsiders.
Sounds like a damn good arguement for havin a separate CVS under namespace
org.apache.framework ;)
>> In neuroscience I would call this "form" functions. This contrasts with
>> "content" functions such as
>
>Now we're getting somewhere. "The Avalon framework consists of interfaces
>that define relationships between commonly used application components,
>form functions, best-of-practice pattern enforcements, and several
>lightweight convenience implementations of the generic components.
>
>We also provide Excalibur, which provides content functions and other
>commonly used utilities to simplify and speed up the development of
>Avalon-based applications."
>
>Something like that.
sounds good to me - want to update the docs ;)
>> Just because it also includes a DefaultTableRenderer when you may want to
>> write your own does not devalue it's structure.
>
>Uhm, yes it does. If I want to write a swing-based mobile phone app and
>remove all the fancy controls, that's a lot of work. It'd be less work
>if I'd have two trees/jars.
If you were to be writing to a mobile app then the other interfaces would
also need to be stripped out. Luckily there is tools that do the stripping
for you ;) (I think someone even submitted one to ant a while back).
>> >> thankfully we have just moved away from that model - it was unanimous
>> >> decision so you should check archives for reasoning ;)
>> >
>> >did so. My answer would be "ant" to every problem mentioned =)
>>
>> Right - but by your logic we should include all jakarta projects
>> in one CVS
>> right? (or maybe all java apache projects - or perhaps the whole jdk ;]).
>
>It is all a question of granularity. Most projects have one CVS
>(some have one for old and one for new versions). We have no less
>than 5.
>By my logic each project has its own (single) CVS =)
true but we are moving away from that model. Turbine recently split, ant
split, in time I assume commons will split etc.
>Paul Hammant wrote:
>> Also, I'll bet you we lost subscribers to the mail lists when we
>> switched from java.apache.org to
>> jakarta.apache.org as we're now spammed by CVS messages in the
>> *same* list.
>
>you almost lost me =) I'd still like to see this changed if possible...
I am indifferent to it ... but if you want it changed you can always
propose a vote ;)
>> Proposal 1) June 15th : Switch to beta
>
>+/-0.5
>
>> Proposal 2) Formal release : August 1st
>
>+/-0.5. I hate dates like this when we don't even have something of
>a release plan. We cannot say when something is finished if we don't
>know what it has to be.
Phoenix will be suitable enough IMHO when we have management and good
logging. We almost have management thanks to you after that I will do
logging as soon as I have time. Then we may be closer to being ready.
The framework will be ready when it is decoupled from the components.
I doubt components as a whole will ever be *ready* as such - maybe
individual ones will be though ;)
Cornerstone/logkit/testlet is ready enough now.
>Come up with a more detailed plan and I'll support this.
When the above is achieved then I will do all the work required to put
together a release but until ... ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
