On Tue, Jan 14, 2003 at 10:37:37AM -0500, Chris Felaco wrote:
> >- Separate the template based engine which creates java classes from
> > templates from the actual persistence code.
>
> I'm not entirely sure what you're proposing here, but I think
> you're suggesting keeping the save() and related methods out of
> the OM objects entirely.
No, I think he was suggesting that as it is now, the templates look
like:
public class $blah {
#if x
protected int foo;
#if y
public int getFoo()
#if z
return x
#else
return w
#endif
#endif
#endif
So, this isn't a real code snippet. But having to do both
persistence code generation and Java source generation at the same
time sucks. My interpretation was that the Java source generation
would be put in a seperate template based engine, then Torque would
interact with a nice API and plug in the various bits of persistence
code here and there (as templates).
> I'm not in favor of simply replacing the existing persistence
> layer with any other persistence layer out there. There are so
> many APIs out there that it's hard to make sense of them all and
> compare and contrast them.
Precisely why we don't need to make another one. As long as we pick
a good one, with community support, that 1-2-3 years from now will
still be around and active/semi-active, I think it is a great boon
for us not having to re-invent and re-debug and re-maintain the
wheel.
If you want to spend the next few months/years designing,
implementing, and maintaining your very own persistance mechancism
embedded specifically into Torque, go ahead. But given that there
are already viable, generic alternatives, I'd rather do that.
> Torque should be self-sufficient if it has any chance of surviving
> on its own merits. If Torque is at the mercy of bugs in another
> API, it's less viable.
If you pick a good API that is stable and released, this won't
happen anymore than we have bugs in our own solution.
> And worse, it will probably have to resort to inefficient
> convoluted code to work with ANY other API that had different
> design goals.
Given that with Torque we just want to persist objects (that we also
happen to generate), and in any given persistance implementation
(OJB, Hibernate, player), they just want to persist objects, how are
the design goals different?
I can assure you that using a well-designed API would be much nicer
than what we have now, and IMHO, much easier than refactoring what
we have now (and it seems Henning and Martin agree with this point).
Indeed this is the very point of API's and libraries of any nature.
> As it stands today, the only reason to use Torque is if you're
> already using it.
Agreed. If I had to choose again, I would not use Torque on my
project. BUT, it is because the persistence implementation is
fragile and buggy. The generation part of it is awesome. Generation
is what everyone loves about Torque. The actual persistence is what
everyone hates about Torque.
To me, a simple surgery as per Martin's suggestion of dropping in a
different persistence implementation would be ideal and:
Create a reason for new users to start using Torque.
> Why? The big selling point of Torque to me is the ease of using
> Velocity templates.
I like Velocity for text generation, but it sucks as embedding
business logic in it, which is all over the freaking place in the
templates. To me an object model where you could use inheritance,
polymorphism, and encapsulation, all the reasons we like Java, to
build the generated object model in memory and then pass it off to a
generic source file generation library would be ideal.
- Stephen
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
