CarlosRuiz: Good morning
CarlosRuiz: as I use to say starting these meetings :-)
CarlosRuiz: no agenda, just open meeting to chat about technical/functional things, so if you have any issue (technical or functional) you want to discuss - is open - otherwise I'll start working on my pendings for iDempiere
CarlosRuiz: ah - but I remember there was a point proposed by hengsin - "git vs mercurial"
a42niem: good morning
Suman_: Good Morning
CarlosRuiz: morning :-)
CarlosRuiz: I'll be working on IDEMPIERE-140 meanwhile ...
Suman_: Hi Carlos
CarlosRuiz: Hi Suman
Suman_: selenium one
Suman_: I have downloaded adempiere361, but it seems you have given selenium related changes as patch
Suman_: and one more thing my understanding is in Rich Internet applications through code we should not set ID
Suman_: as it can create name space problem
Suman_: We need to have our own attribute, and selenium should recognize this
CarlosRuiz: 1- adempiere361 and idempiere are in sync on that selenium naming convention - and evolving
CarlosRuiz: 2 - zk provides and recommends this mechanism for selenium http://books.zkoss.org/wiki/Small_Talks/2009/February/How_to_Test_ZK_Application_with_Selenium
CarlosRuiz: hmmm - seems like hengsin is having a lot of connection problems
CarlosRuiz: but I would like to analyze this statement -> "With the current version ZK 5.0.3 the manual implementation of the ID generator is no longer required"
Suman_: yes I agree, your the given by you is basis for our work
Suman_: From ZK5.0 onwards ZK implemented a new tool called ZTL, which will help in selenium automation
Suman_: but that tool does not work in zk3.6
CarlosRuiz: thanks for clarifying
Suman_: we can see discussion at the following link
hengsin__: hi carlos
CarlosRuiz: hi hengsin
CarlosRuiz: Suman_, what do you mean with "it can create name space problem"
Suman_: Carlos, are you able to record and Playback the script with out manual intervention with the code changes you made
CarlosRuiz: yes - for a big percentage of components
Suman_: When we load a page no two components should have same ID
Suman_: if our code is setting ID manually then there is a chance that ID may get repeated
CarlosRuiz: ah - ok - I changed the nextUUID function to check that
hengsin: hi carlos
CarlosRuiz: Suman_, look the AdempiereIdGenerator.java the line with this comment "// but don't trust and look to avoid dups"
CarlosRuiz: at this moment the recorded session can be played back - and it stops precisely at the components where we have not implemented the nextID approach
CarlosRuiz: so for me it's a matter of extending coverage of the nextID thing for more and more components
CarlosRuiz: trying to find a unique predictable ID for each
Suman_: I have taken snapshot from the following link, hg clone https://bitbucket.org/CarlosRuiz_globalqss/adempiere361
Suman_: is this correct link for latest adempiere361?
CarlosRuiz: after cloned you must -> hg update globalqss_adempiere361
CarlosRuiz: is the IDGenerator approach still backward compatible in zk5?
Suman_: with some minor changes I think yes
Suman_: Instead _ we may need to use -
Suman_: but ZK5.0 has licensing issues
hengsin: hi carlos
CarlosRuiz: yes - I saw hengsin opened a ticket pointing to ZK6
CarlosRuiz: Suman_, if you plan to work on that area I'll be glad to review and integrate your work
Suman_: I have around this, I have downloaded adempiere361 today, will send an update as I make progress
CarlosRuiz: with a42niem we tested the fork mechanism and pull request on bitbucket
CarlosRuiz: it works good
Suman_: I am new to this bitbucket
Suman_: can you share any link
Suman_: with the steps on how to pull the changes
CarlosRuiz: very simple really
CarlosRuiz: I wrote just a few lines here
Suman_: Thanks for Discussion
Suman_: I will be leaving now