You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Kevin Menard <km...@servprise.com> on 2006/06/23 15:06:41 UTC
External framework tie-ins?
Hey all,
The recent thread with Michael re: Tapestry and even the one on the users
list not too long ago about HiveMind & Cayenne got me thinking a little.
How do you guys feel about having framework extension package in Cayenne?
I realize there's a push not to include what can be perceived as bloat,
but realistically, a few extra classes here and there aren't going to make
a huge difference. Currently, we rely on the external frameworks to add
support for Cayenne. If they don't add it, then we sorta just linger.
E.g., Spring didn't add Cayenne support, so Spring-Cayenne integration
went into an external lib that hardly anyone uses.
Cayenne is pretty simple to integrate with most frameworks, so I think
we've ignored the integration aspect thus far. But everyone that wants to
tie in with Tapestry, for example, has to jump through the same (few)
hoops. I suppose that could be one argument for using Click, which seems
to work well with Cayenne out of the box, but we should try to maximize
exposure.
The presence of an external contrib lib could be argued for, but what I'm
aiming to do is cut down on the amount of time to tie in with whatever
other frameworks. I also want something that is fairly well supported and
maintained.
--
Kevin
Re: External framework tie-ins?
Posted by "Watkins, Garry" <gw...@motleyrice.com>.
I agree with Andrus on separating these out. I really would like to get the
WO compatibility layer separated.
Just my .02
Garry
On 6/23/06 9:42 AM, "Andrus Adamchik" <an...@objectstyle.org> wrote:
>
> On Jun 23, 2006, at 5:06 PM, Kevin Menard wrote:
>
>> The presence of an external contrib lib could be argued for, but
>> what I'm aiming to do is cut down on the amount of time to tie in
>> with whatever other frameworks. I also want something that is
>> fairly well supported and maintained.
>
> I think the core of the issue is "supported and maintained" and not
> the "same jar vs. a separate jar". We have these examples of
> technologies that are somewhat tangential to Cayenne:
>
> * Spring integration is not maintained cause nobody cares to maintain
> it.
> * WebObjects integration is fairly well maintained.
> * DataViews is abandoned (inside Cayenne)
>
> At the source level I would actually separate each integration piece
> in its own Maven module (if only to have a clear separation of third-
> party dependencies for the build build), and defer a decision of how
> we assemble the release till we actually have those pieces written.
>
> Andrus
>
--
Garry Watkins
Database Administrator
Motley Rice LLC
843-216-9639
Confidential & Privileged
Unless otherwise indicated or obvious from its nature, the information contained in this communication is attorney-client privileged and confidential information/work product. This communication is intended for the use of the individual or entity named above. If the reader of this communication is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error or are not sure whether it is privileged, please immediately notify us by return e-mail and destroy any copies--electronic, paper or otherwise--which you may have of this communication.
Re: External framework tie-ins?
Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 23, 2006, at 5:06 PM, Kevin Menard wrote:
> The presence of an external contrib lib could be argued for, but
> what I'm aiming to do is cut down on the amount of time to tie in
> with whatever other frameworks. I also want something that is
> fairly well supported and maintained.
I think the core of the issue is "supported and maintained" and not
the "same jar vs. a separate jar". We have these examples of
technologies that are somewhat tangential to Cayenne:
* Spring integration is not maintained cause nobody cares to maintain
it.
* WebObjects integration is fairly well maintained.
* DataViews is abandoned (inside Cayenne)
At the source level I would actually separate each integration piece
in its own Maven module (if only to have a clear separation of third-
party dependencies for the build build), and defer a decision of how
we assemble the release till we actually have those pieces written.
Andrus
RE: External framework tie-ins?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I still think putting such things on the wiki could be quite useful. We
can have Tapestry/Cayenne documentation and source code attached as
files for download, so someone won't need to re-write things, just get
the code. Just my opinion, though. Anyone else have thoughts on the
matter?
Thanks,
/dev/mrg
-----Original Message-----
From: Kevin Menard [mailto:kmenard@servprise.com]
Sent: Friday, June 23, 2006 10:12 AM
To: cayenne-dev@incubator.apache.org
Subject: Re: External framework tie-ins?
On Fri, 23 Jun 2006 10:00:15 -0400, Gentry, Michael (Contractor)
<mi...@fanniemae.com> wrote:
> I'm not sure things needed to be added in, but perhaps some better
> documentation. Such as with Tapestry, document how you can use a
> DataSqueezer (and point to Tapestry wiki page -- or wherever the
> squeezer is). Or use the hash code approach I was talking about if
your
> application shouldn't be exposing database information
(keys/tables/etc)
> to the client. These seem more of a best practice type of thing than
> adding more into Cayenne (when it can be avoided).
This is exactly what I was saying is part of the existing problem.
Everyone now has to jump through the same hoops, regardless of
documentation. Whereas, for example, we could have a
TapestryCayenneDataObject or something that adds some of this stuff
right
in. Perhaps the Cayenne data squeezer could be absorbed as well. Maybe
even add in that DataContextFactory I posted for interacting with
HiveMind.
Now, when I want to start up a Tapestry project, everything I need is
already there. I really don't have to write the same code that many
others have written before me. The documentation can then tell me how
to
use the API rather than telling me how to write my own.
> Also, with T4, you
> have to be careful with @For/etc because if you are in a FORM, it
wants
> to serialize your data objects to the HTML page it generates. When
the
> user submits the form, it deserializes your data objects, but then
they
> are detached from the data context, which is bad. The above two
> practices prevent the serialization (or re-attach conveniently).
Perhaps a caveat in documentation is the best approach. It just strikes
me that there has to be a better way that'll prevent the issue from
happening in the first place.
--
Kevin
Re: External framework tie-ins?
Posted by Kevin Menard <km...@servprise.com>.
On Fri, 23 Jun 2006 10:00:15 -0400, Gentry, Michael (Contractor)
<mi...@fanniemae.com> wrote:
> I'm not sure things needed to be added in, but perhaps some better
> documentation. Such as with Tapestry, document how you can use a
> DataSqueezer (and point to Tapestry wiki page -- or wherever the
> squeezer is). Or use the hash code approach I was talking about if your
> application shouldn't be exposing database information (keys/tables/etc)
> to the client. These seem more of a best practice type of thing than
> adding more into Cayenne (when it can be avoided).
This is exactly what I was saying is part of the existing problem.
Everyone now has to jump through the same hoops, regardless of
documentation. Whereas, for example, we could have a
TapestryCayenneDataObject or something that adds some of this stuff right
in. Perhaps the Cayenne data squeezer could be absorbed as well. Maybe
even add in that DataContextFactory I posted for interacting with HiveMind.
Now, when I want to start up a Tapestry project, everything I need is
already there. I really don't have to write the same code that many
others have written before me. The documentation can then tell me how to
use the API rather than telling me how to write my own.
> Also, with T4, you
> have to be careful with @For/etc because if you are in a FORM, it wants
> to serialize your data objects to the HTML page it generates. When the
> user submits the form, it deserializes your data objects, but then they
> are detached from the data context, which is bad. The above two
> practices prevent the serialization (or re-attach conveniently).
Perhaps a caveat in documentation is the best approach. It just strikes
me that there has to be a better way that'll prevent the issue from
happening in the first place.
--
Kevin
RE: External framework tie-ins?
Posted by "Gentry, Michael (Contractor)" <mi...@fanniemae.com>.
I'm not sure things needed to be added in, but perhaps some better
documentation. Such as with Tapestry, document how you can use a
DataSqueezer (and point to Tapestry wiki page -- or wherever the
squeezer is). Or use the hash code approach I was talking about if your
application shouldn't be exposing database information (keys/tables/etc)
to the client. These seem more of a best practice type of thing than
adding more into Cayenne (when it can be avoided). Also, with T4, you
have to be careful with @For/etc because if you are in a FORM, it wants
to serialize your data objects to the HTML page it generates. When the
user submits the form, it deserializes your data objects, but then they
are detached from the data context, which is bad. The above two
practices prevent the serialization (or re-attach conveniently).
/dev/mrg
-----Original Message-----
From: Kevin Menard [mailto:kmenard@servprise.com]
Sent: Friday, June 23, 2006 9:07 AM
To: cayenne-dev@incubator.apache.org
Subject: External framework tie-ins?
Hey all,
The recent thread with Michael re: Tapestry and even the one on the
users
list not too long ago about HiveMind & Cayenne got me thinking a little.
How do you guys feel about having framework extension package in
Cayenne?
I realize there's a push not to include what can be perceived as bloat,
but realistically, a few extra classes here and there aren't going to
make
a huge difference. Currently, we rely on the external frameworks to add
support for Cayenne. If they don't add it, then we sorta just linger.
E.g., Spring didn't add Cayenne support, so Spring-Cayenne integration
went into an external lib that hardly anyone uses.
Cayenne is pretty simple to integrate with most frameworks, so I think
we've ignored the integration aspect thus far. But everyone that wants
to
tie in with Tapestry, for example, has to jump through the same (few)
hoops. I suppose that could be one argument for using Click, which
seems
to work well with Cayenne out of the box, but we should try to maximize
exposure.
The presence of an external contrib lib could be argued for, but what
I'm
aiming to do is cut down on the amount of time to tie in with whatever
other frameworks. I also want something that is fairly well supported
and
maintained.
--
Kevin