Hi,
On Sun, 25 Aug 2002 19:01, Paul Hammant wrote:
> >>>>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.
> >>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.
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". 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 ;)
--
Cheers,
Peter Donald
-----------------------------------------------
"Only two things are infinite, the universe and
human stupidity, and I'm not sure about the
former." -Albert Einstein
-----------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
