I seems to stuck with 1). Markup files (html) seems to be immediately reloaded by Wicket, but I was unable to make class files to be "hot swapped". (Maybe we need to ask help from "Wicket guru" :)) )
What was done: 1) "web" package was removed from jar and put into WEB-INF/classes 2) both html and java code was modified inside eclipse 3) classes and htmls were copied from build/classes/eclipse into WEB-INF/classes changes in markup were displayed on the page. changes in java were not. Can you ask Wicket dev list? If any working scenario will be found I can code it into ant target On Sun, Sep 9, 2012 at 10:13 PM, [email protected] < [email protected]> wrote: > => 2) => I think so too. I would even consider it might be useful to > have the .html files not packaged in the JAR file but having them in > some folder. That way end users have better chances to customize. And > also we have better chances to work together with designers. > > Sebastian > > 2012/9/9 Maxim Solodovnik <[email protected]>: > > 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 > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax
