*The only "extra" markup I add to the forms: wrap it with table, I believe it is better aligned. I thought of adding tabs to the room and user admin since otherwise it has too much options. But IMHO this should be done later. * => this is the markup that I am refering to. There is no need to add a table to layout a form. It does not harm at this moment but actually try to google "using table to layout a form" => the first 100 matches at google are advices like: "Why you shouldn't use tables to layout a form" :)))
So please consider to remove the table tags for the future. In general we should try to avoid to use the html tag table to "design" HTML at all. I know I have added some by myself, but just because of my lack of knowledge about alternatives. Sebastian 2012/10/4 [email protected] <[email protected]> > I think you have to use the query: > > SELECT fv FROM Fieldvalues fv LEFT OUTER JOIN *FETCH *fv.labelValues flv > WHERE fv.deleted = false AND flv.deleted = false AND flv.language_id = :lang > > Otherwise FetchType.Lazy won't be overwritten by your JPQL. > > Sebastian > > > 2012/10/4 Maxim Solodovnik <[email protected]> > >> >> http://mail-archives.apache.org/mod_mbox/openjpa-users/201210.mbox/ajax/%3CCAJmbs8gAeTdVen0ZUg1wmjP4V3YGrtV%2B--yN7ESC%3DZ1uzgSfyw%40mail.gmail.com%3E >> >> >> On Thu, Oct 4, 2012 at 9:55 AM, Maxim Solodovnik <[email protected]>wrote: >> >>> Hello Sebastian, >>> >>> sorry for the late response (have no much free time to work on 3.0) >>> >>> The only "extra" markup I add to the forms: wrap it with table, I >>> believe it is better aligned. I thought of adding tabs to the room and user >>> admin since otherwise it has too much options. But IMHO this should be done >>> later. >>> >>> Language admin section: I'm trying to handle it in more elegant way, >>> using LEFT OUTER JOIN. Unfortunately I'm still unable to write correct JPQL >>> query :( I did ask openjpa user mailing list, but no answer yet. I'll add >>> your solution in case I get no answer. >>> >>> Why do you need AddUserForm as utility class? do we have several places >>> to add users? >>> >>> General add/search/delete user component should be implemented as Panel >>> in Wicket (Panel can have its own markup) and then can be added to any >>> component. >>> >>> I would use overflow=auto instead of overflow=scroll (don't really like >>> disabled scrollers) >>> I believe all "styling" issues can be corrected right after main >>> functionality will be completed. >>> I would vote for completing all areas (except rooms) and then start >>> GUI enchantments :) >>> >>> On Tue, Oct 2, 2012 at 1:05 AM, [email protected] < >>> [email protected]> wrote: >>> >>>> Hi Maxim, >>>> >>>> let me give an update about the admin section: >>>> I have completed Users, Configuration, Ldap, Servers. >>>> >>>> About the markup for the forms: >>>> I would like to use the fieldset tag and structure everything using >>>> CSS. You can also make nice sub sections using a fieldset. >>>> There are thousands example of forms styled by simply using CSS in the >>>> www, no need to blow up the markup to have the form styled. >>>> >>>> Language admin section has the issue with the new/empty labels (JOIN >>>> issues as you described it in your last email). >>>> >>>> UserGroups admin section has some exceptions. I would like to finish >>>> that. We need the user selection of single users ("AddUserForm") also for >>>> the room administration. >>>> Eventually it might makes sense to make a package "utils" in the >>>> package org.apache.openmeetings.web.components.admin and move the >>>> AddUserForm to it. >>>> Is it possible to have the HTML/Wicket markup of "AddUserForm" also >>>> separated from the groups section? Eventually it makes sense to add a >>>> general "search/add/delete user list" component. >>>> >>>> >>>> Also I would like to have the form its own scrolling, independent from >>>> the table on the left. So you can scroll down the form without scrolling in >>>> the table (and vice versa). >>>> Todos are: >>>> - the tables should auto scale to use 100% of the remaining whitespace >>>> on the bottom (currently fixed height) >>>> - The forms need to be containered in a div, with overflow=scroll (and >>>> a fix to the height so that it automatically takes 100% of the rest of the >>>> whitespace of the page when you resize the browser window). >>>> >>>> Also the x-position of the form is currently wrong, if you resize the >>>> browser you can see a bad effect. This is something that I was also looking >>>> at but found no solution yet. >>>> >>>> Cheerio :) >>>> Sebastian >>>> >>>> -- >>>> Sebastian Wagner >>>> https://twitter.com/#!/dead_lock >>>> http://www.webbase-design.de >>>> http://www.wagner-sebastian.com >>>> [email protected] >>>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
