That would be useful...

The sort of thing I'm thinking of as a jump-start would simply revolve
around a single table, with a few sample columns,
e.g.
 CREATE TABLE EXAMPLE_TABLE (
   ID   INTEGER       NOT NULL PRIMARY KEY,
   NAME VARCHAR2 (21) NOT NULL,
   VAL  INTEGER       NOT NULL );
in Oracle SQL-speak...

I'd have thought we'd cover most of the basic requirements with a 2
page (or panel?) app.  The main page would be a pageable list view
which had the data and [edit] & [delete] links on each row, with a
[new] link at the end,
i.e.
         NAME  VAL
         n1    v1   [edit][del]
         n2    v2   [edit][del]
         n3    v3   [edit][del]
         [new]

The other half of the app would be the details page, where the details
could be entered (from [new]), edited (from [edit]) or viewed (as a
confirm from [del)
  Just a simple
         NAME   ______
         VAL    ______
         [action]   [bank]
  page should do as a basis?

  Given that, it should be just a matter of writing a little
documentation as to what to edit where to change db/table-name/add
fields, which I should be able to manage!
  Other types of column/field might be worth adding as examples, e.g.
some form of boolean or a time_stamp, but unless they're trivial for
you, I expect I can add them once there's a basic app running.

That would certainly cover the basics of a large %age of the 'admin'
app's /I've/ written in the past, but I'd be interested in comments
from others, as my apps have tended to just be internal admin/control
intranet apps, nothing too big or heavily used...

/Gwyn

On 07/10/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> Outline a small but thorough example that you think will benefit someone
> looking to use hibernate/spring/wicket combo and I can probably throw it
> together w/out the javadoc and pretty html. Maybe you can pick it up from
> there.
>
> -Igor
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> > Gwyn Evans
> > Sent: Friday, October 07, 2005 1:36 PM
> > To: wicket-user@lists.sourceforge.net
> > Subject: Re: [Wicket-user] Standard for database integration?
> > (Please!)
> >
> > I tend to agree with Nathan, in that there does seem to be a
> > lot of odd parts dotted around... Maybe they all hook
> > together, but I suspect that only if you know what you need
> > can you pull the right bits together...
> >
> > Personally, I'm not familiar with Hibernate, so don't really
> > know what I'm looking for, although I was able to pull
> > together a PageableListView app to display a table loaded via
> > Hibernate a while ago.  I'm limited to JDK 1.4, so can't use
> > annotations (and thus the later cd-app as a template).
> >
> > I'm still not sure if I'm missing something here, as even
> > that simple app required wicket-contrib-data,
> > wicket-contrib-data-hibernate-3.0 and wicket-contrib-dataview...
> >
> > What I'm personally missing is a generic (template) DB
> > web-app, that would run under JDK 1.4, that would provide
> > CRUD functionality and a pageable view...
> >
> > Any thoughts/comments?
> >
> > /Gwyn
> >
> > On 04/10/05, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > What kind of integration do you want with the dataview? The
> > dataview
> > > is a generic package and all you need to integrate it is to
> > provide a
> > > dataprovider:
> > >
> > > protected static class UsersDataProvider implements IDataProvider {
> > >                 private UserDAO getUserDao() {
> > >                         return
> > MyApplication.getInstance().getUserDao();
> > >                 }
> > >
> > >                 public Iterator iterator(int first, int count) {
> > >                         return getUserDao().find(first, count);
> > >                 }
> > >
> > >                 public int size() {
> > >                         return getUserDao().count();
> > >                 }
> > >
> > >                 public IModel model(Object object) {
> > >                         return new
> > DetachableUserModel((User)object);
> > >                 }
> > >         };
> > >
> > > Getting a hold of a sessionfactory is also very easy
> > especially when
> > > you are dealing with spring // create your application
> > subclass inside
> > > spring Class MyApplication extends WebApplication {
> > >         private SessionFactory sf;
> > >
> > >         public void setSessionFactory(SessionFactory sf) {
> > >                 this.sf=sf;
> > >         }
> > >
> > >         public SessionFactory getSessionFactory() {
> > >                 return sf;
> > >         }
> > >
> > >         public static MyApplication getInstance() {
> > >                 return (MyApplication)Application.get();
> > >         }
> > > }
> > >
> > > Then anywhere in your code:
> > >
> > > MyAPplication.getInstance().getSessionFactory();
> > >
> > > I personally think these things are pretty trivial and I
> > don't see a
> > > need for a stand alone project. Maybe an example is all we need.
> > >
> > > -Igor
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED]
> > > > [mailto:[EMAIL PROTECTED] On
> > Behalf Of Nathan
> > > > Hamblen
> > > > Sent: Tuesday, October 04, 2005 9:49 AM
> > > > To: wicket-user@lists.sourceforge.net
> > > > Subject: [Wicket-user] Standard for database integration?
> > (Please!)
> > > >
> > > > One of this project's strengths is its community of contributers.
> > > > Unlike some other Java web component frameworks, Wicket is not
> > > > controlled by a founder & dictator.
> > > > Hooray for that. But in some areas, disorganization is killing us.
> > > >
> > > > At present, there is no standard way to access a
> > hibernate session
> > > > factory. I understand that the lack of such a standard
> > doesn't stop
> > > > me from accessing one somehow. Wicket's domain is the user
> > > > interface, and I could integrate with a database however I like.
> > > > That's not very helpful though, to me and every other web
> > > > application programmer who absolutely have to integrate with a
> > > > database before we do anything else.
> > > > Most of us are on hibernate, often accessed through Spring.
> > > > We just want one way to hook these things up.
> > > >
> > > > In late August there were two (or more) database packages
> > that did
> > > > things rather differently from each other, then Jonathan Locke
> > > > announced contrib-database. Apparently he didn't think
> > the existing
> > > > efforts were clean enough. That's fair, I'll take his
> > word for it. I
> > > > was ready to switch to that package until I saw that it didn't go
> > > > beyond loading individual hibernate objects. Loading one
> > object is
> > > > the easy part. The interesting part, the part that could
> > be done a
> > > > hundred different ways, is how to load and display many objects
> > > > using a query. That's handled by the apparently unclean
> > contrib data
> > > > and dataview packages. Great.
> > > >
> > > > I wonder if this is just a problem of communication. Surely
> > > > dataview, for example, could be adapted to contrib.database's
> > > > foundation. If those two could be merged, we'd have something
> > > > deprecation-proof to use right now. The code doesn't have to be
> > > > perfect, it just needs to give us an overall structure to program
> > > > around.
> > > >
> > > > Are people talking to each other? I'm just asking
> > because, from my
> > > > perspective, there's a bizarre silence on the subject. An
> > argument
> > > > would be better than nothing. We NEED database
> > integration. Not just
> > > > for the "enterprise,"  but for any web application worth using.
> > > > Let's get it together.
> > > >
> > > > Nathan


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to