If it doesn't work for all clients, then the change is illegal, will test and see, if we can keep it or not
On Fri, Jan 2, 2015 at 11:38 PM, Reza Naghibi < [email protected]> wrote: > That fix does not work. The pattern incorrectly captures SGP313, SGP314, > etc. Its too wide. The ticket is to capture 2 specific devices. > > I have reverted your changes. Please consider this issue closed. > > From: Werner Keil <[email protected]> > To: [email protected]; Reza Naghibi <[email protected]> > Sent: Friday, January 2, 2015 5:26 PM > Subject: Re: DMAP-86 > > Then fix classifier to use BuilderDataSources please, <device > id="SGP311"> <list> > <value>SGP31\d</value> </list> </device> > This allows the proper W3C implementation (dmap-ddr-filter) to recognize > both SGP311 and SGP312 correctly. > The classifier does not use BuilderDataSources, but the broken > DeviceDataSource you added for SGP312 messed up both.That's not acceptable > in the 1.0 branch of device-data. > If you must have a separate clone, you'd have to add a separate > DeviceDataSource entry for SGP312. The parent does not work to override > some random property or "clone" a device entry that is identical, but if > you create a second (complete) device descriptor with ID SGP312 that would > be fine. > > <device id="DROID X2" parentId="genericMotorola"> > <property name="model" value="MB870"/> <property > name="marketing_name" value="DROID X2"/> <property > name="displayWidth" value="540"/> <property name="displayHeight" > value="960"/> <property name="mobile_browser" value="Android > Webkit"/> <property name="inputDevices" value="touchscreen"/> > <property name="device_os" value="Android"/> <property > name="device_os_version" value="2.2"/> <property > name="dual_orientation" value="true"/> <property > name="ajax_support_javascript" value="true"/> <property > name="ajax_support_getelementbyid" value="true"/> <property > name="ajax_support_inner_html" value="true"/> <property > name="ajax_manipulate_dom" value="true"/> <property > name="ajax_manipulate_css" value="true"/> <property > name="ajax_support_events" value="true"/> <property > name="ajax_support_event_listener" value="true"/> <property > name="image_inlining" value="true"/> <property name="from" > value="oddr"/> </device>and <device id="MB870" > parentId="genericMotorola"> <property name="model" > value="MB870"/> <property name="marketing_name" value="DROID > X2"/> <property name="displayWidth" value="540"/> > <property name="displayHeight" value="960"/> <property > name="mobile_browser" value="Android Webkit"/> <property > name="mobile_browser_version" value="4.0"/> <property > name="device_os" value="Android"/> <property > name="device_os_version" value="2.2.2"/> <property > name="inputDevices" value="touchscreen"/> <property > name="dual_orientation" value="true"/> <property > name="ajax_support_javascript" value="true"/> <property > name="ajax_support_getelementbyid" value="true"/> <property > name="ajax_support_inner_html" value="true"/> <property > name="ajax_manipulate_dom" value="true"/> <property > name="ajax_manipulate_css" value="true"/> <property > name="ajax_support_events" value="true"/> <property > name="ajax_support_event_listener" value="true"/> <property > name="image_inlining" value="true"/> <property name="from" > value="oddr"/> </device> > are perfect examples for the same practice. > In a 2.x refactored device-data file one may try to do that differently, > e.g. use a "parent" for these 2 nearly identical "MB870" devices (the only > thing that differs seems to be the default OS and that isn't even valid > after an update any more;-) > Werner > > > On Fri, Jan 2, 2015 at 11:17 PM, Reza Naghibi > <[email protected]> wrote: > > 'genericAndroid' is the fallback device. The user had requested we add the > actual device, SGP311 and SGP312. I added these devices on October 20th > [0]. Please look at this ticket [1]. You reverted my changes last night. I > ask that you add them back. Im also asking you stop committing to trunk and > start committing your changes to a branch so I can review them before they > land in trunk. When you become more comfortable with the codebase, then we > can consider direct access to trunk. > > [0] > http://svn.apache.org/viewvc/devicemap/trunk/data/device-data/src/main/resources/devicedata/BuilderDataSource.xml?r1=1622530&r2=1633175 > [1] https://issues.apache.org/jira/browse/DMAP-86 > > --- > > From: Werner Keil <[email protected]> > To: [email protected]; Reza Naghibi <[email protected]> > Sent: Friday, January 2, 2015 5:11 PM > Subject: Re: DMAP-86 > > This is what dmap-spring does if you run the right combination of latest > data snapshot and classifier: > { > "success":true, > "ua":"Mozilla/5.0 (Linux; Android 4.3; SGP311 Build/10.4.B.0.577) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.102 Safari/537.36", > "time_microseconds":409, > > "result":{"id":"genericAndroid","attributes":{"model":"-","ajax_support_getelementbyid":"true","is_bot":"false","marketing_name":"-","displayWidth":"320","id":"genericAndroid","device_os":"Android","xhtml_format_as_attribute":"false","dual_orientation":"false","nokia_series":"0","device_os_version":"-","nokia_edition":"0","vendor":"-","mobile_browser_version":"-","ajax_support_events":"true","is_desktop":"false","image_inlining":"false","ajax_support_inner_html":"true","mobile_browser":"-","ajax_support_event_listener":"true","ajax_manipulate_css":"true","displayHeight":"480","is_tablet":"false","ajax_support_javascript":"true","inputDevices":"touchscreen","is_wireless_device":"true","ajax_manipulate_dom":"true","xhtml_format_as_css_property":"false"}} > } > It's perfectly fine. > Werner > > > On Fri, Jan 2, 2015 at 11:09 PM, Werner Keil <[email protected]> > wrote: > > Well it was you who introduced a bug with this abuse of the DDR files.It > is recommended, to do structural changes in a branch or separate 2.x folder > as mentioned so they don't break the existing 1.x one. > Werner > > > > Werner, the above issue is now broken due to your changes. We can no > longer identify the Xperia Tablet Z as one of our users have requested. > This was working perfectly before you began committing code last night. > > Last time, can you please revert all the changes you made do the data and > the API starting last night? > > I am also going to ask you to stop committing code to SVN trunk. Can you > please start committing your code in a feature branch so I can review your > changes before they land in trunk? > > > > > > > > > > > > >
