OK, I will fix it today sorry for that, break that while fixing event editing :(
On Fri, Sep 23, 2011 at 02:09, [email protected] <[email protected]>wrote: > If you got any additional questions about that point let me know, I > know its bit tricky handling with datapath's and datapointer's in > OpenLaszlo sometimes. > > Sebastian > > 2011/9/22 [email protected] <[email protected]>: > > the calendar Issue is: > > http://code.google.com/p/openmeetings/issues/detail?id=1522 > > > > btw: The calendar uses this datapath thing instead of the rest of the > > application because the calendar initially worked like that. > > Actually the hole OpenLaszlo data-API works using datapath, I have > > customized the rtmp-calls also to be able to apply datasets as return > > objects and use datapaths to present data. But I think I have only > > rare use of it practically. > > > > Sebastian > > > > 2011/9/22 [email protected] <[email protected]>: > >> okay that seems to work. > >> > >> But what happened to the param roomtype in the method saveAppointement > ?! > >> Why is the box to choose the roomtype in the panel gone? > >> > >> You bound the combobox to the datapath: datapath="roomtype" in r4223 > >> > >> That means if you create the calendar this datapath does not exist. As > >> consequence the hole box is invisible. And every call to create a > >> calendar event does fail because roomtype is NaN. > >> > >> Could you fix that to work again please? (in tag and trunk) > >> > >> You could either simulate the object when you create an empty new > >> calendar event, > >> or you read the value of the node for the calendar event at a node > >> level that does exist also when the calendar-event is created and > >> parse then the childNodes out of the tree with > >> childeNodes[0].childNodes[xyz]. ... et cetera until you got the value. > >> Or you create an empty, non visual view and bound the datapath to that > >> one, so nobody does care if its not visible if the path does not > >> exist. > >> > >> The same for datapath="remindtype" > >> > >> Please leave comments like > >> <!-- > >> public Long deleteAppointment(String SID,Long appointmentId) > >> --> > >> in the code, when they are directly in front of the remote call they > >> are refereing too. > >> In 99,9% of all issues (including the one right now) it all ends up to > >> compare the params of the server side to the params in the client side > >> and a possible number, order or type mismatch. > >> > >> Thanks > >> Sebastian > >> > >> 2011/9/22 Maxim Solodovnik <[email protected]>: > >>> Yes, > >>> I add default_language to trunk > >>> then merge everything into 1_8 and test it. > >>> seems to work as expected. > >>> > >>> On Fri, Sep 23, 2011 at 00:08, [email protected] < > [email protected]> > >>> wrote: > >>>> > >>>> did you commit it also to TAG 1.8 ? > >>>> > >>>> Sebastian > >>>> > >>>> 2011/9/22 Maxim Solodovnik <[email protected]>: > >>>> > Hello Sebastian, > >>>> > according to my testing everything should works as expected now. > >>>> > hope I didn't miss anything. > >>>> > > >>>> > On Wed, Sep 21, 2011 at 14:38, Maxim Solodovnik < > [email protected]> > >>>> > wrote: > >>>> >> > >>>> >> Hello Sebastian, > >>>> >> I haven't add use of default language yet (busy on payed customers > >>>> >> support) > >>>> >> Hope will be able to do it today or tomorrow. > >>>> >> I will check 1.8.1 to have all language fixes in place. > >>>> >> > >>>> >> On Wed, Sep 21, 2011 at 14:17, [email protected] > >>>> >> <[email protected]> wrote: > >>>> >>> > >>>> >>> Hi Maxim, > >>>> >>> > >>>> >>> there are some mails incoming about language problems. Could you > check > >>>> >>> the effort about merging your fixes from trunk to version / tag > 1.8 > >>>> >>> (actually its now 1.8.1) and check if: > >>>> >>> > >>>> >>> 1) language_id can be successfully updated in user-profile + in > >>>> >>> registration form > >>>> >>> 2) administrator can set language_id in user_profile > >>>> >>> 3) if a user has null in its user_profile the language_default_id > from > >>>> >>> the Administration > Configuration is taken to load the UI > >>>> >>> 4) Initially if the UI loads and the user is not authenticated the > >>>> >>> login > >>>> >>> shield should always be shown in the language_default_id > >>>> >>> > >>>> >>> ... thats it I think > >>>> >>> > >>>> >>> We should fix that with a version 1.8.2 soon, because otherwise > the > >>>> >>> emails about issues with default language will come up regularly. > >>>> >>> > >>>> >>> Thanks > >>>> >>> Sebastian > >>>> >>> > >>>> >>> -- > >>>> >>> Sebastian Wagner > >>>> >>> http://www.webbase-design.de > >>>> >>> http://openmeetings.googlecode.com > >>>> >>> http://www.wagner-sebastian.com > >>>> >>> [email protected] > >>>> >> > >>>> >> > >>>> >> > >>>> >> -- > >>>> >> WBR > >>>> >> Maxim aka solomax > >>>> > > >>>> > > >>>> > > >>>> > -- > >>>> > WBR > >>>> > Maxim aka solomax > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> Sebastian Wagner > >>>> http://www.webbase-design.de > >>>> http://openmeetings.googlecode.com > >>>> http://www.wagner-sebastian.com > >>>> [email protected] > >>> > >>> > >>> > >>> -- > >>> WBR > >>> Maxim aka solomax > >>> > >> > >> > >> > >> -- > >> Sebastian Wagner > >> http://www.webbase-design.de > >> http://openmeetings.googlecode.com > >> http://www.wagner-sebastian.com > >> [email protected] > >> > > > > > > > > -- > > Sebastian Wagner > > http://www.webbase-design.de > > http://openmeetings.googlecode.com > > http://www.wagner-sebastian.com > > [email protected] > > > > > > -- > Sebastian Wagner > http://www.webbase-design.de > http://openmeetings.googlecode.com > http://www.wagner-sebastian.com > [email protected] > -- WBR Maxim aka solomax -- You received this message because you are subscribed to the Google Groups "OpenMeetings developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/openmeetings-dev?hl=en.
