Peter, >>>>>>1) Merlin includes phoenix-client.jar and provides alternate >>>>>>implemetations of the BlockContext interface. >>>>>> >>>>>> >>>>>Thats the only real solution at this stage. >>>>> >>>>> >>>>There could be some reason why that is not possible. >>>> >>>> >>>It will become a lot more difficult in the future when classLoader and >>>interceptor stuff get integrated but it should be possible to no-op those >>>features - not sure. >>> >>> >>Well let's tackle future features in the future. For now though I think >>that useing a Phoenix jar to be Phoenix compatible is perfectly possible. >> >> > >I am not sure what you are saying. If you want to implement BlockContext then >that is fine but the implementation is inherently container specific. The >implementation should not even be in the same classloader as the interface. > >Look at the Servlet/EJB/other APIs. They all follow this pattern and I believe >some (servlet API 2.1+) actually mandates that no container specific classes >can be in same classloader. > >And we don't want to limit our evolution in future for so little a gain as >having a generic implementation. It is rare that the implementations are more >than 20-30 lines of code, so I am not sure what the great technical >difficulty is. > Err I agree with you Peter. The interface iremains in phoenix-client.jar and the impl is left to the container in question. I think Stephen is comping round to the possibility of that fact.
>>>>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. Thats where I want a lot of avalon stuff to >go in the future. It is a brilliant concept when used appropriately. > > That's what everyone is saying. Expect .Net inspired atributes to arrive in Java3. >Essentially every component/service/object is handled identically. The magic >comes from the metadata that is stored along with the object. > >In avalon terms this means marking each method/class with xdoclet attributes. >We could mark a method with "avalon.remote=true". > Same as .Net. Cool. For us it is xdoclet today with a concrete impl for Java3. >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. > >The way the object is treated is essentially a combination of; >* the extra metadata it encodes >* the metadata that the container supports > >So you could add transaction, persistence, security, remoting, replication, >pooling, <insert favourite aspect here> etc with a few metadata entries. > >While the above is largely talking about "service" orientated attributes, it >can also be used in Model Driven development. For example, my latest contract >is basically a frontend to a non-j2ee distributed management system (jsp, >struts, taglibs, sitemesh, etc). In it, each buisness object is represented >on multiple layers; >* as a struts form object >* as a commons/struts DynaBean (mainly for auxilliary tag libraries) >* as a client-server Data Transfer Object (DTO) >* as a DAO >* as a inter-server DTO >* as XML readers/writers >etc. > >Each BusObj also has a whole host of UI arterfacts and screens (table views, >editing forms, version history etc). > >Trying to develope all this code using traditional processes was scheduled at >about 8 months work. We had just under 2 months :) > >So what I did was essentially describe the object model in xml like > ><object name="nzUser" > display-name="User" > validator="com.biz.UserValidator" > view-rank="3"> > <property name="username" > type="String" > key-part="true"/> > <property name="pent_id" > type="Integer" > immutable="true" > dto="none" > hidden="true"/> > <property name="password" > type="Password"/> > ... > etc > ... > <relationship to="Role" via="username"/> ></object> > >So each object contains >* a set of object attributes >* a set of propertys >* a set of relationships > >Each property contains >* a name >* a type >* a set of property attributes > >Each relationship contains >* a destination schema >* optionally a via and multiplicity >* a set of property attributes > >In each case the attributes are the magic interpted by an appropriate >"engine". ie I end up having only about 18 jsps (thank god!), rather than >120+. Which attributes are editable, immutable, displayed and so forth is all >defined by their metadata rather than by any harcoding. > >The struts/taglib portion only deals with attributes it knows about, while the >DTO builders only deal with attributes they know about, while the database >layer only deals with attributes it knows about. > >Anyways it has made it possible for us to get the majority of GUI, >persistence, distribution and all the rest of the "grunt" programming out of >the way in 2 weeks! Now all we have to do is the actual buisness logic, 8 >months be damned ;) > >You will notice that this is the same approach that a lot of new toolkits are >heading. Especially a lot of new toolkits that describe the model in UML + >magic attributes (are they called tags in UML?) and allow you to generate a >whole application setup (though most use icky code generation). This is a >partially a result of the difficulty of J2EE and the need to move between 2 >tier and multi-tier dev platforms. > >Anyways thats my latest kick. If you are familiar with torque, it sort of does >the model driven approach for one aspect of program (persistence and data >migration). It uses code generation because it only covers once aspect but it >is still great. > >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). > >Can you imagine the ease of this if we ever achieved it? >* Service Orientated Programming + Attribute driven framework >* Model Driven development + Attribute driven framework > >I think the above is largely achievable (even if not in a a completely generic >fashion for MDD). > >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. > >Anyways I believe I be gushing ;) > > Sigh, will this commercial effort ever be open-sourced? - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
