You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Francisco Diaz Trepat - gmail <fr...@gmail.com> on 2010/10/04 01:40:04 UTC
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
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
<ch...@stepaheadsoftware.com>wrote:
> 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.diaztrepat@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-unsubscribe@wicket.apache.org
> >For additional commands, e-mail: users-help@wicket.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
RE: New App - Best Practices
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
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.diaztrepat@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-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
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
<je...@wickettraining.com>wrote:
> >
> > 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
Posted by Jeremy Thomerson <je...@wickettraining.com>.
>
> 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
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
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 <7z...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: New App - Best Practices
Posted by 7zark7 <7z...@gmail.com>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
Right indeed...
On Sun, Oct 3, 2010 at 11:09 PM, Sam Stainsby <
sam@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New App - Best Practices
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
Aha...
On Sun, Oct 3, 2010 at 11:59 PM, Chris Colman
<ch...@stepaheadsoftware.com>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.
>
> 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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New App - Best Practices
Posted by Erdinc <ko...@yahoo.com>.
My suggestion : Wicket / Spring / Cayenne ORM
________________________________
From: Josh Kamau <jo...@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 <sam@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New App - Best Practices
Posted by Josh Kamau <jo...@gmail.com>.
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 <sam@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New App - Best Practices
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: New App - Best Practices
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>> 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-unsubscribe@wicket.apache.org
>For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Brian Topping <to...@codehaus.org>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: New App - Best Practices
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: New App - Best Practices
Posted by Chris Colman <ch...@stepaheadsoftware.com>.
>> 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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Francisco Diaz Trepat - gmail <fr...@gmail.com>.
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 <sam@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: New App - Best Practices
Posted by Sam Stainsby <sa...@sustainablesoftware.com.au>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by James Carman <ja...@carmanconsulting.com>.
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" <to...@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 <to...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: New App - Best Practices
Posted by Brian Topping <to...@codehaus.org>.
On Oct 3, 2010, at 11:19 PM, Jeremy Thomerson wrote:
> On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping <to...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: New App - Best Practices
Posted by Jeremy Thomerson <je...@wickettraining.com>.
On Sun, Oct 3, 2010 at 9:17 PM, Brian Topping <to...@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
Posted by Brian Topping <to...@codehaus.org>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org