Hi,

Here's a summary of next round of changes coming into CVS.

Again, the primary goal was to try and isolate the services so
that they can be built as a separate entity. This is still not
completely possible because all the services have not been
separated.

The two services that I have worked on are the

1) UploadService
2) DatabaseService

I have decoupled the UploadService from Turbine. Basically what this
entails is simply removing refereneces to ParameterParser in the
service. Instead of passing in a PP to the parseRequest method
and having the method directly manipuate that PP object, the parseRequest
method takes the request, parses it and returns an ArrayList of FileItems.
All the necessary classes have been modified, but user code will have
to change one import statement. I could find no way around this given
the coupling of the code. This class has been deprecated in the 2.1 release
so I don't see it as a problem, and if someone sees a way to make it
100% backward compatible than they can do so. The UploadService in its
new form would be usable by any webapp framework. Hopefully the services
when separated will be useful to a much larger audience.

There are a lot of changes with the database related code/system/processes
because everything is so highly coupled. Everything is still highly
coupled but the changes have almost made the service cleanly usable
outside of the context of Turbine.

What we really have is a PersistenceService of persistence layer because
all of the classes are so bound to each other. The first thing I did was
group all of these classes together because none of it works in isolation
and the sprinkling of all these classes all over the tree makes the overall
pattern difficult to discern.

Everything to do with persistence is now grouped under the service with
a view (in the very near future, as in days) of separating Torque from
the set of classes we now call the DatabaseService. So a lot of classes
have moved and I have only replaced a few classes with proxies because
all you have to do it regenerate the object model with torque. All the
templates have been changed to match the changes in location of all the
classes. I don't see this as a standard deprecation issue because the
majority of these classes are only used by Torque. The only classes I
left in their original positions are Criteria (with a proxy) and the
TurbineMapBuilder classes. The first is used in client code everywhere, the
second is currently required by the security services.

I know this is somewhat of a radical change, but I think it's
a path that will allow us to fully separate the services and Torque.

I think we need to decide what Torque is. I see it as a persistence
layer. So maybe we make it a fully functional tool with what we
have that will work for many people and write a small adapter
to make Torque or DatabaseService or PersistenceService.

I think we also need an overall fa�ade for access to everything
Torque provides, hiding things like Criteria and if possible adding
standard querying with OQL.

I'm going to start pushing in the changes now. There are a few more
services to decouple and I will continue to try and make the partitioning
clear with documentation and lots of comments. I have lots of //!!
comments in a lot of places expressing concerns.

Just so it is clear, I plan to keep going and intend to work on
Turbine, the TDK, Torque and services for the next three months
almost exclusively in conjunction with writing the book. So between
the book and working on turbine related goodies it will probably be
somewhere on the order of 60 hours a week toward turbine.

When the cleanup is done I hope there is a lot of discussion as
to future improvements. There have still been no functional changes
in the code, all I have done so far is try to separate everything
cleanly. But when the discussions have taken place I definitely have
the time and I would like to volunteer to coordinate the effort
toward 2.2 (or maybe 3.0 it should be called with all possible changes).

When the services and torque are separated from turbine proper I
think will be in excellent shape to discuss the future of
turbine :-)

So, the changes are coming in now. I will work with anyone trying
to stay in sync with HEAD if I have inadvertently caused anyone
any grief.

-- 

jvz.

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to