Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
Hi jeremy, thanks for answering.

I mostly wanted a new technology, and maybe learn new ways and help with
testing and reporting.

Thanks again,
f(t)

On Sun, Oct 3, 2010 at 8:50 PM, Jeremy Thomerson
jer...@wickettraining.comwrote:

 
  So, ideas on what to use?
 
  UI = Wicket.
 + 1.4?
 + 1.5?
  middle layer?
  Persistence?
 

 Wicket / Spring / Hibernate is a very common setup, so you will have an
 easy
 time finding examples, help, etc.

 --
 Jeremy Thomerson
 http://www.wickettraining.com



RE: New App - Best Practices

2010-10-04 Thread Chris Colman
 Not really AFAIK: The ability to not have to manage fetch depths that
 JDO/DB40 gives you over raw DB40 gives you is a massive productivity
 boost (not sure if the latest DB40 supports lazy loading or not yet).

This is OT, but I feel it needs some correction.

DB4O has had transparent activation (automatic loading of references
if/
when needed) and transparent persistence (automatic update depth) for a
while now. You byte code can even be automatically instrumented with
TA/TP
(but note code injection doesn't work with Scala, so we hand-code a few
base relationship classes with TA instead).

That's good to know. I evaluated DB40 a few years ago but the lack of
support for automatic activation/lazy loading of references if/when
needed really took away from my concept of the *ideal* transparent,
object database solution and so scared me off. I took it up with the
DB40 developers and they were adamant that 'no automatic/lazy loading'
was an intentional design strategy and a good thing - which freaked me
out a bit, making me believe DB40 would never get something I judged to
be so essential for any transparent persistence solution - glad to see
they've 'seen the light' on automatic activation now. Using
JDO/DataNucleus, with its automatic activation, over the top of DB40 was
a sneaky way of achieving that - as well as the datastore agnosticism
that brings.

You are also missing out on advantages like automatic schema updates,
DB4O's own unique ID system, and other very useful parts of the DB4O
API.

The way I use JDO I get all of those features but in a datastore
agnostic way. For unique IDs I make sure I use the default long int
OIDs. I also make sure I use unique IDs for the discriminators and avoid
the default 'package/class name' discriminator (otherwise you class info
into your datastore which is an inhibitor to refactoring). We use
Javelin MDA (www.visualclassworks.com) to generate unique discriminators
and all meta data for us so there's zero effort in making our models
persistent capable.

 In any case coding to a standard persistence interface (JDO)
 over a proprietary API is IMHO an insurance policy

I can understand that, and I think that way too in some situations, but
I
reject the notion that there is no price to pay.

We certainly haven't paid any price in terms of developer productivity
by using JDO because with byte code enhancement the persistence is truly
transparent. Perhaps there might be a slight run time performance
advantage in using DB40 direct instead of JDO over DB40 (if we went that
way eventually) but at this stage the performance is exceptional with
JDO over MySQL and it has rock solid reliability with a huge enterprise
app with 952 classes. Our app will definitely be using an object
database one day in the future and that's why we chose JDO instead of
other persistent frameworks that cement the future of our apps into
1970's RDBMS technology - none of us want that :)

Is DB40 starting to get used more in the enterprise world now? A few
years ago it was very popular in the embedded market (BMW use it in the
on board car computers!) but its use in large enterprise apps was
unclear. Hopefully that's changed now also.





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-04 Thread Sam Stainsby
On Mon, 04 Oct 2010 00:45:26 -0400, Brian Topping wrote:

 There's *always* a cost, but which one is cheapest (most efficient,
 easiest to use, yada yada) in the end depends on a lot of localized
 factors.  If it did not, there would be a website that every developer
 visited before starting a new project, and the anointed best
 technologies for that moment would be listed there.  Heck, you would be
 able check boxes on the list and generate a POM from it...

Very true. It is precisely the diversity of what the cost (TCO, etc.) is 
that allows project like Wicket to get off the ground. If nobody had been 
willing to try doing J2EE in a different way, then where would Wicket be?


Cheers,
Sam.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
Sam you are absolutely right about my subject, it is not best practices.

Best Practices are Safe, Robust, Well Tested, Etc.

I want new innovating ideas.

Thanks for pointing that up, and last night I was checking DB4O up... (my
life is sad... but I was happy :-)

f(t)

On Sun, Oct 3, 2010 at 9:16 PM, Sam Stainsby s...@sustainablesoftware.com.au
 wrote:

 On Sun, 03 Oct 2010 20:40:04 -0300, Francisco Diaz Trepat - gmail wrote:

  Now I am free to do whatever I want. This is the worst part. :-)

 I understand that feeling! When I started designing our web app
 framework, I picked the technologies from an enormous set of options that
 I thought would make app development as rapid and robust as possible. The
 title of your message best practices suggests though that you want to
 stick to the mainstream solutions.

  So, ideas on what to use?

 If you want to avoid ORMs completely, you could consider an object
 database like DB4O as we have in Granite. Granite is currently is not
 quite complete and poorly documented, and written Scala not Java, but
 there is surely something you can use there if you want to go down a that
 path - even if its just ideas and sample code.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
Thanks Chris, I'll never heard of it. It sounds pretty cool. I'll check it
out.

On Sun, Oct 3, 2010 at 10:33 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 We use Wicket with DataNucleus (JDO) www.datanucleus.org as the
 persistence layer. The persistence side is truly transparent and it
 performs really well - your model objects don't need any extra methods
 and you are free to model and code just as if you were dealing with an
 'in memory' only set of objects.

 We also use the 'Exposed Domain Model' pattern/strategy which is another
 productivity boost over many of the other more traditional approaches to
 persistence.

 Regards,
 Chris

 -Original Message-
 From: Francisco Diaz Trepat - gmail
 [mailto:francisco.diaztre...@gmail.com]
 Sent: Monday, 4 October 2010 10:40 AM
 To: Wicket-Users
 Subject: New App - Best Practices
 
 Hi I've tested wicket before it was in the apache incubator and found
 it to be awesome, since then we have adopted it and I have been
 migrating all legacy applications for my company for the last 3 years
 aprox.
 
 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business
 
 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.
 
 At work I use wicket with an ingenious CORBA server, courtesy of the
 legacy applications.
 
 Now I am free to do whatever I want. This is the worst part. :-)
 
 I would like to help out and test maybe wicket 1.5 and some good
 database solution.
 
 Can you share some comments or recommendations on what to do?
 For Instance, I once read about Active Objects, I pretty much liked
 the idea and built some prototypes, but now the site is exactly the
 same and found their latest released is from 2008. So that is no so
 edgy...
 
 I don't wish to use hibernate, but could be some other object
 relational mapping, even hibernate if you insist... :-)
 
 So, ideas on what to use?
 
 UI = Wicket.
 + 1.4?
 + 1.5?
 middle layer?
 Persistence?
 
 Thanks in advance,
 f(t)
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
Right indeed...

On Sun, Oct 3, 2010 at 11:09 PM, Sam Stainsby 
s...@sustainablesoftware.com.au wrote:

 On Mon, 04 Oct 2010 11:36:48 +1000, Chris Colman wrote:


  Forgot to mention: DataNucleus allows you to use a wide range of
  datastores and switch between them without any code changes: eg., all
  the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
  others), Google Application Engine (GAE), LDAP, Excel plus loads more.
  If you don't want to commit to an ORM/RDBMS then DN would provide that
  level of protection against datastore 'lock in'.

 Keep in mind though that adding a layer like this over DB4O will mostly
 remove the advantages that would make you want to choose DB4O in the
 first place.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
Aha...

On Sun, Oct 3, 2010 at 11:59 PM, Chris Colman
chr...@stepaheadsoftware.comwrote:

  Forgot to mention: DataNucleus allows you to use a wide range of
  datastores and switch between them without any code changes: eg., all
  the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and
 some
  others), Google Application Engine (GAE), LDAP, Excel plus loads
 more.
  If you don't want to commit to an ORM/RDBMS then DN would provide
 that
  level of protection against datastore 'lock in'.
 
 Keep in mind though that adding a layer like this over DB4O will mostly
 remove the advantages that would make you want to choose DB4O in the
 first place.

 Not really AFAIK: The ability to not have to manage fetch depths that
 JDO/DB40 gives you over raw DB40 gives you is a massive productivity
 boost (not sure if the latest DB40 supports lazy loading or not yet). In
 any case coding to a standard persistence interface (JDO) over a
 proprietary API is IMHO an insurance policy I am prepared to invest in
 given the performance overheads are so miniscule.

 ... but this is probably a discussion best held elsewhere... I think we
 all agree in terms of UI frameworks Wicket is definitely the best there
 is!

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
LOL@Couch potato idea of my self

On Mon, Oct 4, 2010 at 8:41 AM, Kent Tong sm-k...@cpttm.org.mo wrote:

  Now I have to build a small app to manage small accounting and
  logistics for my wife's Business
 
  She is opening a small printing shop for small business labels, such
  as wine bottle labels, clothing labels, bags, etc.

 I am quite surprised to see so many suggestions, while all there
 is known is the above brief description :-)

 My suggestion is to avoid writing any code at all :-) For example,
 check out the open source, free or paid applications that can do
 what you want (eg, sql-ledger for accounting), then customize them
 as needed.

 --
 Kent Tong
 Useful news for network admins at
 http://www2.cpttm.org.mo/cyberlab/netadmin-news


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Sam Stainsby
On Mon, 04 Oct 2010 17:49:07 +1000, Chris Colman wrote:

You are also missing out on advantages like automatic schema updates,
DB4O's own unique ID system, and other very useful parts of the DB4O
 API.
 
 The way I use JDO I get all of those features but in a datastore
 agnostic way.

This is really interesting, albeit your solution uses non-open source 
tools that I could not specify as a dependency in our open source 
framework. We also didn't discuss DB4O's native queries, which are 
optimised on the fly, but we are wandering further off-topic, so I will 
send an email.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-04 Thread Francisco Diaz Trepat - gmail
LOL@100%, mathematically-proven to be superior technology in this is Wicket
;-)

Hate Spring.
Almost hate Hibernate.

This totally personal, and those with reason should abstain from taking me
seriously.

:-)

f(t)

On Sun, Oct 3, 2010 at 10:50 PM, 7zark7 7za...@gmail.com wrote:

 There's no best practices any more :-)

 Wicket/Spring/Hibernate is simple and lots of examples.
 Hibernate with JPA is super-easy to work with.

 If you want something different, NoSQL such as CouchDB is nice,
 especially if you need to store binary attachments, etc.

 My current stack is Wicket/Spring/CouchDB using Scala - but the only 100%,
 mathematically-proven to be superior technology in this is Wicket ;-)



 On 10/3/10 4:40 PM, Francisco Diaz Trepat - gmail wrote:

 Hi I've tested wicket before it was in the apache incubator and found
 it to be awesome, since then we have adopted it and I have been
 migrating all legacy applications for my company for the last 3 years
 aprox.

 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business

 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.

 At work I use wicket with an ingenious CORBA server, courtesy of the
 legacy applications.

 Now I am free to do whatever I want. This is the worst part. :-)

 I would like to help out and test maybe wicket 1.5 and some good
 database solution.

 Can you share some comments or recommendations on what to do?
 For Instance, I once read about Active Objects, I pretty much liked
 the idea and built some prototypes, but now the site is exactly the
 same and found their latest released is from 2008. So that is no so
 edgy...

 I don't wish to use hibernate, but could be some other object
 relational mapping, even hibernate if you insist... :-)

 So, ideas on what to use?

 UI = Wicket.
 + 1.4?
 + 1.5?
 middle layer?
 Persistence?

 Thanks in advance,
 f(t)

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





Re: New App - Best Practices

2010-10-04 Thread Josh Kamau
I use Wicket/Guice/JPA-Hibernate.

I think you will have to do alot of evaluation of the technologies yourself.
You have wicket for the presentation, now find a DI container and an ORM
solution and you are sorted. Normally the Presentation layer is the hard
part to decide when you are a java developer but you seem to have that taken
care off.

regards.

On Mon, Oct 4, 2010 at 1:15 PM, Sam Stainsby s...@sustainablesoftware.com.au
 wrote:

 On Mon, 04 Oct 2010 17:49:07 +1000, Chris Colman wrote:

 You are also missing out on advantages like automatic schema updates,
 DB4O's own unique ID system, and other very useful parts of the DB4O
  API.
 
  The way I use JDO I get all of those features but in a datastore
  agnostic way.

 This is really interesting, albeit your solution uses non-open source
 tools that I could not specify as a dependency in our open source
 framework. We also didn't discuss DB4O's native queries, which are
 optimised on the fly, but we are wandering further off-topic, so I will
 send an email.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: New App - Best Practices

2010-10-04 Thread Kent Tong

 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business

 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.

I am quite surprised to see so many suggestions, while all there
is known is the above brief description :-)

My suggestion is to avoid writing any code at all :-) For example,
check out the open source, free or paid applications that can do
what you want (eg, sql-ledger for accounting), then customize them
as needed.

--
Kent Tong
Useful news for network admins at 
http://www2.cpttm.org.mo/cyberlab/netadmin-news


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-04 Thread Erdinc
My suggestion : Wicket / Spring / Cayenne ORM

 




From: Josh Kamau joshnet2...@gmail.com
To: users@wicket.apache.org
Sent: Mon, October 4, 2010 1:37:45 PM
Subject: Re: New App - Best Practices

I use Wicket/Guice/JPA-Hibernate.

I think you will have to do alot of evaluation of the technologies yourself.
You have wicket for the presentation, now find a DI container and an ORM
solution and you are sorted. Normally the Presentation layer is the hard
part to decide when you are a java developer but you seem to have that taken
care off.

regards.

On Mon, Oct 4, 2010 at 1:15 PM, Sam Stainsby s...@sustainablesoftware.com.au
 wrote:

 On Mon, 04 Oct 2010 17:49:07 +1000, Chris Colman wrote:

 You are also missing out on advantages like automatic schema updates,
 DB4O's own unique ID system, and other very useful parts of the DB4O
  API.
 
  The way I use JDO I get all of those features but in a datastore
  agnostic way.

 This is really interesting, albeit your solution uses non-open source
 tools that I could not specify as a dependency in our open source
 framework. We also didn't discuss DB4O's native queries, which are
 optimised on the fly, but we are wandering further off-topic, so I will
 send an email.


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org





  

New App - Best Practices

2010-10-03 Thread Francisco Diaz Trepat - gmail
Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
+ 1.4?
+ 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Jeremy Thomerson

 So, ideas on what to use?

 UI = Wicket.
+ 1.4?
+ 1.5?
 middle layer?
 Persistence?


Wicket / Spring / Hibernate is a very common setup, so you will have an easy
time finding examples, help, etc.

-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Sun, 03 Oct 2010 20:40:04 -0300, Francisco Diaz Trepat - gmail wrote:

 Now I am free to do whatever I want. This is the worst part. :-)

I understand that feeling! When I started designing our web app 
framework, I picked the technologies from an enormous set of options that 
I thought would make app development as rapid and robust as possible. The 
title of your message best practices suggests though that you want to 
stick to the mainstream solutions.

 So, ideas on what to use?

If you want to avoid ORMs completely, you could consider an object 
database like DB4O as we have in Granite. Granite is currently is not 
quite complete and poorly documented, and written Scala not Java, but 
there is surely something you can use there if you want to go down a that 
path - even if its just ideas and sample code.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: New App - Best Practices

2010-10-03 Thread Chris Colman
We use Wicket with DataNucleus (JDO) www.datanucleus.org as the
persistence layer. The persistence side is truly transparent and it
performs really well - your model objects don't need any extra methods
and you are free to model and code just as if you were dealing with an
'in memory' only set of objects.

We also use the 'Exposed Domain Model' pattern/strategy which is another
productivity boost over many of the other more traditional approaches to
persistence.

Regards,
Chris

-Original Message-
From: Francisco Diaz Trepat - gmail
[mailto:francisco.diaztre...@gmail.com]
Sent: Monday, 4 October 2010 10:40 AM
To: Wicket-Users
Subject: New App - Best Practices

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
+ 1.4?
+ 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: New App - Best Practices

2010-10-03 Thread Chris Colman

 So, ideas on what to use?

If you want to avoid ORMs completely, you could consider an object
database like DB4O as we have in Granite. Granite is currently is not
quite complete and poorly documented, and written Scala not Java, but
there is surely something you can use there if you want to go down a
that
path - even if its just ideas and sample code.

Forgot to mention: DataNucleus allows you to use a wide range of
datastores and switch between them without any code changes: eg., all
the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
others), Google Application Engine (GAE), LDAP, Excel plus loads more.
If you don't want to commit to an ORM/RDBMS then DN would provide that
level of protection against datastore 'lock in'.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread 7zark7

There's no best practices any more :-)

Wicket/Spring/Hibernate is simple and lots of examples.
Hibernate with JPA is super-easy to work with.

If you want something different, NoSQL such as CouchDB is nice, 
especially if you need to store binary attachments, etc.


My current stack is Wicket/Spring/CouchDB using Scala - but the only 
100%, mathematically-proven to be superior technology in this is Wicket ;-)



On 10/3/10 4:40 PM, Francisco Diaz Trepat - gmail wrote:

Hi I've tested wicket before it was in the apache incubator and found
it to be awesome, since then we have adopted it and I have been
migrating all legacy applications for my company for the last 3 years
aprox.

Now I have to build a small app to manage small accounting and
logistics for my wife's Business

She is opening a small printing shop for small business labels, such
as wine bottle labels, clothing labels, bags, etc.

At work I use wicket with an ingenious CORBA server, courtesy of the
legacy applications.

Now I am free to do whatever I want. This is the worst part. :-)

I would like to help out and test maybe wicket 1.5 and some good
database solution.

Can you share some comments or recommendations on what to do?
For Instance, I once read about Active Objects, I pretty much liked
the idea and built some prototypes, but now the site is exactly the
same and found their latest released is from 2008. So that is no so
edgy...

I don't wish to use hibernate, but could be some other object
relational mapping, even hibernate if you insist... :-)

So, ideas on what to use?

UI = Wicket.
 + 1.4?
 + 1.5?
middle layer?
Persistence?

Thanks in advance,
f(t)

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Mon, 04 Oct 2010 11:36:48 +1000, Chris Colman wrote:


 Forgot to mention: DataNucleus allows you to use a wide range of
 datastores and switch between them without any code changes: eg., all
 the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and some
 others), Google Application Engine (GAE), LDAP, Excel plus loads more.
 If you don't want to commit to an ORM/RDBMS then DN would provide that
 level of protection against datastore 'lock in'.

Keep in mind though that adding a layer like this over DB4O will mostly 
remove the advantages that would make you want to choose DB4O in the 
first place.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Brian Topping
I personally use Wicket / Spring / JPA Hibernate / PostgreSQL.  Hibernate 
because I know how to tune it and I'm too busy learning other new technologies 
to focus on replacing one that is working for my needs now.  Spring because it 
helps immensely with unit testing and marginally by promoting good patterns 
(note these are two nice to have but not critical requirements for a small 
project).  I'd have to agree with the previous poster that Wicket is the one 
tried and true, money back guaranteed must have technology in the entire stack.

If you are just learning ORM for the first time, DataNucleus does look like a 
better way to go.

I would focus more on patterns and interfaces than on technologies.  Liberal 
use of patterns will keep your code honest and help you to refactor out or in 
technologies as necessary in the future.  Interfaces can always be extracted 
later, but having replaceable implementations are a huge benefit for migration 
between technologies.  You'll never get the perfect mix of technologies because 
they change all the time, but your application's domain focus will change very 
little.  The name of the game is to keep these realms as separate as possible.

One thing about Spring for a beginner is that you don't absolutely need it to 
get started with.  It's a big framework and it's core competency is dependency 
injection.  OTOH, the biggest thing it provides for small projects is a stable 
and well-maintained framework for database transactions.  If you want to use 
Spring, read the first chapter of the reference, skip to the database chapter, 
THEN skip back as necessary to fill in the gaps on how to set up the database.  
That's the fastest way to learn it.  Once you get started with it, the learning 
comes naturally.  If you use Spring, immediately learn the @SpringBean 
annotation in Wicket.

Good luck!

Brian

On Oct 3, 2010, at 7:40 PM, Francisco Diaz Trepat - gmail wrote:

 Hi I've tested wicket before it was in the apache incubator and found
 it to be awesome, since then we have adopted it and I have been
 migrating all legacy applications for my company for the last 3 years
 aprox.
 
 Now I have to build a small app to manage small accounting and
 logistics for my wife's Business
 
 She is opening a small printing shop for small business labels, such
 as wine bottle labels, clothing labels, bags, etc.
 
 At work I use wicket with an ingenious CORBA server, courtesy of the
 legacy applications.
 
 Now I am free to do whatever I want. This is the worst part. :-)
 
 I would like to help out and test maybe wicket 1.5 and some good
 database solution.
 
 Can you share some comments or recommendations on what to do?
 For Instance, I once read about Active Objects, I pretty much liked
 the idea and built some prototypes, but now the site is exactly the
 same and found their latest released is from 2008. So that is no so
 edgy...
 
 I don't wish to use hibernate, but could be some other object
 relational mapping, even hibernate if you insist... :-)
 
 So, ideas on what to use?
 
 UI = Wicket.
+ 1.4?
+ 1.5?
 middle layer?
 Persistence?
 
 Thanks in advance,
 f(t)
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 
 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



RE: New App - Best Practices

2010-10-03 Thread Chris Colman
 Forgot to mention: DataNucleus allows you to use a wide range of
 datastores and switch between them without any code changes: eg., all
 the usual RDBMSes (MySQL, Oracle etc.,), Object Databases (DB4O and
some
 others), Google Application Engine (GAE), LDAP, Excel plus loads
more.
 If you don't want to commit to an ORM/RDBMS then DN would provide
that
 level of protection against datastore 'lock in'.

Keep in mind though that adding a layer like this over DB4O will mostly
remove the advantages that would make you want to choose DB4O in the
first place.

Not really AFAIK: The ability to not have to manage fetch depths that
JDO/DB40 gives you over raw DB40 gives you is a massive productivity
boost (not sure if the latest DB40 supports lazy loading or not yet). In
any case coding to a standard persistence interface (JDO) over a
proprietary API is IMHO an insurance policy I am prepared to invest in
given the performance overheads are so miniscule.

... but this is probably a discussion best held elsewhere... I think we
all agree in terms of UI frameworks Wicket is definitely the best there
is!

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Jeremy Thomerson
On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org wrote:

 If you want to use Spring, read the first chapter of the reference, skip to
 the database chapter, THEN skip back as necessary to fill in the gaps on how
 to set up the database.  That's the fastest way to learn it.


I've worked with Brian on other projects, and he is very good with
architecture.  His advice here is sound. I would be curious just to be sure
- which reference in particular do you mean?

-- 
Jeremy Thomerson
http://www.wickettraining.com


Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

 On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org wrote:
 
 If you want to use Spring, read the first chapter of the reference, skip to
 the database chapter, THEN skip back as necessary to fill in the gaps on how
 to set up the database.  That's the fastest way to learn it.
 
 
 I've worked with Brian on other projects, and he is very good with
 architecture.  His advice here is sound. I would be curious just to be sure
 - which reference in particular do you mean?

http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/
 is what I use.  I'm not ashamed to say that I still use this page frequently, 
as I'm less about memorizing everything and more about knowing where to look 
something up fast.  

As I started to think about documentation, Wicket In Action is a must have.  
Spring In Action is probably just as good, the folks at Manning would rather 
throw away a manuscript than release a bad one, but I haven't read it.  The 
paper versions are great to take to a cafe, but definitely spend a few extra 
bucks on the PDF too.  It's more than worth the price of a couple of lattes!
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread James Carman
Make sure your Manning books don't already come with the free PDF version
before you spring (couldn't resist) for it.  When I get them from Amazon,
they sometimes come with an insert that allows you to download the PDF.
On Oct 3, 2010 11:35 PM, Brian Topping topp...@codehaus.org wrote:

 On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:

 On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping topp...@codehaus.org
wrote:

 If you want to use Spring, read the first chapter of the reference, skip
to
 the database chapter, THEN skip back as necessary to fill in the gaps on
how
 to set up the database. That's the fastest way to learn it.


 I've worked with Brian on other projects, and he is very good with
 architecture. His advice here is sound. I would be curious just to be
sure
 - which reference in particular do you mean?


http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/is
what I use. I'm not ashamed to say that I still use this page
frequently,
as I'm less about memorizing everything and more about knowing where to look
something up fast.

 As I started to think about documentation, Wicket In Action is a must
have. Spring In Action is probably just as good, the folks at Manning
would rather throw away a manuscript than release a bad one, but I haven't
read it. The paper versions are great to take to a cafe, but definitely
spend a few extra bucks on the PDF too. It's more than worth the price of a
couple of lattes!
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Sam Stainsby
On Mon, 04 Oct 2010 12:59:43 +1000, Chris Colman wrote:

Keep in mind though that adding a layer like this over DB4O will mostly
remove the advantages that would make you want to choose DB4O in the
first place.
 
 Not really AFAIK: The ability to not have to manage fetch depths that
 JDO/DB40 gives you over raw DB40 gives you is a massive productivity
 boost (not sure if the latest DB40 supports lazy loading or not yet).

This is OT, but I feel it needs some correction.

DB4O has had transparent activation (automatic loading of references if/
when needed) and transparent persistence (automatic update depth) for a 
while now. You byte code can even be automatically instrumented with TA/TP
(but note code injection doesn't work with Scala, so we hand-code a few 
base relationship classes with TA instead).

You are missing out on the main goal of DB4O: simplicity - the ability to 
store and query POJOs with zero configuration, even POJOs from other 
database-unaware APIs.

You are also missing out on advantages like automatic schema updates, 
DB4O's own unique ID system, and other very useful parts of the DB4O API.

 In any case coding to a standard persistence interface (JDO) 
 over a proprietary API is IMHO an insurance policy

I can understand that, and I think that way too in some situations, but I 
reject the notion that there is no price to pay.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: New App - Best Practices

2010-10-03 Thread Brian Topping

On Oct 3, 2010, at 11:58 PM, Sam Stainsby wrote:

 In any case coding to a standard persistence interface (JDO) 
 over a proprietary API is IMHO an insurance policy
 
 I can understand that, and I think that way too in some situations, but I 
 reject the notion that there is no price to pay.

This is where the old Total Cost of Ownership comes in to play.  The right 
technology for a particular developer or team is going to be the one that 
allows the problem domain to be solved with the least cost.  

For some developers, a lack of documentation or online examples is might cost 
more in lost time than the additional cost of laboriously setting up JPA and 
all the requisite annotations.  For others, unlearning their old habits might 
be a huge cost.  In a team environment, change can lead to politics, another 
cost.  As a project grows to include a team, potential difficulty in hiring new 
staff that is receptive to the chosen technologies also needs to be considered 
briefly (Wicket itself had this issue until recently).

There's *always* a cost, but which one is cheapest (most efficient, easiest to 
use, yada yada) in the end depends on a lot of localized factors.  If it did 
not, there would be a website that every developer visited before starting a 
new project, and the anointed best technologies for that moment would be 
listed there.  Heck, you would be able check boxes on the list and generate a 
POM from it...

Brian
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org