If you don't want to read such words, please use a Killfile.
X-Copyright: (C) 1996-2002 Henning Schmiedehausen
X-No-Archive: yes
X-Newsreader: NN version 6.5.1 (NOV)
Jason van Zyl <[EMAIL PROTECTED]> writes:
>Hi,
>All users that have responded on the list want to wait for the decoupled
>versions of torque and fulcrum to be available for use in 2.x before we
>release. We have discussed this briefly in IRC but how about the following
>for a plan.
Hm,
I pulled some changes from the 2.2 code because of compatibility
issues. So I want to know how exactly this changeover from 2.1 to 2.2
+ fulcrum + torque will happen. At least the base classes of the whole
om system will change from org.apache.turbine to org.apache.torque,
wouldn't it? Same goes to the service environment.
We pulled the interface changes from T2.2beta because some users had
to recompile. If I use T2 + Fulcrum + Torque with one of my projects,
I have major _rewrites_ of my code to get it to run.
or am I seeing something wrong here? Will we keep code in both Torque
and T2? If yes, the I really see no point in using them.
>i) Introduction of lifecycle interfaces in org.apache.stratum.lifecycle.
[...]
I always see postings about "that we will have now, that we will make
new, that will change...". But the last released TDK is what? six
months old? And I have the "fun" of working with the Torque code today
a little and honestly, it makes me wanting to throw up. Look at this:
--- cut ---
[...]
private static String getDatabaseProperty(String db, String prop)
{
return configuration.getString( new StringBuffer("database.")
.append(db)
.append('.')
.append(prop)
.toString(), "" );
}
[...]
private static final String getProperty(String dbName, String prop)
{
return ("database." + dbName + '.' + prop);
}
[...]
--- cut ---
What is wrong with this picture? And this is not exactly in an unimportant
piece of Torque but in o.a.t.Torque.java
I can point out some race conditions, some unclear code and I still
ask myself why the Torque class must know about threads running in the
DatabaseMap classes.
Ok, I know that bullshit talks and code walks. But I'm _so_ unhappy
with the current state of the OM system of Torque/Turbine _and_ I have
almost a week of time coming up, that I will work on a prototype of a
"Torque next generation" the next week.
BTW: I'd like to reserve "Turbine-Twister" for this. ;-) (Twister
seems to be almost the only synonym that Webster gave me for
"Torque". )
My intention is not "being compatible to Torque" but "keeping the
style of the Turbine OM system alive while attacking the inadequacies
and shortcomings of the current system. I HATE THE STATIC PEERS FROM
THE VERY BOTTOM OF MY HEART. Yet I will keep facade classes for the
people who want to use it.
I currently have about 10% of the code ready and I tackled some of the
heavier stuff first (Torque, Criteria, BasePeer). I will basically
keep the Transformation stuff as it is but (of course) tackle the
templates.
Ideas I will work on from the README.txt
--- cut ---
o Torque should be fully functional on its own, but right now
it doesn't work as a persistence layer without the DBService
in Fulcrum. The classes should be moved from Fulcrum into
this repository and Torque should be made to work on its own
and be embeddable in applications. The DBService in Fulcrum
should be a wrapper around Torque.
o Separate the connection pool and make it pluggable
so that torque can easily be integrated into other application
that already use PoolMan, or the commons connection pool, or
the struts connection pool or whatever
--- cut ---
I have also some notes already written down:
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
