Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

the spec says:

"When instances are queried,
navigated to, or modified, instantiation of instances
and their fields and garbage collection
of unreferenced instances occurs without any explicit
control"

So that means that whatever implementation is used to
map between identity and Object, it can't be a hard
reference. So pojo's get garbage collected out of the
L1 cache. So that lends even more weight to your
statement that you need an L2 cache. Half the time the
implementation is going out to the DB to repopulate
the cache (like if you have a pojo and it's in a
wicket session that gets serialized, welll whoops, the
JDO implementation is going to query the DB to
repopulate the cache the when you deserialize and do
getObjectById).

--- Matej Knopp <[EMAIL PROTECTED]> wrote:

> I haven't profiled L2 caching done by database, if
> someone has I'd 
> really be interested in results.
> 
> Anyway, I wouldn't use WeakReference for caching,
> SoftReference seems to 
> be better alternative.
> 
> -Matej
> 
> Geoff hendrey wrote:
> > No doubt L2 caching can speed up apps. Most
> databases
> > implement caching already. With L2 cache comes
> another
> > set of problems, and when you get deep enough into
> > them, you may wish you had not used the L2 cache,
> but
> > simply relied on effective caching in the
> database. On
> > the other hand, many L2 caching layers are out
> there,
> > and can be easily used with a pojo, whether the
> pojo
> > was retrieved by shades or not.
> > 
> > WeakHashMap will discard your key/val pair during
> the
> > first garbage collection cycle after your program
> > holds no references to the key."An entry in a
> > WeakHashMap will automatically be removed when its
> key
> > is no longer in ordinary use"...from the javadoc.
> > 
> > 
> > 
> > --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> > 
> >> I was more concerned about second level cache.
> When
> >> using loadable 
> >> detachable models it is possible to hold only
> object
> >> id in session, 
> >> loading the entire object on the beginning on
> >> request. In this scenario 
> >> second level cache really helps. I think this is
> >> feature that lot of 
> >> people would be missing.
> >>
> >>  > If your application does not keep a reference
> >>> to the pojo, the pojo doesn't stay in the cache.
> >> What
> >>> kind of cache is that? :-)
> >> I think using soft references, the objects would
> be
> >> evicted only if out 
> >> of memory is about to happen.
> >>
> >> -Matej
> >>
> >>> --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> >>>
>  And how is caching done if you can't query
> >> objects
>  by identity? Or does 
>  this question make even sense?
> 
>  -Matej
> 
>  Geoff hendrey wrote:
> > Ohh my god yes
> >
> > I ran into all these problems in JDOMax, and
> >> they
>  are
> > all solved in Shades.
> >
> > I won't drop the name, but some very
> influential
> > person on EJB and JDO specs now believe that
>  exposing
> > object identity in the form of API's was a
>  mistake.
> > I agree -- you will notice shades has no
> methods
>  to
> > retrieve an object by identity. Shades only
> has
> > queries.
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg <[EMAIL PROTECTED]>
> >> wrote:
> >> another interesting problem i find with
> >> identity
>  in
> >> full blown orms is that
> >> it can cause a nasty cascade of loading
> object
>  graph
> >> when using "business"
> >> identity instead of db identity.
> >>
> >> if you have school->semester->class
> >> relationships
> >> and you do not want to
> >> depend on db identity which is the
> >> "recommended"
>  way
> >> most likely you will
> >> have
> >>
> >> class.equals(class other) {
> >> this.name.equals(other.name
> >> )&&this.semester.equals(other.semster); }
> >> semester.equals(semester other) {
> >> this.code.equals(other.code
> >> )&&this.school.equals(other.school); }
> >>
> >> so now every time you equals/hashcode a class
> >> you
> >> load the semester and the
> >> school. given they they are loaded-by-id and
>  might
> >> be in 2nd level
> >> cachebut still. this is the kind of
> >> troubles
>  you
> >> always have when
> >> working on such a highly abstracted level
> that
> >> doesnt always map properly to
> >> the bare metal.
> >>
> >> -Igor
> >>
> >>
> >> On 8/26/06, Geoff hendrey
>  <[EMAIL PROTECTED]>
> >> wrote:
> >>> Sure - but honestly I don't want to convince
> >> anyone
> >>> they need Shades.
> >>>
> >>> One problem I found with JDO was that the
> >>> PersistenceManager was not serializable.
> >> Another
> >> is
> >>> that detachment had to be handled
> explicitely.
> >>>
> >>> In Shades all pojo's are inherently
> detached.
> >> Change
> >>> tracking 

Re: [Wicket-user] library example using Shades for O/R mapping

[Matej Knopp]

I haven't profiled L2 caching done by database, if someone has I'd 
really be interested in results.

Anyway, I wouldn't use WeakReference for caching, SoftReference seems to 
be better alternative.

-Matej

Geoff hendrey wrote:
> No doubt L2 caching can speed up apps. Most databases
> implement caching already. With L2 cache comes another
> set of problems, and when you get deep enough into
> them, you may wish you had not used the L2 cache, but
> simply relied on effective caching in the database. On
> the other hand, many L2 caching layers are out there,
> and can be easily used with a pojo, whether the pojo
> was retrieved by shades or not.
> 
> WeakHashMap will discard your key/val pair during the
> first garbage collection cycle after your program
> holds no references to the key."An entry in a
> WeakHashMap will automatically be removed when its key
> is no longer in ordinary use"...from the javadoc.
> 
> 
> 
> --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> 
>> I was more concerned about second level cache. When
>> using loadable 
>> detachable models it is possible to hold only object
>> id in session, 
>> loading the entire object on the beginning on
>> request. In this scenario 
>> second level cache really helps. I think this is
>> feature that lot of 
>> people would be missing.
>>
>>  > If your application does not keep a reference
>>> to the pojo, the pojo doesn't stay in the cache.
>> What
>>> kind of cache is that? :-)
>> I think using soft references, the objects would be
>> evicted only if out 
>> of memory is about to happen.
>>
>> -Matej
>>
>>> --- Matej Knopp <[EMAIL PROTECTED]> wrote:
>>>
 And how is caching done if you can't query
>> objects
 by identity? Or does 
 this question make even sense?

 -Matej

 Geoff hendrey wrote:
> Ohh my god yes
>
> I ran into all these problems in JDOMax, and
>> they
 are
> all solved in Shades.
>
> I won't drop the name, but some very influential
> person on EJB and JDO specs now believe that
 exposing
> object identity in the form of API's was a
 mistake.
> I agree -- you will notice shades has no methods
 to
> retrieve an object by identity. Shades only has
> queries.
>
> -geoff
>
>
>
> --- Igor Vaynberg <[EMAIL PROTECTED]>
>> wrote:
>> another interesting problem i find with
>> identity
 in
>> full blown orms is that
>> it can cause a nasty cascade of loading object
 graph
>> when using "business"
>> identity instead of db identity.
>>
>> if you have school->semester->class
>> relationships
>> and you do not want to
>> depend on db identity which is the
>> "recommended"
 way
>> most likely you will
>> have
>>
>> class.equals(class other) {
>> this.name.equals(other.name
>> )&&this.semester.equals(other.semster); }
>> semester.equals(semester other) {
>> this.code.equals(other.code
>> )&&this.school.equals(other.school); }
>>
>> so now every time you equals/hashcode a class
>> you
>> load the semester and the
>> school. given they they are loaded-by-id and
 might
>> be in 2nd level
>> cachebut still. this is the kind of
>> troubles
 you
>> always have when
>> working on such a highly abstracted level that
>> doesnt always map properly to
>> the bare metal.
>>
>> -Igor
>>
>>
>> On 8/26/06, Geoff hendrey
 <[EMAIL PROTECTED]>
>> wrote:
>>> Sure - but honestly I don't want to convince
>> anyone
>>> they need Shades.
>>>
>>> One problem I found with JDO was that the
>>> PersistenceManager was not serializable.
>> Another
>> is
>>> that detachment had to be handled explicitely.
>>>
>>> In Shades all pojo's are inherently detached.
>> Change
>>> tracking is automagic. The DatabaseSession is
>>> ultra-leightweight and totally appropriate for
>> keeping
>>> in a Session.
>>>
>>> A big innovation in Shades is how identity is
>> handled
>>> - that really solved a lot of problems for me
>> related
>>> to change of identity within transactions.
>> Identity is
>>> a much more fluid concept in Shades, due to
>> the
>>> dynamic ORMapping interface, which you can
>> even
>>> implement on the fly as an anonynmous inner
 class.
>>> To be clear, I found ways to make JDO work
>> just
>> fine
>>> with Wicket. Certainly JDO was a huge step
 forward
>> in
>>> making it easier to use Pojo-based frameworks
 like
>>> Wicket.
>>>
>>> I blogged a bit on my motivation for Shades:
>>> http://notskateboarding.blogspot.com/
>>>
>>> -geoff
>>>
>>>
>>>
>>> --- Igor Vaynberg <[EMAIL PROTECTED]>
 wrote:
 i glanced over the code - but i dont get it
>> after
 the first glance. perhaps
 you can explain what difficu

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

No doubt L2 caching can speed up apps. Most databases
implement caching already. With L2 cache comes another
set of problems, and when you get deep enough into
them, you may wish you had not used the L2 cache, but
simply relied on effective caching in the database. On
the other hand, many L2 caching layers are out there,
and can be easily used with a pojo, whether the pojo
was retrieved by shades or not.

WeakHashMap will discard your key/val pair during the
first garbage collection cycle after your program
holds no references to the key."An entry in a
WeakHashMap will automatically be removed when its key
is no longer in ordinary use"...from the javadoc.



--- Matej Knopp <[EMAIL PROTECTED]> wrote:

> I was more concerned about second level cache. When
> using loadable 
> detachable models it is possible to hold only object
> id in session, 
> loading the entire object on the beginning on
> request. In this scenario 
> second level cache really helps. I think this is
> feature that lot of 
> people would be missing.
> 
>  > If your application does not keep a reference
> > to the pojo, the pojo doesn't stay in the cache.
> What
> > kind of cache is that? :-)
> 
> I think using soft references, the objects would be
> evicted only if out 
> of memory is about to happen.
> 
> -Matej
> 
> > 
> > --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> > 
> >> And how is caching done if you can't query
> objects
> >> by identity? Or does 
> >> this question make even sense?
> >>
> >> -Matej
> >>
> >> Geoff hendrey wrote:
> >>> Ohh my god yes
> >>>
> >>> I ran into all these problems in JDOMax, and
> they
> >> are
> >>> all solved in Shades.
> >>>
> >>> I won't drop the name, but some very influential
> >>> person on EJB and JDO specs now believe that
> >> exposing
> >>> object identity in the form of API's was a
> >> mistake.
> >>> I agree -- you will notice shades has no methods
> >> to
> >>> retrieve an object by identity. Shades only has
> >>> queries.
> >>>
> >>> -geoff
> >>>
> >>>
> >>>
> >>> --- Igor Vaynberg <[EMAIL PROTECTED]>
> wrote:
> >>>
>  another interesting problem i find with
> identity
> >> in
>  full blown orms is that
>  it can cause a nasty cascade of loading object
> >> graph
>  when using "business"
>  identity instead of db identity.
> 
>  if you have school->semester->class
> relationships
>  and you do not want to
>  depend on db identity which is the
> "recommended"
> >> way
>  most likely you will
>  have
> 
>  class.equals(class other) {
>  this.name.equals(other.name
>  )&&this.semester.equals(other.semster); }
>  semester.equals(semester other) {
>  this.code.equals(other.code
>  )&&this.school.equals(other.school); }
> 
>  so now every time you equals/hashcode a class
> you
>  load the semester and the
>  school. given they they are loaded-by-id and
> >> might
>  be in 2nd level
>  cachebut still. this is the kind of
> troubles
> >> you
>  always have when
>  working on such a highly abstracted level that
>  doesnt always map properly to
>  the bare metal.
> 
>  -Igor
> 
> 
>  On 8/26/06, Geoff hendrey
> >> <[EMAIL PROTECTED]>
>  wrote:
> > Sure - but honestly I don't want to convince
>  anyone
> > they need Shades.
> >
> > One problem I found with JDO was that the
> > PersistenceManager was not serializable.
> Another
>  is
> > that detachment had to be handled explicitely.
> >
> > In Shades all pojo's are inherently detached.
>  Change
> > tracking is automagic. The DatabaseSession is
> > ultra-leightweight and totally appropriate for
>  keeping
> > in a Session.
> >
> > A big innovation in Shades is how identity is
>  handled
> > - that really solved a lot of problems for me
>  related
> > to change of identity within transactions.
>  Identity is
> > a much more fluid concept in Shades, due to
> the
> > dynamic ORMapping interface, which you can
> even
> > implement on the fly as an anonynmous inner
> >> class.
> > To be clear, I found ways to make JDO work
> just
>  fine
> > with Wicket. Certainly JDO was a huge step
> >> forward
>  in
> > making it easier to use Pojo-based frameworks
> >> like
> > Wicket.
> >
> > I blogged a bit on my motivation for Shades:
> > http://notskateboarding.blogspot.com/
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg <[EMAIL PROTECTED]>
> >> wrote:
> >> i glanced over the code - but i dont get it
>  after
> >> the first glance. perhaps
> >> you can explain what difficulties you hit
> when
>  using
> >> wicket and an orm to
> >> help us better understand.
> >>
> >> seems to me like you are trying to work with
> a
>  ui
> >> connected to a persistence
> >> layer - without a service layer in between.
> >> have
> 

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Yes, it looks like SimpleOrm has similar objectives.
You can't help but come to some of these same
conclusions. Some of the solutions are amlost
self-evident after working with, shall we say,
"complex-orm" for long enough.

Nope, I've not read that book, but I'll put it on my
list. :-)


-geoff
--- Martijn Dashorst <[EMAIL PROTECTED]>
wrote:

> I understand your position... Shades is your hobby,
> pet project and it
> would be nice that people find it helpful. I think
> there is a market
> for it, as other people have come to the same
> conclusion.
> 
> At my company at least I and a collegue of mine are
> very interested in
> trying out http://www.simpleorm.org/ It seems like
> this is very
> similar to your proposition. Their goals are about
> the same but they
> took a different direction.
> 
> The name 'Shades' is not a pun directed to 'The
> Shades', from Terry
> Pratchett's Discworld, would it? :)
> 
> Martijn
> 
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:
> > Sure - but honestly I don't want to convince
> anyone
> > they need Shades.
> >
> > One problem I found with JDO was that the
> > PersistenceManager was not serializable. Another
> is
> > that detachment had to be handled explicitely.
> >
> > In Shades all pojo's are inherently detached.
> Change
> > tracking is automagic. The DatabaseSession is
> > ultra-leightweight and totally appropriate for
> keeping
> > in a Session.
> >
> > A big innovation in Shades is how identity is
> handled
> > - that really solved a lot of problems for me
> related
> > to change of identity within transactions.
> Identity is
> > a much more fluid concept in Shades, due to the
> > dynamic ORMapping interface, which you can even
> > implement on the fly as an anonynmous inner class.
> >
> > To be clear, I found ways to make JDO work just
> fine
> > with Wicket. Certainly JDO was a huge step forward
> in
> > making it easier to use Pojo-based frameworks like
> > Wicket.
> >
> > I blogged a bit on my motivation for Shades:
> > http://notskateboarding.blogspot.com/
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > > i glanced over the code - but i dont get it
> after
> > > the first glance. perhaps
> > > you can explain what difficulties you hit when
> using
> > > wicket and an orm to
> > > help us better understand.
> > >
> > > seems to me like you are trying to work with a
> ui
> > > connected to a persistence
> > > layer - without a service layer in between. have
> you
> > > seen databinder which
> > > glues wicket and hibernate together?
> > >
> > > also your point about wicket and tapestry -
> wicket
> > > is much more flexible
> > > because it has IModel which gives you an extra
> layer
> > > of indirection that can
> > > hide a lot of orm logic and make the code
> > > cleaner/easier.
> > >
> > > -Igor
> > >
> > >
> > > On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I was one of the early users of Wicket before
> 1.0.
> > > I
> > > > did a lot of work to use Wicket with my JDO
> > > > implementation JDOMax (no longer supported).
> In
> > > the
> > > > process I learned a lot about why it is harder
> > > than it
> > > > has to be to use many ORM frameworks with
> Wicket
> > > and
> > > > Tapestry.
> > > >
> > > > I'm a member of JSR 243 Java Data Objects
> Experts
> > > > Group, and I advocated hard within that spec
> for
> > > the
> > > > "fixing" of the JDO spec with regard to
> > > > non-transaction-write behavior, along with
> Eric
> > > Samson
> > > > and others. The JDO group  was receptive,
> having
> > > > gotten similar feedback from Howard Lewis Ship
> of
> > > > Tapestry. I believe this change will benefit
> > > Wicket
> > > > users, and make it much easier to use JDO 2.0
> than
> > > JDO
> > > > 1.1, from Wicket.
> > > >
> > > > However, I still wasn't satisfied that it was
> > > "easy"
> > > > to do ORM from Wicket or Tapestry. So I
> started a
> > > new
> > > > project, based on what I learned -- it's a
> better
> > > way
> > > > to do ORM -- I call it Shades. Following the
> > > wicket
> > > > style,Shades works without any XML
> configuration.
> > > >
> > > > Rather than make this any longer-winded, I
> thought
> > > I
> > > > would just begin passing back some code,
> showing
> > > the
> > > > Library sample application using Shades. The
> > > attached
> > > > zipfile is just the "library" folder from the
> > > wicket
> > > > sample applications. EditBook.java and
> > > > LibrarySession.java have been altered to use
> > > Shades
> > > > for database access. LibraryORMDictionary.java
> is
> > > the
> > > > only new file required.
> > > >
> > > > Please let me know what you think. Also, I do
> not
> > > have
> > > > a website for Shades yet but I hope to find
> the
> > > right
> > > > venue for open sourcing the code soon. (see
> > > attached
> > > > zip file 'library.zippo' with library-example
> > > directory)
> > > >
> > > >
> > >
> >
>
---

Re: [Wicket-user] library example using Shades for O/R mapping

[Matej Knopp]

I was more concerned about second level cache. When using loadable 
detachable models it is possible to hold only object id in session, 
loading the entire object on the beginning on request. In this scenario 
second level cache really helps. I think this is feature that lot of 
people would be missing.

 > If your application does not keep a reference
> to the pojo, the pojo doesn't stay in the cache. What
> kind of cache is that? :-)

I think using soft references, the objects would be evicted only if out 
of memory is about to happen.

-Matej

> 
> --- Matej Knopp <[EMAIL PROTECTED]> wrote:
> 
>> And how is caching done if you can't query objects
>> by identity? Or does 
>> this question make even sense?
>>
>> -Matej
>>
>> Geoff hendrey wrote:
>>> Ohh my god yes
>>>
>>> I ran into all these problems in JDOMax, and they
>> are
>>> all solved in Shades.
>>>
>>> I won't drop the name, but some very influential
>>> person on EJB and JDO specs now believe that
>> exposing
>>> object identity in the form of API's was a
>> mistake.
>>> I agree -- you will notice shades has no methods
>> to
>>> retrieve an object by identity. Shades only has
>>> queries.
>>>
>>> -geoff
>>>
>>>
>>>
>>> --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>>>
 another interesting problem i find with identity
>> in
 full blown orms is that
 it can cause a nasty cascade of loading object
>> graph
 when using "business"
 identity instead of db identity.

 if you have school->semester->class relationships
 and you do not want to
 depend on db identity which is the "recommended"
>> way
 most likely you will
 have

 class.equals(class other) {
 this.name.equals(other.name
 )&&this.semester.equals(other.semster); }
 semester.equals(semester other) {
 this.code.equals(other.code
 )&&this.school.equals(other.school); }

 so now every time you equals/hashcode a class you
 load the semester and the
 school. given they they are loaded-by-id and
>> might
 be in 2nd level
 cachebut still. this is the kind of troubles
>> you
 always have when
 working on such a highly abstracted level that
 doesnt always map properly to
 the bare metal.

 -Igor


 On 8/26/06, Geoff hendrey
>> <[EMAIL PROTECTED]>
 wrote:
> Sure - but honestly I don't want to convince
 anyone
> they need Shades.
>
> One problem I found with JDO was that the
> PersistenceManager was not serializable. Another
 is
> that detachment had to be handled explicitely.
>
> In Shades all pojo's are inherently detached.
 Change
> tracking is automagic. The DatabaseSession is
> ultra-leightweight and totally appropriate for
 keeping
> in a Session.
>
> A big innovation in Shades is how identity is
 handled
> - that really solved a lot of problems for me
 related
> to change of identity within transactions.
 Identity is
> a much more fluid concept in Shades, due to the
> dynamic ORMapping interface, which you can even
> implement on the fly as an anonynmous inner
>> class.
> To be clear, I found ways to make JDO work just
 fine
> with Wicket. Certainly JDO was a huge step
>> forward
 in
> making it easier to use Pojo-based frameworks
>> like
> Wicket.
>
> I blogged a bit on my motivation for Shades:
> http://notskateboarding.blogspot.com/
>
> -geoff
>
>
>
> --- Igor Vaynberg <[EMAIL PROTECTED]>
>> wrote:
>> i glanced over the code - but i dont get it
 after
>> the first glance. perhaps
>> you can explain what difficulties you hit when
 using
>> wicket and an orm to
>> help us better understand.
>>
>> seems to me like you are trying to work with a
 ui
>> connected to a persistence
>> layer - without a service layer in between.
>> have
 you
>> seen databinder which
>> glues wicket and hibernate together?
>>
>> also your point about wicket and tapestry -
 wicket
>> is much more flexible
>> because it has IModel which gives you an extra
 layer
>> of indirection that can
>> hide a lot of orm logic and make the code
>> cleaner/easier.
>>
>> -Igor
>>
>>
>> On 8/26/06, Geoff hendrey
 <[EMAIL PROTECTED]>
>> wrote:
>>> Hi All,
>>>
>>> I was one of the early users of Wicket before
 1.0.
>> I
>>> did a lot of work to use Wicket with my JDO
>>> implementation JDOMax (no longer supported).
 In
>> the
>>> process I learned a lot about why it is harder
>> than it
>>> has to be to use many ORM frameworks with
 Wicket
>> and
>>> Tapestry.
>>>
>>> I'm a member of JSR 243 Java Data Objects
 Experts
>>> Group, and I advocated hard within that spec
 for
>> the
>>> "fixing" of the JDO spec with regard to
>>> non-t

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Most ORMS have 2 kinds of L1 caching:

1) caching of compiled queries
2) caching of POJOs, where the cache is keyed by
identity


Shades does (1).

Shades does not do (2). 

I found that the L1 cache was actually redundant. Why?
Because most modern frameworks, like Wicket, take the
pojo, and hold onto it. The caching is implicit in the
application. In JDO, the L1 cache is implemented using
WeakHashMap. So it's sort of a pseudocache anyway. We
(the JDO EG) actually had a long debate about changing
some of the JDO method names to not use the term
"cache". If your application does not keep a reference
to the pojo, the pojo doesn't stay in the cache. What
kind of cache is that? :-)

--- Matej Knopp <[EMAIL PROTECTED]> wrote:

> And how is caching done if you can't query objects
> by identity? Or does 
> this question make even sense?
> 
> -Matej
> 
> Geoff hendrey wrote:
> > Ohh my god yes
> > 
> > I ran into all these problems in JDOMax, and they
> are
> > all solved in Shades.
> > 
> > I won't drop the name, but some very influential
> > person on EJB and JDO specs now believe that
> exposing
> > object identity in the form of API's was a
> mistake.
> > 
> > I agree -- you will notice shades has no methods
> to
> > retrieve an object by identity. Shades only has
> > queries.
> > 
> > -geoff
> > 
> > 
> > 
> > --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > 
> >> another interesting problem i find with identity
> in
> >> full blown orms is that
> >> it can cause a nasty cascade of loading object
> graph
> >> when using "business"
> >> identity instead of db identity.
> >>
> >> if you have school->semester->class relationships
> >> and you do not want to
> >> depend on db identity which is the "recommended"
> way
> >> most likely you will
> >> have
> >>
> >> class.equals(class other) {
> >> this.name.equals(other.name
> >> )&&this.semester.equals(other.semster); }
> >> semester.equals(semester other) {
> >> this.code.equals(other.code
> >> )&&this.school.equals(other.school); }
> >>
> >> so now every time you equals/hashcode a class you
> >> load the semester and the
> >> school. given they they are loaded-by-id and
> might
> >> be in 2nd level
> >> cachebut still. this is the kind of troubles
> you
> >> always have when
> >> working on such a highly abstracted level that
> >> doesnt always map properly to
> >> the bare metal.
> >>
> >> -Igor
> >>
> >>
> >> On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]>
> >> wrote:
> >>> Sure - but honestly I don't want to convince
> >> anyone
> >>> they need Shades.
> >>>
> >>> One problem I found with JDO was that the
> >>> PersistenceManager was not serializable. Another
> >> is
> >>> that detachment had to be handled explicitely.
> >>>
> >>> In Shades all pojo's are inherently detached.
> >> Change
> >>> tracking is automagic. The DatabaseSession is
> >>> ultra-leightweight and totally appropriate for
> >> keeping
> >>> in a Session.
> >>>
> >>> A big innovation in Shades is how identity is
> >> handled
> >>> - that really solved a lot of problems for me
> >> related
> >>> to change of identity within transactions.
> >> Identity is
> >>> a much more fluid concept in Shades, due to the
> >>> dynamic ORMapping interface, which you can even
> >>> implement on the fly as an anonynmous inner
> class.
> >>>
> >>> To be clear, I found ways to make JDO work just
> >> fine
> >>> with Wicket. Certainly JDO was a huge step
> forward
> >> in
> >>> making it easier to use Pojo-based frameworks
> like
> >>> Wicket.
> >>>
> >>> I blogged a bit on my motivation for Shades:
> >>> http://notskateboarding.blogspot.com/
> >>>
> >>> -geoff
> >>>
> >>>
> >>>
> >>> --- Igor Vaynberg <[EMAIL PROTECTED]>
> wrote:
> >>>
>  i glanced over the code - but i dont get it
> >> after
>  the first glance. perhaps
>  you can explain what difficulties you hit when
> >> using
>  wicket and an orm to
>  help us better understand.
> 
>  seems to me like you are trying to work with a
> >> ui
>  connected to a persistence
>  layer - without a service layer in between.
> have
> >> you
>  seen databinder which
>  glues wicket and hibernate together?
> 
>  also your point about wicket and tapestry -
> >> wicket
>  is much more flexible
>  because it has IModel which gives you an extra
> >> layer
>  of indirection that can
>  hide a lot of orm logic and make the code
>  cleaner/easier.
> 
>  -Igor
> 
> 
>  On 8/26/06, Geoff hendrey
> >> <[EMAIL PROTECTED]>
>  wrote:
> > Hi All,
> >
> > I was one of the early users of Wicket before
> >> 1.0.
>  I
> > did a lot of work to use Wicket with my JDO
> > implementation JDOMax (no longer supported).
> >> In
>  the
> > process I learned a lot about why it is harder
>  than it
> > has to be to use many ORM frameworks with
> >> Wicket
>  and
> > Tapestry.
> >
> > I'm a member of JSR 243 Java Data Objects
> >> Experts
> 

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

aBook and anAuthor are RecordCandidate instances.
RecordCandidates are not pojo's, just structures used
to represent the data behind a pojo, for the purpose
of forming a query.

aBook.getAuthor() would not compile because
RecordCandidate has no getAuthor method.

-geoff




--- Martijn Dashorst <[EMAIL PROTECTED]>
wrote:

> I also read your blog, and it sounds very
> interesting.
> 
> Just a quick question (probably should've done so on
> the blog though):
> 
> Does it hold that after getting a book and author
> from the results that:
> aBook.getAuthor() == anAuthor
> and/or
> aBook.getAuthor().equals(anAuthor)
> ?
> 
> Martijn
> 
> On 8/27/06, Igor Vaynberg <[EMAIL PROTECTED]>
> wrote:
> > another interesting problem i find with identity
> in full blown orms is that
> > it can cause a nasty cascade of loading object
> graph when using "business"
> > identity instead of db identity.
> >
> > if you have school->semester->class relationships
> and you do not want to
> > depend on db identity which is the "recommended"
> way most likely you will
> > have
> >
> > class.equals(class other) {
> >
>
this.name.equals(other.name)&&this.semester.equals(other.semster);
> }
> > semester.equals(semester other) {
> > this.code.equals(other.code)&&this.school.equals(
> other.school); }
> >
> > so now every time you equals/hashcode a class you
> load the semester and the
> > school. given they they are loaded-by-id and might
> be in 2nd level
> > cachebut still. this is the kind of troubles
> you always have when
> > working on such a highly abstracted level that
> doesnt always map properly to
> > the bare metal.
> >
> >
> > -Igor
> >
> >
> > On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]> wrote:
> > > Sure - but honestly I don't want to convince
> anyone
> > > they need Shades.
> > >
> > > One problem I found with JDO was that the
> > > PersistenceManager was not serializable. Another
> is
> > > that detachment had to be handled explicitely.
> > >
> > > In Shades all pojo's are inherently detached.
> Change
> > > tracking is automagic. The DatabaseSession is
> > > ultra-leightweight and totally appropriate for
> keeping
> > > in a Session.
> > >
> > > A big innovation in Shades is how identity is
> handled
> > > - that really solved a lot of problems for me
> related
> > > to change of identity within transactions.
> Identity is
> > > a much more fluid concept in Shades, due to the
> > > dynamic ORMapping interface, which you can even
> > > implement on the fly as an anonynmous inner
> class.
> > >
> > > To be clear, I found ways to make JDO work just
> fine
> > > with Wicket. Certainly JDO was a huge step
> forward in
> > > making it easier to use Pojo-based frameworks
> like
> > > Wicket.
> > >
> > > I blogged a bit on my motivation for Shades:
> > > http://notskateboarding.blogspot.com/
> > >
> > > -geoff
> > >
> > >
> > >
> > > --- Igor Vaynberg < [EMAIL PROTECTED]>
> wrote:
> > >
> > > > i glanced over the code - but i dont get it
> after
> > > > the first glance. perhaps
> > > > you can explain what difficulties you hit when
> using
> > > > wicket and an orm to
> > > > help us better understand.
> > > >
> > > > seems to me like you are trying to work with a
> ui
> > > > connected to a persistence
> > > > layer - without a service layer in between.
> have you
> > > > seen databinder which
> > > > glues wicket and hibernate together?
> > > >
> > > > also your point about wicket and tapestry -
> wicket
> > > > is much more flexible
> > > > because it has IModel which gives you an extra
> layer
> > > > of indirection that can
> > > > hide a lot of orm logic and make the code
> > > > cleaner/easier.
> > > >
> > > > -Igor
> > > >
> > > >
> > > > On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]>
> > > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I was one of the early users of Wicket
> before 1.0.
> > > > I
> > > > > did a lot of work to use Wicket with my JDO
> > > > > implementation JDOMax (no longer supported).
> In
> > > > the
> > > > > process I learned a lot about why it is
> harder
> > > > than it
> > > > > has to be to use many ORM frameworks with
> Wicket
> > > > and
> > > > > Tapestry.
> > > > >
> > > > > I'm a member of JSR 243 Java Data Objects
> Experts
> > > > > Group, and I advocated hard within that spec
> for
> > > > the
> > > > > "fixing" of the JDO spec with regard to
> > > > > non-transaction-write behavior, along with
> Eric
> > > > Samson
> > > > > and others. The JDO group  was receptive,
> having
> > > > > gotten similar feedback from Howard Lewis
> Ship of
> > > > > Tapestry. I believe this change will benefit
> > > > Wicket
> > > > > users, and make it much easier to use JDO
> 2.0 than
> > > > JDO
> > > > > 1.1, from Wicket.
> > > > >
> > > > > However, I still wasn't satisfied that it
> was
> > > > "easy"
> > > > > to do ORM from Wicket or Tapestry. So I
> started a
> > > > new
> > > > > project, based on what I learned -- it's a
> better
> > > > way
> > > > > to do ORM --

Re: [Wicket-user] library example using Shades for O/R mapping

[Matej Knopp]

And how is caching done if you can't query objects by identity? Or does 
this question make even sense?

-Matej

Geoff hendrey wrote:
> Ohh my god yes
> 
> I ran into all these problems in JDOMax, and they are
> all solved in Shades.
> 
> I won't drop the name, but some very influential
> person on EJB and JDO specs now believe that exposing
> object identity in the form of API's was a mistake.
> 
> I agree -- you will notice shades has no methods to
> retrieve an object by identity. Shades only has
> queries.
> 
> -geoff
> 
> 
> 
> --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> 
>> another interesting problem i find with identity in
>> full blown orms is that
>> it can cause a nasty cascade of loading object graph
>> when using "business"
>> identity instead of db identity.
>>
>> if you have school->semester->class relationships
>> and you do not want to
>> depend on db identity which is the "recommended" way
>> most likely you will
>> have
>>
>> class.equals(class other) {
>> this.name.equals(other.name
>> )&&this.semester.equals(other.semster); }
>> semester.equals(semester other) {
>> this.code.equals(other.code
>> )&&this.school.equals(other.school); }
>>
>> so now every time you equals/hashcode a class you
>> load the semester and the
>> school. given they they are loaded-by-id and might
>> be in 2nd level
>> cachebut still. this is the kind of troubles you
>> always have when
>> working on such a highly abstracted level that
>> doesnt always map properly to
>> the bare metal.
>>
>> -Igor
>>
>>
>> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
>> wrote:
>>> Sure - but honestly I don't want to convince
>> anyone
>>> they need Shades.
>>>
>>> One problem I found with JDO was that the
>>> PersistenceManager was not serializable. Another
>> is
>>> that detachment had to be handled explicitely.
>>>
>>> In Shades all pojo's are inherently detached.
>> Change
>>> tracking is automagic. The DatabaseSession is
>>> ultra-leightweight and totally appropriate for
>> keeping
>>> in a Session.
>>>
>>> A big innovation in Shades is how identity is
>> handled
>>> - that really solved a lot of problems for me
>> related
>>> to change of identity within transactions.
>> Identity is
>>> a much more fluid concept in Shades, due to the
>>> dynamic ORMapping interface, which you can even
>>> implement on the fly as an anonynmous inner class.
>>>
>>> To be clear, I found ways to make JDO work just
>> fine
>>> with Wicket. Certainly JDO was a huge step forward
>> in
>>> making it easier to use Pojo-based frameworks like
>>> Wicket.
>>>
>>> I blogged a bit on my motivation for Shades:
>>> http://notskateboarding.blogspot.com/
>>>
>>> -geoff
>>>
>>>
>>>
>>> --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>>>
 i glanced over the code - but i dont get it
>> after
 the first glance. perhaps
 you can explain what difficulties you hit when
>> using
 wicket and an orm to
 help us better understand.

 seems to me like you are trying to work with a
>> ui
 connected to a persistence
 layer - without a service layer in between. have
>> you
 seen databinder which
 glues wicket and hibernate together?

 also your point about wicket and tapestry -
>> wicket
 is much more flexible
 because it has IModel which gives you an extra
>> layer
 of indirection that can
 hide a lot of orm logic and make the code
 cleaner/easier.

 -Igor


 On 8/26/06, Geoff hendrey
>> <[EMAIL PROTECTED]>
 wrote:
> Hi All,
>
> I was one of the early users of Wicket before
>> 1.0.
 I
> did a lot of work to use Wicket with my JDO
> implementation JDOMax (no longer supported).
>> In
 the
> process I learned a lot about why it is harder
 than it
> has to be to use many ORM frameworks with
>> Wicket
 and
> Tapestry.
>
> I'm a member of JSR 243 Java Data Objects
>> Experts
> Group, and I advocated hard within that spec
>> for
 the
> "fixing" of the JDO spec with regard to
> non-transaction-write behavior, along with
>> Eric
 Samson
> and others. The JDO group  was receptive,
>> having
> gotten similar feedback from Howard Lewis Ship
>> of
> Tapestry. I believe this change will benefit
 Wicket
> users, and make it much easier to use JDO 2.0
>> than
 JDO
> 1.1, from Wicket.
>
> However, I still wasn't satisfied that it was
 "easy"
> to do ORM from Wicket or Tapestry. So I
>> started a
 new
> project, based on what I learned -- it's a
>> better
 way
> to do ORM -- I call it Shades. Following the
 wicket
> style,Shades works without any XML
>> configuration.
> Rather than make this any longer-winded, I
>> thought
 I
> would just begin passing back some code,
>> showing
 the
> Library sample application using Shades. The
 attached
> zipfile is just the "library" folder from the
 wicket
> sample applica

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Ohh my god yes

I ran into all these problems in JDOMax, and they are
all solved in Shades.

I won't drop the name, but some very influential
person on EJB and JDO specs now believe that exposing
object identity in the form of API's was a mistake.

I agree -- you will notice shades has no methods to
retrieve an object by identity. Shades only has
queries.

-geoff



--- Igor Vaynberg <[EMAIL PROTECTED]> wrote:

> another interesting problem i find with identity in
> full blown orms is that
> it can cause a nasty cascade of loading object graph
> when using "business"
> identity instead of db identity.
> 
> if you have school->semester->class relationships
> and you do not want to
> depend on db identity which is the "recommended" way
> most likely you will
> have
> 
> class.equals(class other) {
> this.name.equals(other.name
> )&&this.semester.equals(other.semster); }
> semester.equals(semester other) {
> this.code.equals(other.code
> )&&this.school.equals(other.school); }
> 
> so now every time you equals/hashcode a class you
> load the semester and the
> school. given they they are loaded-by-id and might
> be in 2nd level
> cachebut still. this is the kind of troubles you
> always have when
> working on such a highly abstracted level that
> doesnt always map properly to
> the bare metal.
> 
> -Igor
> 
> 
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:
> >
> > Sure - but honestly I don't want to convince
> anyone
> > they need Shades.
> >
> > One problem I found with JDO was that the
> > PersistenceManager was not serializable. Another
> is
> > that detachment had to be handled explicitely.
> >
> > In Shades all pojo's are inherently detached.
> Change
> > tracking is automagic. The DatabaseSession is
> > ultra-leightweight and totally appropriate for
> keeping
> > in a Session.
> >
> > A big innovation in Shades is how identity is
> handled
> > - that really solved a lot of problems for me
> related
> > to change of identity within transactions.
> Identity is
> > a much more fluid concept in Shades, due to the
> > dynamic ORMapping interface, which you can even
> > implement on the fly as an anonynmous inner class.
> >
> > To be clear, I found ways to make JDO work just
> fine
> > with Wicket. Certainly JDO was a huge step forward
> in
> > making it easier to use Pojo-based frameworks like
> > Wicket.
> >
> > I blogged a bit on my motivation for Shades:
> > http://notskateboarding.blogspot.com/
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > > i glanced over the code - but i dont get it
> after
> > > the first glance. perhaps
> > > you can explain what difficulties you hit when
> using
> > > wicket and an orm to
> > > help us better understand.
> > >
> > > seems to me like you are trying to work with a
> ui
> > > connected to a persistence
> > > layer - without a service layer in between. have
> you
> > > seen databinder which
> > > glues wicket and hibernate together?
> > >
> > > also your point about wicket and tapestry -
> wicket
> > > is much more flexible
> > > because it has IModel which gives you an extra
> layer
> > > of indirection that can
> > > hide a lot of orm logic and make the code
> > > cleaner/easier.
> > >
> > > -Igor
> > >
> > >
> > > On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I was one of the early users of Wicket before
> 1.0.
> > > I
> > > > did a lot of work to use Wicket with my JDO
> > > > implementation JDOMax (no longer supported).
> In
> > > the
> > > > process I learned a lot about why it is harder
> > > than it
> > > > has to be to use many ORM frameworks with
> Wicket
> > > and
> > > > Tapestry.
> > > >
> > > > I'm a member of JSR 243 Java Data Objects
> Experts
> > > > Group, and I advocated hard within that spec
> for
> > > the
> > > > "fixing" of the JDO spec with regard to
> > > > non-transaction-write behavior, along with
> Eric
> > > Samson
> > > > and others. The JDO group  was receptive,
> having
> > > > gotten similar feedback from Howard Lewis Ship
> of
> > > > Tapestry. I believe this change will benefit
> > > Wicket
> > > > users, and make it much easier to use JDO 2.0
> than
> > > JDO
> > > > 1.1, from Wicket.
> > > >
> > > > However, I still wasn't satisfied that it was
> > > "easy"
> > > > to do ORM from Wicket or Tapestry. So I
> started a
> > > new
> > > > project, based on what I learned -- it's a
> better
> > > way
> > > > to do ORM -- I call it Shades. Following the
> > > wicket
> > > > style,Shades works without any XML
> configuration.
> > > >
> > > > Rather than make this any longer-winded, I
> thought
> > > I
> > > > would just begin passing back some code,
> showing
> > > the
> > > > Library sample application using Shades. The
> > > attached
> > > > zipfile is just the "library" folder from the
> > > wicket
> > > > sample applications. EditBook.java and
> > > > LibrarySession.java have been altered to use
> > > Shades
> > > > for database 

Re: [Wicket-user] library example using Shades for O/R mapping

[Martijn Dashorst]

I understand your position... Shades is your hobby, pet project and it
would be nice that people find it helpful. I think there is a market
for it, as other people have come to the same conclusion.

At my company at least I and a collegue of mine are very interested in
trying out http://www.simpleorm.org/ It seems like this is very
similar to your proposition. Their goals are about the same but they
took a different direction.

The name 'Shades' is not a pun directed to 'The Shades', from Terry
Pratchett's Discworld, would it? :)

Martijn

On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
> Sure - but honestly I don't want to convince anyone
> they need Shades.
>
> One problem I found with JDO was that the
> PersistenceManager was not serializable. Another is
> that detachment had to be handled explicitely.
>
> In Shades all pojo's are inherently detached. Change
> tracking is automagic. The DatabaseSession is
> ultra-leightweight and totally appropriate for keeping
> in a Session.
>
> A big innovation in Shades is how identity is handled
> - that really solved a lot of problems for me related
> to change of identity within transactions. Identity is
> a much more fluid concept in Shades, due to the
> dynamic ORMapping interface, which you can even
> implement on the fly as an anonynmous inner class.
>
> To be clear, I found ways to make JDO work just fine
> with Wicket. Certainly JDO was a huge step forward in
> making it easier to use Pojo-based frameworks like
> Wicket.
>
> I blogged a bit on my motivation for Shades:
> http://notskateboarding.blogspot.com/
>
> -geoff
>
>
>
> --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> > i glanced over the code - but i dont get it after
> > the first glance. perhaps
> > you can explain what difficulties you hit when using
> > wicket and an orm to
> > help us better understand.
> >
> > seems to me like you are trying to work with a ui
> > connected to a persistence
> > layer - without a service layer in between. have you
> > seen databinder which
> > glues wicket and hibernate together?
> >
> > also your point about wicket and tapestry - wicket
> > is much more flexible
> > because it has IModel which gives you an extra layer
> > of indirection that can
> > hide a lot of orm logic and make the code
> > cleaner/easier.
> >
> > -Igor
> >
> >
> > On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > Hi All,
> > >
> > > I was one of the early users of Wicket before 1.0.
> > I
> > > did a lot of work to use Wicket with my JDO
> > > implementation JDOMax (no longer supported). In
> > the
> > > process I learned a lot about why it is harder
> > than it
> > > has to be to use many ORM frameworks with Wicket
> > and
> > > Tapestry.
> > >
> > > I'm a member of JSR 243 Java Data Objects Experts
> > > Group, and I advocated hard within that spec for
> > the
> > > "fixing" of the JDO spec with regard to
> > > non-transaction-write behavior, along with Eric
> > Samson
> > > and others. The JDO group  was receptive, having
> > > gotten similar feedback from Howard Lewis Ship of
> > > Tapestry. I believe this change will benefit
> > Wicket
> > > users, and make it much easier to use JDO 2.0 than
> > JDO
> > > 1.1, from Wicket.
> > >
> > > However, I still wasn't satisfied that it was
> > "easy"
> > > to do ORM from Wicket or Tapestry. So I started a
> > new
> > > project, based on what I learned -- it's a better
> > way
> > > to do ORM -- I call it Shades. Following the
> > wicket
> > > style,Shades works without any XML configuration.
> > >
> > > Rather than make this any longer-winded, I thought
> > I
> > > would just begin passing back some code, showing
> > the
> > > Library sample application using Shades. The
> > attached
> > > zipfile is just the "library" folder from the
> > wicket
> > > sample applications. EditBook.java and
> > > LibrarySession.java have been altered to use
> > Shades
> > > for database access. LibraryORMDictionary.java is
> > the
> > > only new file required.
> > >
> > > Please let me know what you think. Also, I do not
> > have
> > > a website for Shades yet but I hope to find the
> > right
> > > venue for open sourcing the code soon. (see
> > attached
> > > zip file 'library.zippo' with library-example
> > directory)
> > >
> > >
> >
> -
> > > Using Tomcat but need to do more? Need to support
> > web services, security?
> > > Get stuff done quickly with pre-integrated
> > technology to make your job
> > > easier
> > > Download IBM WebSphere Application Server v.1.0.1
> > based on Apache Geronimo
> > >
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > >
> > > ___
> > > Wicket-user mailing list
> > > Wicket-user@lists.sourceforge.net
> > >
> >
> https://lists.sourceforge.net/lists/listinfo/wicket-user
> > >
> > >
> > >
> > >
> > >
> 

Re: [Wicket-user] library example using Shades for O/R mapping

[Martijn Dashorst]

I also read your blog, and it sounds very interesting.

Just a quick question (probably should've done so on the blog though):

Does it hold that after getting a book and author from the results that:
aBook.getAuthor() == anAuthor
and/or
aBook.getAuthor().equals(anAuthor)
?

Martijn

On 8/27/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> another interesting problem i find with identity in full blown orms is that
> it can cause a nasty cascade of loading object graph when using "business"
> identity instead of db identity.
>
> if you have school->semester->class relationships and you do not want to
> depend on db identity which is the "recommended" way most likely you will
> have
>
> class.equals(class other) {
> this.name.equals(other.name)&&this.semester.equals(other.semster); }
> semester.equals(semester other) {
> this.code.equals(other.code)&&this.school.equals( other.school); }
>
> so now every time you equals/hashcode a class you load the semester and the
> school. given they they are loaded-by-id and might be in 2nd level
> cachebut still. this is the kind of troubles you always have when
> working on such a highly abstracted level that doesnt always map properly to
> the bare metal.
>
>
> -Igor
>
>
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
> > Sure - but honestly I don't want to convince anyone
> > they need Shades.
> >
> > One problem I found with JDO was that the
> > PersistenceManager was not serializable. Another is
> > that detachment had to be handled explicitely.
> >
> > In Shades all pojo's are inherently detached. Change
> > tracking is automagic. The DatabaseSession is
> > ultra-leightweight and totally appropriate for keeping
> > in a Session.
> >
> > A big innovation in Shades is how identity is handled
> > - that really solved a lot of problems for me related
> > to change of identity within transactions. Identity is
> > a much more fluid concept in Shades, due to the
> > dynamic ORMapping interface, which you can even
> > implement on the fly as an anonynmous inner class.
> >
> > To be clear, I found ways to make JDO work just fine
> > with Wicket. Certainly JDO was a huge step forward in
> > making it easier to use Pojo-based frameworks like
> > Wicket.
> >
> > I blogged a bit on my motivation for Shades:
> > http://notskateboarding.blogspot.com/
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg < [EMAIL PROTECTED]> wrote:
> >
> > > i glanced over the code - but i dont get it after
> > > the first glance. perhaps
> > > you can explain what difficulties you hit when using
> > > wicket and an orm to
> > > help us better understand.
> > >
> > > seems to me like you are trying to work with a ui
> > > connected to a persistence
> > > layer - without a service layer in between. have you
> > > seen databinder which
> > > glues wicket and hibernate together?
> > >
> > > also your point about wicket and tapestry - wicket
> > > is much more flexible
> > > because it has IModel which gives you an extra layer
> > > of indirection that can
> > > hide a lot of orm logic and make the code
> > > cleaner/easier.
> > >
> > > -Igor
> > >
> > >
> > > On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I was one of the early users of Wicket before 1.0.
> > > I
> > > > did a lot of work to use Wicket with my JDO
> > > > implementation JDOMax (no longer supported). In
> > > the
> > > > process I learned a lot about why it is harder
> > > than it
> > > > has to be to use many ORM frameworks with Wicket
> > > and
> > > > Tapestry.
> > > >
> > > > I'm a member of JSR 243 Java Data Objects Experts
> > > > Group, and I advocated hard within that spec for
> > > the
> > > > "fixing" of the JDO spec with regard to
> > > > non-transaction-write behavior, along with Eric
> > > Samson
> > > > and others. The JDO group  was receptive, having
> > > > gotten similar feedback from Howard Lewis Ship of
> > > > Tapestry. I believe this change will benefit
> > > Wicket
> > > > users, and make it much easier to use JDO 2.0 than
> > > JDO
> > > > 1.1, from Wicket.
> > > >
> > > > However, I still wasn't satisfied that it was
> > > "easy"
> > > > to do ORM from Wicket or Tapestry. So I started a
> > > new
> > > > project, based on what I learned -- it's a better
> > > way
> > > > to do ORM -- I call it Shades. Following the
> > > wicket
> > > > style,Shades works without any XML configuration.
> > > >
> > > > Rather than make this any longer-winded, I thought
> > > I
> > > > would just begin passing back some code, showing
> > > the
> > > > Library sample application using Shades. The
> > > attached
> > > > zipfile is just the "library" folder from the
> > > wicket
> > > > sample applications. EditBook.java and
> > > > LibrarySession.java have been altered to use
> > > Shades
> > > > for database access. LibraryORMDictionary.java is
> > > the
> > > > only new file required.
> > > >
> > > > Please let me know what you think. Also, I do not
> > > have
> > > >

Re: [Wicket-user] library example using Shades for O/R mapping

[Eelco Hillenius]

Yeah, forgot about that. http://code.google.com/hosting/

Eelco


On 8/26/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> there is also google oss hosting which i have heard good things about.
> http://code.google.com i believe.
>
> -Igor
>
>
>
> On 8/26/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> >
>  We left Codehaus because we had to wait for weeks for even an answer
> to Jonathan's request of adding another committer (me). So we decided
> to go to SF where we were less dependent on other people.
>
> SF works. I've heard good stories about http://developer.berlios.de/.
> And you could consider proposing incubation at Apache, depending on
> how serious you want to get on this project.
>
> If you want a place for an example/ integration project for Wicket,
> we'd happily give you access to wicket-stuff.
>
> Eelco
>
> On 8/26/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> > We left codehaus because at that time we had some issues with the
> > support. They didn't respond in time and somtimes not at all. But
> > Martjin may give you more details
> >
> > Juergen
> >
> > On 8/26/06, Geoff hendrey < [EMAIL PROTECTED]> wrote:
> > > Hi Igor,
> > >
> > > Cool.
> > >
> > > I'm trying to find the right venue for open sourcing
> > > Shades, and for putting up the javadocs, etc. I was
> > > wondering why you guys left codehaus?
> > >
> > > -geoff
>
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Wicket-user mailing list
>  Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>
>

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Igor Vaynberg]

another interesting problem i find with identity in full blown orms is that it can cause a nasty cascade of loading object graph when using "business" identity instead of db identity.if you have school->semester->class relationships and you do not want to depend on db identity which is the "recommended" way most likely you will have
class.equals(class other) { this.name.equals(other.name)&&this.semester.equals(other.semster); }semester.equals(semester other) { this.code.equals(other.code)&&this.school.equals(
other.school); }so now every time you equals/hashcode a class you load the semester and the school. given they they are loaded-by-id and might be in 2nd level cachebut still. this is the kind of troubles you always have when working on such a highly abstracted level that doesnt always map properly to the bare metal.
-IgorOn 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
Sure - but honestly I don't want to convince anyonethey need Shades.One problem I found with JDO was that thePersistenceManager was not serializable. Another isthat detachment had to be handled explicitely.
In Shades all pojo's are inherently detached. Changetracking is automagic. The DatabaseSession isultra-leightweight and totally appropriate for keepingin a Session.A big innovation in Shades is how identity is handled
- that really solved a lot of problems for me relatedto change of identity within transactions. Identity isa much more fluid concept in Shades, due to thedynamic ORMapping interface, which you can even
implement on the fly as an anonynmous inner class.To be clear, I found ways to make JDO work just finewith Wicket. Certainly JDO was a huge step forward inmaking it easier to use Pojo-based frameworks like
Wicket.I blogged a bit on my motivation for Shades:http://notskateboarding.blogspot.com/-geoff--- Igor Vaynberg <
[EMAIL PROTECTED]> wrote:> i glanced over the code - but i dont get it after> the first glance. perhaps> you can explain what difficulties you hit when using> wicket and an orm to
> help us better understand.>> seems to me like you are trying to work with a ui> connected to a persistence> layer - without a service layer in between. have you> seen databinder which
> glues wicket and hibernate together?>> also your point about wicket and tapestry - wicket> is much more flexible> because it has IModel which gives you an extra layer> of indirection that can
> hide a lot of orm logic and make the code> cleaner/easier.>> -Igor>>> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:> >> > Hi All,> >> > I was one of the early users of Wicket before 1.0.> I> > did a lot of work to use Wicket with my JDO> > implementation JDOMax (no longer supported). In
> the> > process I learned a lot about why it is harder> than it> > has to be to use many ORM frameworks with Wicket> and> > Tapestry.> >> > I'm a member of JSR 243 Java Data Objects Experts
> > Group, and I advocated hard within that spec for> the> > "fixing" of the JDO spec with regard to> > non-transaction-write behavior, along with Eric> Samson> > and others. The JDO group  was receptive, having
> > gotten similar feedback from Howard Lewis Ship of> > Tapestry. I believe this change will benefit> Wicket> > users, and make it much easier to use JDO 2.0 than> JDO> > 
1.1, from Wicket.> >> > However, I still wasn't satisfied that it was> "easy"> > to do ORM from Wicket or Tapestry. So I started a> new> > project, based on what I learned -- it's a better
> way> > to do ORM -- I call it Shades. Following the> wicket> > style,Shades works without any XML configuration.> >> > Rather than make this any longer-winded, I thought
> I> > would just begin passing back some code, showing> the> > Library sample application using Shades. The> attached> > zipfile is just the "library" folder from the
> wicket> > sample applications. EditBook.java and> > LibrarySession.java have been altered to use> Shades> > for database access. LibraryORMDictionary.java is> the> > only new file required.
> >> > Please let me know what you think. Also, I do not> have> > a website for Shades yet but I hope to find the> right> > venue for open sourcing the code soon. (see
> attached> > zip file 'library.zippo' with library-example> directory)> >> >>-> > Using Tomcat but need to do more? Need to support
> web services, security?> > Get stuff done quickly with pre-integrated> technology to make your job> > easier> > Download IBM WebSphere Application Server v.1.0.1> based on Apache Geronimo
> >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> >
> > ___> > Wicket-user mailing list> > Wicket-user@lists.sourceforge.net> >>
https://lists.sourceforge.net/lists/listinfo/wicket-user> >> >> >> >> >-
> Using Tomcat but need to do more? Need to support> web services, security?> Get stuff done

Re: [Wicket-user] library example using Shades for O/R mapping

[Igor Vaynberg]

there is also google oss hosting which i have heard good things about. http://code.google.com i believe.-IgorOn 8/26/06, 
Eelco Hillenius <[EMAIL PROTECTED]> wrote:
We left Codehaus because we had to wait for weeks for even an answerto Jonathan's request of adding another committer (me). So we decidedto go to SF where we were less dependent on other people.SF works. I've heard good stories about 
http://developer.berlios.de/.And you could consider proposing incubation at Apache, depending onhow serious you want to get on this project.If you want a place for an example/ integration project for Wicket,
we'd happily give you access to wicket-stuff.EelcoOn 8/26/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:> We left codehaus because at that time we had some issues with the
> support. They didn't respond in time and somtimes not at all. But> Martjin may give you more details>> Juergen>> On 8/26/06, Geoff hendrey <
[EMAIL PROTECTED]> wrote:> > Hi Igor,> >> > Cool.> >> > I'm trying to find the right venue for open sourcing> > Shades, and for putting up the javadocs, etc. I was
> > wondering why you guys left codehaus?> >> > -geoff-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Eelco Hillenius]

We left Codehaus because we had to wait for weeks for even an answer
to Jonathan's request of adding another committer (me). So we decided
to go to SF where we were less dependent on other people.

SF works. I've heard good stories about http://developer.berlios.de/.
And you could consider proposing incubation at Apache, depending on
how serious you want to get on this project.

If you want a place for an example/ integration project for Wicket,
we'd happily give you access to wicket-stuff.

Eelco

On 8/26/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
> We left codehaus because at that time we had some issues with the
> support. They didn't respond in time and somtimes not at all. But
> Martjin may give you more details
>
> Juergen
>
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
> > Hi Igor,
> >
> > Cool.
> >
> > I'm trying to find the right venue for open sourcing
> > Shades, and for putting up the javadocs, etc. I was
> > wondering why you guys left codehaus?
> >
> > -geoff

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Juergen Donnerstag]

We left codehaus because at that time we had some issues with the
support. They didn't respond in time and somtimes not at all. But
Martjin may give you more details

Juergen

On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
> Hi Igor,
>
> Cool.
>
> I'm trying to find the right venue for open sourcing
> Shades, and for putting up the javadocs, etc. I was
> wondering why you guys left codehaus?
>
> -geoff
>
> --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
>
> > ive read your blog, and agree with some points you
> > make about full orm
> > solutions. but as i said i couldnt grasp everything
> > from looking at the code
> > youve provided. are you planning on writing
> > tutorials for shades in the near
> > future as it sounds appealing.
> >
> > -Igor
> >
> >
> > On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > Sure - but honestly I don't want to convince
> > anyone
> > > they need Shades.
> > >
> > > One problem I found with JDO was that the
> > > PersistenceManager was not serializable. Another
> > is
> > > that detachment had to be handled explicitely.
> > >
> > > In Shades all pojo's are inherently detached.
> > Change
> > > tracking is automagic. The DatabaseSession is
> > > ultra-leightweight and totally appropriate for
> > keeping
> > > in a Session.
> > >
> > > A big innovation in Shades is how identity is
> > handled
> > > - that really solved a lot of problems for me
> > related
> > > to change of identity within transactions.
> > Identity is
> > > a much more fluid concept in Shades, due to the
> > > dynamic ORMapping interface, which you can even
> > > implement on the fly as an anonynmous inner class.
> > >
> > > To be clear, I found ways to make JDO work just
> > fine
> > > with Wicket. Certainly JDO was a huge step forward
> > in
> > > making it easier to use Pojo-based frameworks like
> > > Wicket.
> > >
> > > I blogged a bit on my motivation for Shades:
> > > http://notskateboarding.blogspot.com/
> > >
> > > -geoff
> > >
> > >
> > >
> > > --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > >
> > > > i glanced over the code - but i dont get it
> > after
> > > > the first glance. perhaps
> > > > you can explain what difficulties you hit when
> > using
> > > > wicket and an orm to
> > > > help us better understand.
> > > >
> > > > seems to me like you are trying to work with a
> > ui
> > > > connected to a persistence
> > > > layer - without a service layer in between. have
> > you
> > > > seen databinder which
> > > > glues wicket and hibernate together?
> > > >
> > > > also your point about wicket and tapestry -
> > wicket
> > > > is much more flexible
> > > > because it has IModel which gives you an extra
> > layer
> > > > of indirection that can
> > > > hide a lot of orm logic and make the code
> > > > cleaner/easier.
> > > >
> > > > -Igor
> > > >
> > > >
> > > > On 8/26/06, Geoff hendrey
> > <[EMAIL PROTECTED]>
> > > > wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > I was one of the early users of Wicket before
> > 1.0.
> > > > I
> > > > > did a lot of work to use Wicket with my JDO
> > > > > implementation JDOMax (no longer supported).
> > In
> > > > the
> > > > > process I learned a lot about why it is harder
> > > > than it
> > > > > has to be to use many ORM frameworks with
> > Wicket
> > > > and
> > > > > Tapestry.
> > > > >
> > > > > I'm a member of JSR 243 Java Data Objects
> > Experts
> > > > > Group, and I advocated hard within that spec
> > for
> > > > the
> > > > > "fixing" of the JDO spec with regard to
> > > > > non-transaction-write behavior, along with
> > Eric
> > > > Samson
> > > > > and others. The JDO group  was receptive,
> > having
> > > > > gotten similar feedback from Howard Lewis Ship
> > of
> > > > > Tapestry. I believe this change will benefit
> > > > Wicket
> > > > > users, and make it much easier to use JDO 2.0
> > than
> > > > JDO
> > > > > 1.1, from Wicket.
> > > > >
> > > > > However, I still wasn't satisfied that it was
> > > > "easy"
> > > > > to do ORM from Wicket or Tapestry. So I
> > started a
> > > > new
> > > > > project, based on what I learned -- it's a
> > better
> > > > way
> > > > > to do ORM -- I call it Shades. Following the
> > > > wicket
> > > > > style,Shades works without any XML
> > configuration.
> > > > >
> > > > > Rather than make this any longer-winded, I
> > thought
> > > > I
> > > > > would just begin passing back some code,
> > showing
> > > > the
> > > > > Library sample application using Shades. The
> > > > attached
> > > > > zipfile is just the "library" folder from the
> > > > wicket
> > > > > sample applications. EditBook.java and
> > > > > LibrarySession.java have been altered to use
> > > > Shades
> > > > > for database access. LibraryORMDictionary.java
> > is
> > > > the
> > > > > only new file required.
> > > > >
> > > > > Please let me know what you think. Also, I do
> > not
> > > > have
> > > > > a website for Shades yet but I hope to find
> > the
> > > > right
> > > > > venue for open sourcing the

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Hi Igor,

Cool.

I'm trying to find the right venue for open sourcing
Shades, and for putting up the javadocs, etc. I was
wondering why you guys left codehaus?

-geoff

--- Igor Vaynberg <[EMAIL PROTECTED]> wrote:

> ive read your blog, and agree with some points you
> make about full orm
> solutions. but as i said i couldnt grasp everything
> from looking at the code
> youve provided. are you planning on writing
> tutorials for shades in the near
> future as it sounds appealing.
> 
> -Igor
> 
> 
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:
> >
> > Sure - but honestly I don't want to convince
> anyone
> > they need Shades.
> >
> > One problem I found with JDO was that the
> > PersistenceManager was not serializable. Another
> is
> > that detachment had to be handled explicitely.
> >
> > In Shades all pojo's are inherently detached.
> Change
> > tracking is automagic. The DatabaseSession is
> > ultra-leightweight and totally appropriate for
> keeping
> > in a Session.
> >
> > A big innovation in Shades is how identity is
> handled
> > - that really solved a lot of problems for me
> related
> > to change of identity within transactions.
> Identity is
> > a much more fluid concept in Shades, due to the
> > dynamic ORMapping interface, which you can even
> > implement on the fly as an anonynmous inner class.
> >
> > To be clear, I found ways to make JDO work just
> fine
> > with Wicket. Certainly JDO was a huge step forward
> in
> > making it easier to use Pojo-based frameworks like
> > Wicket.
> >
> > I blogged a bit on my motivation for Shades:
> > http://notskateboarding.blogspot.com/
> >
> > -geoff
> >
> >
> >
> > --- Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> >
> > > i glanced over the code - but i dont get it
> after
> > > the first glance. perhaps
> > > you can explain what difficulties you hit when
> using
> > > wicket and an orm to
> > > help us better understand.
> > >
> > > seems to me like you are trying to work with a
> ui
> > > connected to a persistence
> > > layer - without a service layer in between. have
> you
> > > seen databinder which
> > > glues wicket and hibernate together?
> > >
> > > also your point about wicket and tapestry -
> wicket
> > > is much more flexible
> > > because it has IModel which gives you an extra
> layer
> > > of indirection that can
> > > hide a lot of orm logic and make the code
> > > cleaner/easier.
> > >
> > > -Igor
> > >
> > >
> > > On 8/26/06, Geoff hendrey
> <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > I was one of the early users of Wicket before
> 1.0.
> > > I
> > > > did a lot of work to use Wicket with my JDO
> > > > implementation JDOMax (no longer supported).
> In
> > > the
> > > > process I learned a lot about why it is harder
> > > than it
> > > > has to be to use many ORM frameworks with
> Wicket
> > > and
> > > > Tapestry.
> > > >
> > > > I'm a member of JSR 243 Java Data Objects
> Experts
> > > > Group, and I advocated hard within that spec
> for
> > > the
> > > > "fixing" of the JDO spec with regard to
> > > > non-transaction-write behavior, along with
> Eric
> > > Samson
> > > > and others. The JDO group  was receptive,
> having
> > > > gotten similar feedback from Howard Lewis Ship
> of
> > > > Tapestry. I believe this change will benefit
> > > Wicket
> > > > users, and make it much easier to use JDO 2.0
> than
> > > JDO
> > > > 1.1, from Wicket.
> > > >
> > > > However, I still wasn't satisfied that it was
> > > "easy"
> > > > to do ORM from Wicket or Tapestry. So I
> started a
> > > new
> > > > project, based on what I learned -- it's a
> better
> > > way
> > > > to do ORM -- I call it Shades. Following the
> > > wicket
> > > > style,Shades works without any XML
> configuration.
> > > >
> > > > Rather than make this any longer-winded, I
> thought
> > > I
> > > > would just begin passing back some code,
> showing
> > > the
> > > > Library sample application using Shades. The
> > > attached
> > > > zipfile is just the "library" folder from the
> > > wicket
> > > > sample applications. EditBook.java and
> > > > LibrarySession.java have been altered to use
> > > Shades
> > > > for database access. LibraryORMDictionary.java
> is
> > > the
> > > > only new file required.
> > > >
> > > > Please let me know what you think. Also, I do
> not
> > > have
> > > > a website for Shades yet but I hope to find
> the
> > > right
> > > > venue for open sourcing the code soon. (see
> > > attached
> > > > zip file 'library.zippo' with library-example
> > > directory)
> > > >
> > > >
> > >
> >
>
-
> > > > Using Tomcat but need to do more? Need to
> support
> > > web services, security?
> > > > Get stuff done quickly with pre-integrated
> > > technology to make your job
> > > > easier
> > > > Download IBM WebSphere Application Server
> v.1.0.1
> > > based on Apache Geronimo
> > > >
> > >
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&d

Re: [Wicket-user] library example using Shades for O/R mapping

[Igor Vaynberg]

ive read your blog, and agree with some points you make about full orm solutions. but as i said i couldnt grasp everything from looking at the code youve provided. are you planning on writing tutorials for shades in the near future as it sounds appealing.
-IgorOn 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
Sure - but honestly I don't want to convince anyonethey need Shades.One problem I found with JDO was that thePersistenceManager was not serializable. Another isthat detachment had to be handled explicitely.
In Shades all pojo's are inherently detached. Changetracking is automagic. The DatabaseSession isultra-leightweight and totally appropriate for keepingin a Session.A big innovation in Shades is how identity is handled
- that really solved a lot of problems for me relatedto change of identity within transactions. Identity isa much more fluid concept in Shades, due to thedynamic ORMapping interface, which you can even
implement on the fly as an anonynmous inner class.To be clear, I found ways to make JDO work just finewith Wicket. Certainly JDO was a huge step forward inmaking it easier to use Pojo-based frameworks like
Wicket.I blogged a bit on my motivation for Shades:http://notskateboarding.blogspot.com/-geoff--- Igor Vaynberg <
[EMAIL PROTECTED]> wrote:> i glanced over the code - but i dont get it after> the first glance. perhaps> you can explain what difficulties you hit when using> wicket and an orm to
> help us better understand.>> seems to me like you are trying to work with a ui> connected to a persistence> layer - without a service layer in between. have you> seen databinder which
> glues wicket and hibernate together?>> also your point about wicket and tapestry - wicket> is much more flexible> because it has IModel which gives you an extra layer> of indirection that can
> hide a lot of orm logic and make the code> cleaner/easier.>> -Igor>>> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:> >> > Hi All,> >> > I was one of the early users of Wicket before 1.0.> I> > did a lot of work to use Wicket with my JDO> > implementation JDOMax (no longer supported). In
> the> > process I learned a lot about why it is harder> than it> > has to be to use many ORM frameworks with Wicket> and> > Tapestry.> >> > I'm a member of JSR 243 Java Data Objects Experts
> > Group, and I advocated hard within that spec for> the> > "fixing" of the JDO spec with regard to> > non-transaction-write behavior, along with Eric> Samson> > and others. The JDO group  was receptive, having
> > gotten similar feedback from Howard Lewis Ship of> > Tapestry. I believe this change will benefit> Wicket> > users, and make it much easier to use JDO 2.0 than> JDO> > 
1.1, from Wicket.> >> > However, I still wasn't satisfied that it was> "easy"> > to do ORM from Wicket or Tapestry. So I started a> new> > project, based on what I learned -- it's a better
> way> > to do ORM -- I call it Shades. Following the> wicket> > style,Shades works without any XML configuration.> >> > Rather than make this any longer-winded, I thought
> I> > would just begin passing back some code, showing> the> > Library sample application using Shades. The> attached> > zipfile is just the "library" folder from the
> wicket> > sample applications. EditBook.java and> > LibrarySession.java have been altered to use> Shades> > for database access. LibraryORMDictionary.java is> the> > only new file required.
> >> > Please let me know what you think. Also, I do not> have> > a website for Shades yet but I hope to find the> right> > venue for open sourcing the code soon. (see
> attached> > zip file 'library.zippo' with library-example> directory)> >> >>-> > Using Tomcat but need to do more? Need to support
> web services, security?> > Get stuff done quickly with pre-integrated> technology to make your job> > easier> > Download IBM WebSphere Application Server v.1.0.1> based on Apache Geronimo
> >>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642> >
> > ___> > Wicket-user mailing list> > Wicket-user@lists.sourceforge.net> >>
https://lists.sourceforge.net/lists/listinfo/wicket-user> >> >> >> >> >-
> Using Tomcat but need to do more? Need to support> web services, security?> Get stuff done quickly with pre-integrated> technology to make your job easier> Download IBM WebSphere Application Server 
v.1.0.1> based on Apache Geronimo>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>___> Wicket-user mailing list> Wicket-user@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wicket-user>-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technol

Re: [Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Sure - but honestly I don't want to convince anyone
they need Shades. 

One problem I found with JDO was that the
PersistenceManager was not serializable. Another is
that detachment had to be handled explicitely.

In Shades all pojo's are inherently detached. Change
tracking is automagic. The DatabaseSession is
ultra-leightweight and totally appropriate for keeping
in a Session. 

A big innovation in Shades is how identity is handled
- that really solved a lot of problems for me related
to change of identity within transactions. Identity is
a much more fluid concept in Shades, due to the
dynamic ORMapping interface, which you can even
implement on the fly as an anonynmous inner class.

To be clear, I found ways to make JDO work just fine
with Wicket. Certainly JDO was a huge step forward in
making it easier to use Pojo-based frameworks like
Wicket. 

I blogged a bit on my motivation for Shades:
http://notskateboarding.blogspot.com/

-geoff



--- Igor Vaynberg <[EMAIL PROTECTED]> wrote:

> i glanced over the code - but i dont get it after
> the first glance. perhaps
> you can explain what difficulties you hit when using
> wicket and an orm to
> help us better understand.
> 
> seems to me like you are trying to work with a ui
> connected to a persistence
> layer - without a service layer in between. have you
> seen databinder which
> glues wicket and hibernate together?
> 
> also your point about wicket and tapestry - wicket
> is much more flexible
> because it has IModel which gives you an extra layer
> of indirection that can
> hide a lot of orm logic and make the code
> cleaner/easier.
> 
> -Igor
> 
> 
> On 8/26/06, Geoff hendrey <[EMAIL PROTECTED]>
> wrote:
> >
> > Hi All,
> >
> > I was one of the early users of Wicket before 1.0.
> I
> > did a lot of work to use Wicket with my JDO
> > implementation JDOMax (no longer supported). In
> the
> > process I learned a lot about why it is harder
> than it
> > has to be to use many ORM frameworks with Wicket
> and
> > Tapestry.
> >
> > I'm a member of JSR 243 Java Data Objects Experts
> > Group, and I advocated hard within that spec for
> the
> > "fixing" of the JDO spec with regard to
> > non-transaction-write behavior, along with Eric
> Samson
> > and others. The JDO group  was receptive, having
> > gotten similar feedback from Howard Lewis Ship of
> > Tapestry. I believe this change will benefit
> Wicket
> > users, and make it much easier to use JDO 2.0 than
> JDO
> > 1.1, from Wicket.
> >
> > However, I still wasn't satisfied that it was
> "easy"
> > to do ORM from Wicket or Tapestry. So I started a
> new
> > project, based on what I learned -- it's a better
> way
> > to do ORM -- I call it Shades. Following the
> wicket
> > style,Shades works without any XML configuration.
> >
> > Rather than make this any longer-winded, I thought
> I
> > would just begin passing back some code, showing
> the
> > Library sample application using Shades. The
> attached
> > zipfile is just the "library" folder from the
> wicket
> > sample applications. EditBook.java and
> > LibrarySession.java have been altered to use
> Shades
> > for database access. LibraryORMDictionary.java is
> the
> > only new file required.
> >
> > Please let me know what you think. Also, I do not
> have
> > a website for Shades yet but I hope to find the
> right
> > venue for open sourcing the code soon. (see
> attached
> > zip file 'library.zippo' with library-example
> directory)
> >
> >
>
-
> > Using Tomcat but need to do more? Need to support
> web services, security?
> > Get stuff done quickly with pre-integrated
> technology to make your job
> > easier
> > Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >
> > ___
> > Wicket-user mailing list
> > Wicket-user@lists.sourceforge.net
> >
>
https://lists.sourceforge.net/lists/listinfo/wicket-user
> >
> >
> >
> >
> >
-
> Using Tomcat but need to do more? Need to support
> web services, security?
> Get stuff done quickly with pre-integrated
> technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1
> based on Apache Geronimo
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
>
https://lists.sourceforge.net/lists/listinfo/wicket-user
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=

Re: [Wicket-user] library example using Shades for O/R mapping

[Landry Soules]

:-( That's just what lots of people say in java forums when a new 
Wicket release is announced :
"We already have [replace with the framework you think is the market 
leader] , why the hell should we learn a new one ?"
One of java's strength is in the choice we have to make our job done  :-)


Korbinian Bachl a écrit :
> hi,
>
> my thought is: with EJB3 and hibernate (and both together if you want) - why
> do we need more ?
>
> regards,
>
> korbinian 
>
>   
>> -Ursprüngliche Nachricht-
>> Von: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] Im Auftrag 
>> von Geoff hendrey
>> Gesendet: Samstag, 26. August 2006 18:54
>> An: Wicket-user@lists.sourceforge.net
>> Betreff: [Wicket-user] library example using Shades for O/R mapping
>>
>> Hi All,
>>
>> I was one of the early users of Wicket before 1.0. I did a 
>> lot of work to use Wicket with my JDO implementation JDOMax 
>> (no longer supported). In the process I learned a lot about 
>> why it is harder than it has to be to use many ORM frameworks 
>> with Wicket and Tapestry.
>>
>> I'm a member of JSR 243 Java Data Objects Experts Group, and 
>> I advocated hard within that spec for the "fixing" of the JDO 
>> spec with regard to non-transaction-write behavior, along 
>> with Eric Samson and others. The JDO group  was receptive, 
>> having gotten similar feedback from Howard Lewis Ship of 
>> Tapestry. I believe this change will benefit Wicket users, 
>> and make it much easier to use JDO 2.0 than JDO 1.1, from Wicket.
>>
>> However, I still wasn't satisfied that it was "easy"
>> to do ORM from Wicket or Tapestry. So I started a new 
>> project, based on what I learned -- it's a better way to do 
>> ORM -- I call it Shades. Following the wicket style,Shades 
>> works without any XML configuration.
>>
>> Rather than make this any longer-winded, I thought I would 
>> just begin passing back some code, showing the Library sample 
>> application using Shades. The attached zipfile is just the 
>> "library" folder from the wicket sample applications. 
>> EditBook.java and LibrarySession.java have been altered to 
>> use Shades for database access. LibraryORMDictionary.java is 
>> the only new file required.
>>
>> Please let me know what you think. Also, I do not have a 
>> website for Shades yet but I hope to find the right venue for 
>> open sourcing the code soon. (see attached zip file 
>> 'library.zippo' with library-example directory)
>>
>> 
>
>
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Wicket-user mailing list
> Wicket-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
>   


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Igor Vaynberg]

i glanced over the code - but i dont get it after the first glance. perhaps you can explain what difficulties you hit when using wicket and an orm to help us better understand.seems to me like you are trying to work with a ui connected to a persistence layer - without a service layer in between. have you seen databinder which glues wicket and hibernate together?
also your point about wicket and tapestry - wicket is much more flexible because it has IModel which gives you an extra layer of indirection that can hide a lot of orm logic and make the code cleaner/easier.
-IgorOn 8/26/06, Geoff hendrey <[EMAIL PROTECTED]> wrote:
Hi All,I was one of the early users of Wicket before 1.0. Idid a lot of work to use Wicket with my JDOimplementation JDOMax (no longer supported). In theprocess I learned a lot about why it is harder than it
has to be to use many ORM frameworks with Wicket andTapestry.I'm a member of JSR 243 Java Data Objects ExpertsGroup, and I advocated hard within that spec for the"fixing" of the JDO spec with regard to
non-transaction-write behavior, along with Eric Samsonand others. The JDO group  was receptive, havinggotten similar feedback from Howard Lewis Ship ofTapestry. I believe this change will benefit Wicket
users, and make it much easier to use JDO 2.0 than JDO1.1, from Wicket.However, I still wasn't satisfied that it was "easy"to do ORM from Wicket or Tapestry. So I started a newproject, based on what I learned -- it's a better way
to do ORM -- I call it Shades. Following the wicketstyle,Shades works without any XML configuration.Rather than make this any longer-winded, I thought Iwould just begin passing back some code, showing the
Library sample application using Shades. The attachedzipfile is just the "library" folder from the wicketsample applications. EditBook.java andLibrarySession.java have been altered to use Shades
for database access. LibraryORMDictionary.java is theonly new file required.Please let me know what you think. Also, I do not havea website for Shades yet but I hope to find the rightvenue for open sourcing the code soon. (see attached
zip file 'library.zippo' with library-example directory)-Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___Wicket-user mailing list
Wicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Igor Vaynberg]

because there is always an opportunity to make the wheel rounder - aka innovation :)-IgorOn 8/26/06, Korbinian Bachl <
[EMAIL PROTECTED]> wrote:hi,my thought is: with EJB3 and hibernate (and both together if you want) - why
do we need more ?regards,korbinian> -Ursprüngliche Nachricht-> Von: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] Im Auftrag> von Geoff hendrey> Gesendet: Samstag, 26. August 2006 18:54> An: 
Wicket-user@lists.sourceforge.net> Betreff: [Wicket-user] library example using Shades for O/R mapping>> Hi All,>> I was one of the early users of Wicket before 1.0. I did a> lot of work to use Wicket with my JDO implementation JDOMax
> (no longer supported). In the process I learned a lot about> why it is harder than it has to be to use many ORM frameworks> with Wicket and Tapestry.>> I'm a member of JSR 243 Java Data Objects Experts Group, and
> I advocated hard within that spec for the "fixing" of the JDO> spec with regard to non-transaction-write behavior, along> with Eric Samson and others. The JDO group  was receptive,> having gotten similar feedback from Howard Lewis Ship of
> Tapestry. I believe this change will benefit Wicket users,> and make it much easier to use JDO 2.0 than JDO 1.1, from Wicket.>> However, I still wasn't satisfied that it was "easy"
> to do ORM from Wicket or Tapestry. So I started a new> project, based on what I learned -- it's a better way to do> ORM -- I call it Shades. Following the wicket style,Shades> works without any XML configuration.
>> Rather than make this any longer-winded, I thought I would> just begin passing back some code, showing the Library sample> application using Shades. The attached zipfile is just the> "library" folder from the wicket sample applications.
> EditBook.java and LibrarySession.java have been altered to> use Shades for database access. LibraryORMDictionary.java is> the only new file required.>> Please let me know what you think. Also, I do not have a
> website for Shades yet but I hope to find the right venue for> open sourcing the code soon. (see attached zip file> 'library.zippo' with library-example directory)>-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing listWicket-user@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wicket-user

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] library example using Shades for O/R mapping

[Korbinian Bachl]

hi,

my thought is: with EJB3 and hibernate (and both together if you want) - why
do we need more ?

regards,

korbinian 

> -Ursprüngliche Nachricht-
> Von: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] Im Auftrag 
> von Geoff hendrey
> Gesendet: Samstag, 26. August 2006 18:54
> An: Wicket-user@lists.sourceforge.net
> Betreff: [Wicket-user] library example using Shades for O/R mapping
> 
> Hi All,
> 
> I was one of the early users of Wicket before 1.0. I did a 
> lot of work to use Wicket with my JDO implementation JDOMax 
> (no longer supported). In the process I learned a lot about 
> why it is harder than it has to be to use many ORM frameworks 
> with Wicket and Tapestry.
> 
> I'm a member of JSR 243 Java Data Objects Experts Group, and 
> I advocated hard within that spec for the "fixing" of the JDO 
> spec with regard to non-transaction-write behavior, along 
> with Eric Samson and others. The JDO group  was receptive, 
> having gotten similar feedback from Howard Lewis Ship of 
> Tapestry. I believe this change will benefit Wicket users, 
> and make it much easier to use JDO 2.0 than JDO 1.1, from Wicket.
> 
> However, I still wasn't satisfied that it was "easy"
> to do ORM from Wicket or Tapestry. So I started a new 
> project, based on what I learned -- it's a better way to do 
> ORM -- I call it Shades. Following the wicket style,Shades 
> works without any XML configuration.
> 
> Rather than make this any longer-winded, I thought I would 
> just begin passing back some code, showing the Library sample 
> application using Shades. The attached zipfile is just the 
> "library" folder from the wicket sample applications. 
> EditBook.java and LibrarySession.java have been altered to 
> use Shades for database access. LibraryORMDictionary.java is 
> the only new file required.
> 
> Please let me know what you think. Also, I do not have a 
> website for Shades yet but I hope to find the right venue for 
> open sourcing the code soon. (see attached zip file 
> 'library.zippo' with library-example directory)
> 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] library example using Shades for O/R mapping

[Geoff hendrey]

Hi All,

I was one of the early users of Wicket before 1.0. I
did a lot of work to use Wicket with my JDO
implementation JDOMax (no longer supported). In the
process I learned a lot about why it is harder than it
has to be to use many ORM frameworks with Wicket and
Tapestry.

I'm a member of JSR 243 Java Data Objects Experts
Group, and I advocated hard within that spec for the
"fixing" of the JDO spec with regard to
non-transaction-write behavior, along with Eric Samson
and others. The JDO group  was receptive, having
gotten similar feedback from Howard Lewis Ship of
Tapestry. I believe this change will benefit Wicket
users, and make it much easier to use JDO 2.0 than JDO
1.1, from Wicket.

However, I still wasn't satisfied that it was "easy"
to do ORM from Wicket or Tapestry. So I started a new
project, based on what I learned -- it's a better way
to do ORM -- I call it Shades. Following the wicket
style,Shades works without any XML configuration.

Rather than make this any longer-winded, I thought I
would just begin passing back some code, showing the
Library sample application using Shades. The attached
zipfile is just the "library" folder from the wicket
sample applications. EditBook.java and
LibrarySession.java have been altered to use Shades
for database access. LibraryORMDictionary.java is the
only new file required.

Please let me know what you think. Also, I do not have
a website for Shades yet but I hope to find the right
venue for open sourcing the code soon. (see attached
zip file 'library.zippo' with library-example directory)

library.zippo
Description: 710569467-library.zippo
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user