> > >>Personally I like this solution best. Why? I have beans with EOB, and if > > >>I get back to it Jesktop-applets that could also be contextualizable. > > >> JAMES has maillets and one day newslets. FtpServer might one day have > > >>FtpLets. If all these were Contextualizable woulldn't it be nice is one > > >>Component could run in multiple containers, and adapt its duties to that > > >>container. For example a single comp that was both a Mailet and a > > >>EOB-Bean. Maybe I'm guilty of dreaming up something that has no proven > > >>need. > > > > > >It is a goal and thats what I am moving towards with the ContainerKit > > > stuff. > > > > Bllimey, I thought'd you'd shoot that down as inpossible dream ;-) > > Naah :) > > Have a look at Microsofts "attribute-driven" programming style that is part of > dot net. I have not looked at implementation details mainly just > research+white papers about it.
me too (still waiting on books...damned amazon ;) > Thats where I want a lot of avalon stuff to > go in the future. It is a brilliant concept when used appropriately. definately. The single good bit of VB (as in Visual Basic, not Victoria Bitter...I miss Oz :) extracted out ;) > In avalon terms this means marking each method/class with xdoclet attributes. > We could mark a method with "avalon.remote=true". This would indicate to the > container that it is capable of being remoted via altrmi, soap, rmi or > whatever. We could also look for other attributes like "avalon.stateless", > "avalon.multiclient" and "avalon.threadsafe". Depending on the values of > these attributes, the component could be equivelent to stateless session > bean, or stateful session bean, a remoted singleton or whatever. hmm. This is implementation stuff, I guess, but I like using XML for metadata. It fits well. > While the above is largely talking about "service" orientated attributes, it > can also be used in Model Driven development. you know what I'd like to see? One of the avalon architecture gurus (you know who you are) writing a paper on how avalon relates to/facilitates MDD... > Anyways thats one of the very very attractive ideas I want to explore in the > next year or two with avalon stuff. (Or at least the service side of > attribute driven dev). I'd like to see all that...but I'm also considering the fact that we might end up coding to .net...so am looking at ways to steal ideas from that rather than doing it ourselves...but I guess that's the attitude of most people around here? > If someone was to come up with a decent process/workflow system (I haven't > ever seen anything that is vaguely close to being viable) then it would make > development soooooooooo much easier - essentially just coding in buisness > rules and maybe engines to interpret the model. maybe in 20 years or so....imagine the terribly high programmer unemployment rate that results though ;) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
