I agree, abstracting out the object-relational implementation is important. My list/query filtering code uses interfaces which may provide enough flexibility for other ORMs.
I'm not familiar with how TRails looks or works. That is built with Tapestry, right? Kind of a take-off on Ruby on Rails? I'll send pics and code in a few hours. I don't have the bookmarking stuff implemented, but that can be added pretty easily. It's really just the dynamic query filtering/ordering code that is unique. The code is all mine so no licensing problems. I like to give back to the community if it will help. - Jonathan On 7/12/05, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > >I'm thinking of bean list panel that allows you to dynamically filter > >on one or more attributes (for making very large tables manageable. I > >wrote a list panel like this, but the data access assumes the Cayenne > >flexibility of dynamically creating queries using Java. I'm not sure > >Hibernate is quite as flexible, but I'd be glad to be wrong on that.) > >A check-box in each row would allow you to bookmark instances. These > >bookmarked instances could be put into a drop-down on the edit panels > >of related objects. > > Do we need ORM though? I think we should abstract that, and leave it up > to the user what ORM should be used, if any. That is, unless you'd like > to go the (T)Rails way. Ofcourse, a default implementation providing for > Cayenne would be cool. > > >I can send you an image of what I'm talking about (for the list > >filtering). If you are interested, I can send you my list panel code > >with the dynamic query-builder classes. I think I documented them > >pretty well, at least at the class level. The columns in my list > >panel are not generic yet (you still have to specify the individual > >columns in the HTML) but the dynamic query builder code wouldn't > >change much except to make it more generic for other persistence > >mechanisms. > > > > > > Sure, pls send me the pics :) How is your code licenced? If it could be > open source, we could just build on your project, right? > > >I really think it is possible to create a few well-crafted editing and > >list panels (using the flexibility of OGNL, dynamic queries, and > >modern ORM tools) that would allow relatively easy management of > >almost any data schema. When I was a kid, my grandma taught me 3 or 4 > >chords on a ukelele. Those simple chords could be used to accompany > >any song, she said. That made a big impression on me at the time. In > >our case, though, the tricky part is to keep the panels relatively > >simple without sacrificing critical features. > > > > > > > > Yeah. I'm a guitar player, and allways am amazed that even bands like > Radiohead just need a few chords for really great songs :) > > How would our project compare to Trails? Anything we could learn from > that? Or maybe even 'just' integrate? > > Anyway, I think the main flexibility should cover the looks of the panel > and the ordering of fields. Furthermore, I think the BeanInfo like > pattern I used is usefull for breaking out of the default field > rendering. What do you think? > > >Would there be any reason to keep the basic, generic, BeanPanel and > >BeanListPanel stuff in wicket-extensions, then have the uber-project > >in wicket-stuff? Either way is fine with me. > > > > > > Hmm. Dunno. Though it would be nice to have the beanpanel in its basic > form in extensions, I doubt it's usefullness. Editing of objects seems > to be an all or nothing thing to mee. > > Eelco > > >- Jonathan Carlson > > > > > > > > > >>>>[EMAIL PROTECTED] 2005-07-12 2:21:36 AM >>> > >>>> > >>>> > >Jonathan Carlson wrote: > > > > > > > >>I think you are right, it does get complex rather quickly. > >> > >>I've played with having a tab panel for related objects. Mine sat > >>right below the edit form. It worked pretty well. One-to-many > >>relationship tabs have a pageable table of related instances. > >>One-to-one relationship tabs just have an editable form for the related > >>object. It makes for a larger page object, but it feels natural to me > >>to keep related stuff together on the same page. > >> > >> > > > >Sounds good. Does that mean it's all page centric then? One of the > >things I would really like, is that you could include the bean editor as > >a Panel, that works regardless of what is more on your page. > > > > > > > >>One thing that would help is to be able to "bookmark" instances as you > >>browse them. These can be candidates for adding to a relationship (like > >>adding an employee to a manager, etc). Or just for speedier access to > >>the instances you use most frequently. > >> > >> > > > >Great idea. Not sure how exactly that would look though. > > > > > > > >>I'm interested in helping out since I need to do this anyways, but I'd > >>probably push towards a more full-fledged project. > >> > >> > >> > >> > > > >Cool. I think the smartest thing is to start a new project for it in > >wicket-stuff. I'll try to start that up tonight. > > > >Eelco > > > > > > > >>- Jonathan Carlson > >> > >> > >> > >> > >> > >> > >>>>>[EMAIL PROTECTED] 2005-07-11 4:45:03 PM >>> > >>>>> > >>>>> > >>>>> > >>>>> > >>I've been thinking a bit more about the bean panel, and I'm kind of > >>stuck. That is, there's too many possibilities! > >> > >>A simple bean is no problem. I have code in CVS for that now and it > >>works (with a special case, FieldPanel, which lets you select a subset > >> > >>of the properties of the bean). The problem starts when you think about > >> > >>the more complex properties. E.g. a Person object that has an Address > >>as > >>a property. Usually, you'd want to give the Address its own edit form. > >> > >>But probably not in the same page as the Person form is (things would > >>get messy pretty quickly). So, say you'd want to navigate to address > >>edit from person edit. The current implementation I had was just a > >>bunch > >>of fields, no form, which has the advantage that you can decide to nest > >> > >>it in any form you like. Also it had no buttons (cancel, save), just > >>the > >>fields. Thing is, that we need the form and the buttons if we'd want to > >> > >>support the object browsing. And if we build that, we are allready > >>halfway a Trails application. > >> > >>So, what do you guys think? What direction should the bean panel > >>experiment head? Who is interested in cooperating, and where should we > >> > >>put it (in wicket-stuff, so that it can be a seperate full-fledged > >>project with more people working on it, or in extensions in case we > >>keep > >>it really simple)? > >> > >>Eelco > >> > >> > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > >July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > >core and dual graphics technology at this free one hour event hosted by HP, > >AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > >_______________________________________________ > >Wicket-user mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > -- Jon Carlson Reply to: [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
