1) I still use "jar.only". In case of small changes I attach Eclipse debugger and perform changes while running. In my previous project I did the following: link Eclipse build location to webapps/openmeetings/WEB-INF/classes (in such case as soon as classes are recompiled by Eclipse they will be used by Wicket (I'll try it and will send you the steps)
2) In Wicket you can pack any resource with HTML/java file, but I would vote for css in webapps/openmeetings/css (WebContent/openmeetings/css) so design can be easily changed by the end user. On Sun, Sep 9, 2012 at 4:22 PM, [email protected] <[email protected] > wrote: > I slowly get the hang of it. You still export/import the saluations_id > as title_id. That way it does not conflict with the old style but > still work with the new attribute name. Clever you are :) > > I guess I can handle the rest of the user administration to learn how > to use wicket. I will ask you to review it. > What I would like to discuss several things: > 1) I have added a new ant target "jar.web.only". You can only use it > to recompile, it does not ivy checks et cetera. It only takes 3-4 > seconds (compared to 30 seconds that takes it when you run > "jar.only"). > However you still need to re-start tomcat every time, and that takes > around 30 seconds more. > Is there a way to run it from inside Eclipse without need to restart? > That would make the development process much more fluent and speed up > things. What do you think? > 2) What is the best way to include CSS files in our app? Is there a > common way in Wicket to attach CSS files to certain Panels or > sub-pages or do you normally use a global CSS and include it > everywhere? > > Thanks! > Sebastian > > 2012/9/8 Maxim Solodovnik <[email protected]>: > > Currently I'm testing export/import > > And will commit the fix in half an hour. > > > > Maybe will have time to improve Wicket part :) > > > > > > On Sun, Sep 9, 2012 at 1:23 AM, Maxim Solodovnik <[email protected]> > > wrote: > >> > >> Please take a look at BackupImportController::private List<Users> > >> readUserList(line 714) > >> The first loop starting at line 728 is removing duplicated "deleted" > node > >> > >> complicated part at line 749 (marked as HACK in comments) > >> did the following: > >> if this is the backup of fresh version (2.1) then do nothing > >> If it is old backup and it has address and sipdata fields merged into > user > >> fields then parse it extensively) > >> > >> I create converters to support old format. > >> All newly added and nullable fields are marked as "required='false'" > >> > >> I hope I don't miss any significant parts. > >> > >> In case of future refactoring we need to add "name" attribute to > @Element > >> annotation to ensure import/export is not changed. > >> > >> > >> On Sun, Sep 9, 2012 at 1:11 AM, [email protected] > >> <[email protected]> wrote: > >>> > >>> Ok, > >>> > >>> thanks for taking that serious :) > >>> The issue is that we have now two attributes: > >>> title_id and salutations_id that do represent the same. > >>> > >>> I have been reviewing part of the BackupImportController, it is just > >>> very clean now compared to before. > >>> I think you covered all the tricky parts and refactored into the new > >>> mechanism. > >>> > >>> But how does it deal with attribute name changes, is there a way in > >>> the UserConverter for example where we could define an alternative > >>> mapping so that it gets backward compatible? > >>> > >>> Thanks! > >>> Sebastian > >>> > >>> 2012/9/8 Maxim Solodovnik <[email protected]>: > >>> > I did test old backups while refactoring import. > >>> > I'll double check my latest changes. > >>> > > >>> > I have added > >>> > @Element(name="title_id", data=true, required=false) > >>> > so exported and imported element name will be "title_id" (backward > >>> > compatible) > >>> > > >>> > I will test if new Salutations field works. > >>> > I did change this code since it was not compilable (Eclipse reported > >>> > setSalutation(int) is illegal). > >>> > > >>> > > >>> > On Sat, Sep 8, 2012 at 11:07 PM, [email protected] > >>> > <[email protected]> wrote: > >>> >> > >>> >> Sorry I did not know that new implementation. > >>> >> What is the inted way for the new implementation to handle backward > >>> >> compatibility. > >>> >> I mean: > >>> >> I have now changed the attribute title_id to saluation_id. Does that > >>> >> mean that all old backup ZIPs will not work anymore because there > are > >>> >> different attribute name used in that Users object? > >>> >> > >>> >> There are a number of such fields that, from my point of view the > goal > >>> >> of the importer was always to be able to import any old backup ZIPs. > >>> >> That means that there could be schema changes from one version to > the > >>> >> next. > >>> >> That also means that whole tables, attribute names or attribute > types > >>> >> may change from one version to the next. That is actually the reason > >>> >> for having that in a database/schema independent XML format. > >>> >> > >>> >> How can we make sure now that those olde backups still will work? > >>> >> > >>> >> Sebastian > >>> >> > >>> >> 2012/9/8 [email protected] <[email protected]> > >>> >> > > >>> >> > Okay, > >>> >> > > >>> >> > but what have you done with your commit now? > >>> >> > There are now two attributes in the Users table: > >>> >> > title_id > >>> >> > and salutation_id > >>> >> > > >>> >> > and two attributes: > >>> >> > salutation_id > >>> >> > and > >>> >> > salutations > >>> >> > > >>> >> > I have implemented it in that way that there are two attributes, > >>> >> > while > >>> >> > "saluations" is read only (insertable = false, updatable = false). > >>> >> > I have kept the salutations_id because I did not want to modify > too > >>> >> > much > >>> >> > of the code in the OpenLaszlo client for now. But what you have > done > >>> >> > now > >>> >> > simply does not work. Why? > >>> >> > > >>> >> > Sebastian > >>> >> > > >>> >> > > >>> >> > > >>> >> > 2012/9/8 Maxim Solodovnik <[email protected]> > >>> >> >> > >>> >> >> Hello Sebastian, > >>> >> >> > >>> >> >> Does > >>> >> >> UserImport.java > >>> >> >> Export.java > >>> >> >> > >>> >> >> Are still used in our code? > >>> >> >> If yes I believe it need to be refactored like > >>> >> >> BackupImportController > >>> >> >> line 288 > >>> >> >> > >>> >> >> I believe the code doing similar things should be in 1 place > only. > >>> >> >> > >>> >> >> -- > >>> >> >> 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] > >>> > > >>> > > >>> > > >>> > > >>> > -- > >>> > WBR > >>> > Maxim aka solomax > >>> > >>> > >>> > >>> -- > >>> 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] > -- WBR Maxim aka solomax
