You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2012/09/08 20:11:21 UTC
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
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 <so...@gmail.com>:
> 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, seba.wagner@gmail.com
> <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> >
>> > 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 <so...@gmail.com>
>> >>
>> >> 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
>> > seba.wagner@gmail.com
>>
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>
>
>
>
> --
> WBR
> Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by Maxim Solodovnik <so...@gmail.com>.
linking folders not working at all
On Sun, Sep 9, 2012 at 11:44 PM, Maxim Solodovnik <so...@gmail.com>wrote:
> 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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <so...@gmail.com>:
>> > 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, seba.wagner@gmail.com
>> > <se...@gmail.com> 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 <so...@gmail.com>:
>> >> > 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 <
>> solomax666@gmail.com>
>> >> > 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, seba.wagner@gmail.com
>> >> >> <se...@gmail.com> 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 <so...@gmail.com>:
>> >> >>> > 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, seba.wagner@gmail.com
>> >> >>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> >> >>> >> >
>> >> >>> >> > 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 <so...@gmail.com>
>> >> >>> >> >>
>> >> >>> >> >> 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
>> >> >>> >> > seba.wagner@gmail.com
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> --
>> >> >>> >> Sebastian Wagner
>> >> >>> >> https://twitter.com/#!/dead_lock
>> >> >>> >> http://www.webbase-design.de
>> >> >>> >> http://www.wagner-sebastian.com
>> >> >>> >> seba.wagner@gmail.com
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > --
>> >> >>> > WBR
>> >> >>> > Maxim aka solomax
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> Sebastian Wagner
>> >> >>> https://twitter.com/#!/dead_lock
>> >> >>> http://www.webbase-design.de
>> >> >>> http://www.wagner-sebastian.com
>> >> >>> seba.wagner@gmail.com
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> 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
>> >> seba.wagner@gmail.com
>> >
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by Maxim Solodovnik <so...@gmail.com>.
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, seba.wagner@gmail.com <
seba.wagner@gmail.com> 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 <so...@gmail.com>:
> > 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, seba.wagner@gmail.com
> > <se...@gmail.com> 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 <so...@gmail.com>:
> >> > 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 <
> solomax666@gmail.com>
> >> > 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, seba.wagner@gmail.com
> >> >> <se...@gmail.com> 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 <so...@gmail.com>:
> >> >>> > 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, seba.wagner@gmail.com
> >> >>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >> >>> >> >
> >> >>> >> > 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 <so...@gmail.com>
> >> >>> >> >>
> >> >>> >> >> 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
> >> >>> >> > seba.wagner@gmail.com
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >>
> >> >>> >> --
> >> >>> >> Sebastian Wagner
> >> >>> >> https://twitter.com/#!/dead_lock
> >> >>> >> http://www.webbase-design.de
> >> >>> >> http://www.wagner-sebastian.com
> >> >>> >> seba.wagner@gmail.com
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > --
> >> >>> > WBR
> >> >>> > Maxim aka solomax
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Sebastian Wagner
> >> >>> https://twitter.com/#!/dead_lock
> >> >>> http://www.webbase-design.de
> >> >>> http://www.wagner-sebastian.com
> >> >>> seba.wagner@gmail.com
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> 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
> >> seba.wagner@gmail.com
> >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
=> 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 <so...@gmail.com>:
> 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, seba.wagner@gmail.com
> <se...@gmail.com> 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 <so...@gmail.com>:
>> > 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 <so...@gmail.com>
>> > 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, seba.wagner@gmail.com
>> >> <se...@gmail.com> 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 <so...@gmail.com>:
>> >>> > 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, seba.wagner@gmail.com
>> >>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> >>> >> >
>> >>> >> > 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 <so...@gmail.com>
>> >>> >> >>
>> >>> >> >> 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
>> >>> >> > seba.wagner@gmail.com
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> Sebastian Wagner
>> >>> >> https://twitter.com/#!/dead_lock
>> >>> >> http://www.webbase-design.de
>> >>> >> http://www.wagner-sebastian.com
>> >>> >> seba.wagner@gmail.com
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > WBR
>> >>> > Maxim aka solomax
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Sebastian Wagner
>> >>> https://twitter.com/#!/dead_lock
>> >>> http://www.webbase-design.de
>> >>> http://www.wagner-sebastian.com
>> >>> seba.wagner@gmail.com
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>> seba.wagner@gmail.com
>
>
>
>
> --
> WBR
> Maxim aka solomax
--
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by Maxim Solodovnik <so...@gmail.com>.
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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 <so...@gmail.com>:
> > 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 <so...@gmail.com>
> > 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, seba.wagner@gmail.com
> >> <se...@gmail.com> 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 <so...@gmail.com>:
> >>> > 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, seba.wagner@gmail.com
> >>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >>> >> >
> >>> >> > 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 <so...@gmail.com>
> >>> >> >>
> >>> >> >> 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
> >>> >> > seba.wagner@gmail.com
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Sebastian Wagner
> >>> >> https://twitter.com/#!/dead_lock
> >>> >> http://www.webbase-design.de
> >>> >> http://www.wagner-sebastian.com
> >>> >> seba.wagner@gmail.com
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > WBR
> >>> > Maxim aka solomax
> >>>
> >>>
> >>>
> >>> --
> >>> Sebastian Wagner
> >>> https://twitter.com/#!/dead_lock
> >>> http://www.webbase-design.de
> >>> http://www.wagner-sebastian.com
> >>> seba.wagner@gmail.com
> >>
> >>
> >>
> >>
> >> --
> >> 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
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com>:
> 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 <so...@gmail.com>
> 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, seba.wagner@gmail.com
>> <se...@gmail.com> 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 <so...@gmail.com>:
>>> > 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, seba.wagner@gmail.com
>>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>>> >> >
>>> >> > 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 <so...@gmail.com>
>>> >> >>
>>> >> >> 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
>>> >> > seba.wagner@gmail.com
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Sebastian Wagner
>>> >> https://twitter.com/#!/dead_lock
>>> >> http://www.webbase-design.de
>>> >> http://www.wagner-sebastian.com
>>> >> seba.wagner@gmail.com
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > WBR
>>> > Maxim aka solomax
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>
>>
>>
>>
>> --
>> 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
seba.wagner@gmail.com
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by Maxim Solodovnik <so...@gmail.com>.
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 <so...@gmail.com>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, seba.wagner@gmail.com <
> seba.wagner@gmail.com> 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 <so...@gmail.com>:
>> > 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, seba.wagner@gmail.com
>> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
>> >> >
>> >> > 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 <so...@gmail.com>
>> >> >>
>> >> >> 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
>> >> > seba.wagner@gmail.com
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Sebastian Wagner
>> >> https://twitter.com/#!/dead_lock
>> >> http://www.webbase-design.de
>> >> http://www.wagner-sebastian.com
>> >> seba.wagner@gmail.com
>> >
>> >
>> >
>> >
>> > --
>> > WBR
>> > Maxim aka solomax
>>
>>
>>
>> --
>> Sebastian Wagner
>> https://twitter.com/#!/dead_lock
>> http://www.webbase-design.de
>> http://www.wagner-sebastian.com
>> seba.wagner@gmail.com
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: svn commit: r1382288 - in /incubator/openmeetings/trunk/singlewebapp:
WebContent/src/modules/admin/useradmin/ WebContent/src/modules/settings/
WebContent/src/modules/settings/searchuserprofile/ WebContent/src/modules/settings/usercontacts/
log/ s
Posted by Maxim Solodovnik <so...@gmail.com>.
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, seba.wagner@gmail.com <seba.wagner@gmail.com
> 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 <so...@gmail.com>:
> > 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, seba.wagner@gmail.com
> > <se...@gmail.com> 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 seba.wagner@gmail.com <se...@gmail.com>
> >> >
> >> > 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 <so...@gmail.com>
> >> >>
> >> >> 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
> >> > seba.wagner@gmail.com
> >>
> >>
> >>
> >>
> >> --
> >> Sebastian Wagner
> >> https://twitter.com/#!/dead_lock
> >> http://www.webbase-design.de
> >> http://www.wagner-sebastian.com
> >> seba.wagner@gmail.com
> >
> >
> >
> >
> > --
> > WBR
> > Maxim aka solomax
>
>
>
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>
--
WBR
Maxim aka solomax