From: Laurent A. <la...@al...> - 2011-06-24 18:11:26
|
Hi I am running a custom skin based on jQuery. I recently switched from jQuery 1.4.3 to 1.6.1 and noticed that pages with the Exhibit format are now blank. Reverting to 1.4.3 brings them back. There is a javascript error as well : Error: uncaught exception: Syntax error, unrecognized expression: [rel=exhibit/data] Something to look into as people are going to eventually upgrade. -- - Laurent Alquier http://www.linfa.net |
From: Yaron K. <ya...@wi...> - 2011-06-29 05:07:11
|
Hi Laurent, Starting with version 1.16, MediaWiki came bundled with its own copy of jQuery - so MW skins that use jQuery should use MW's copy whenever possible, which would eliminate problems of jQuery incompatibility. You can see the 6th bullet point here, for one way to do that for a custom skin: http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Semantic_Forms_issues -Yaron On Fri, Jun 24, 2011 at 2:11 PM, Laurent Alquier <la...@al...>wrote: > Hi > > I am running a custom skin based on jQuery. > > I recently switched from jQuery 1.4.3 to 1.6.1 and noticed that pages with > the Exhibit format are now blank. > Reverting to 1.4.3 brings them back. > > There is a javascript error as well : > > Error: uncaught exception: Syntax error, unrecognized expression: > [rel=exhibit/data] > > Something to look into as people are going to eventually upgrade. > > -- > - Laurent Alquier > http://www.linfa.net > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense.. > http://p.sf.net/sfu/splunk-d2d-c1 > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Laurent A. <la...@al...> - 2011-06-29 05:57:26
|
I understand perfectly. The problem remains however. When MW decides to upgrade their bundled version of jQuery, SRF exhibit will still have to be fixed :) - Laurent On Wed, Jun 29, 2011 at 1:07 AM, Yaron Koren <ya...@wi...> wrote: > Hi Laurent, > > Starting with version 1.16, MediaWiki came bundled with its own copy of > jQuery - so MW skins that use jQuery should use MW's copy whenever possible, > which would eliminate problems of jQuery incompatibility. You can see the > 6th bullet point here, for one way to do that for a custom skin: > > > http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Semantic_Forms_issues > > -Yaron > > > On Fri, Jun 24, 2011 at 2:11 PM, Laurent Alquier <la...@al...>wrote: > >> Hi >> >> I am running a custom skin based on jQuery. >> >> I recently switched from jQuery 1.4.3 to 1.6.1 and noticed that pages with >> the Exhibit format are now blank. >> Reverting to 1.4.3 brings them back. >> >> There is a javascript error as well : >> >> Error: uncaught exception: Syntax error, unrecognized expression: >> [rel=exhibit/data] >> >> Something to look into as people are going to eventually upgrade. >> >> -- >> - Laurent Alquier >> http://www.linfa.net >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense.. >> http://p.sf.net/sfu/splunk-d2d-c1 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > -- - Laurent Alquier http://www.linfa.net |
From: zehetner <zeh...@mo...> - 2011-06-29 15:39:31
|
Hi, does somebody know if SMW 1.6 still keeps for multivalue (record type) properties the information about the order of the single values somewhere in the database or if that got lost? Up to now in table atts2 the field p_id allowed to identify (with the help of the smw_iw=':smw-intprop' values from table ids) the original order of the values of value_xsd withing such a property. +---------+------+-----------+------------+-----------+ | s_id | p_id | value_xsd | value_unit | value_num | +---------+------+-----------+------------+-----------+ | 3950215 | 24 | Source1 | | 0 | | 3993424 | 23 | Name3 | | 0 | | 3950216 | 23 | Name2 | | 0 | | 3950216 | 24 | Source2 | | 0 | | 3950215 | 23 | Name1 | | 0 | | 3993425 | 24 | Source4 | | 0 | +---------+------+-----------+------------+-----------+ So in this case it was e.g. [[Prop::Name1;Source1]] and [[Prop::Name3;?]] and [[Prop::?;Source4]] etc. Now with SMW 1.6 the field p_id contains a smw_id value which points to the property type of the record field in table ids +---------+---------+-----------+-----------+ | s_id | p_id | value_xsd | value_num | +---------+---------+-----------+-----------+ | 3912158 | 3993483 | Source4 | 0 | | 3904473 | 3993483 | Source2 | 0 | | 3904473 | 3993483 | Name2 | 0 | | 3904472 | 3993483 | Name1 | 0 | | 3904472 | 3993483 | Source1 | 0 | | 3904474 | 3993483 | Name3 | 0 | +---------+---------+-----------+-----------+ So from this info one can not see anymore if the property was e.g. [[Prop::Name1;Source1]] or [[Prop::Source1;Name1]] and [[Prop::Name3;?]] or [[Prop::?;Name3]] etc. Is the order now maybe stored somewhere else in the DB tables? Would be most grateful if someone could give me a hint. Thanks Gu |
From: Laurent A. <la...@al...> - 2011-07-10 04:39:15
|
I found the (surprisingly simple) solution to recent versions of jQuery breaking SRF Exhibit. All you have to do is replace : rel=exhibit/data with : rel=”exhibit/data” in the following lines : (the missing quotes is the issue) 1- Exhibit\exhibit\exhibit-bundle.js(373): Exhibit.Database._Impl.prototype.loadDataLinks=function(fDone){var links=SimileAjax.jQuery("head > link[rel=exhibit/data]").get(); 2- Exhibit\exhibit\scripts\data\database.js(139): var links = SimileAjax.jQuery('head > link[rel=exhibit/data]').get(); Source (or rather, inspiration for a solution): http://www.thalesjacobi.com/Jquery_error_uncaught_exception_Syntax_error_unrecognized_expression SRF Exhibit works without javascript error with jQuery 1.5.1 and 1.6.1 (two versions that used to break without quotes). Adding the quotes doesn't seem to break SRF qith jQuery 1.4.3 either, so the change seems safe at this time. - Laurent On Wed, Jun 29, 2011 at 1:07 AM, Yaron Koren <ya...@wi...> wrote: > Hi Laurent, > > Starting with version 1.16, MediaWiki came bundled with its own copy of > jQuery - so MW skins that use jQuery should use MW's copy whenever possible, > which would eliminate problems of jQuery incompatibility. You can see the > 6th bullet point here, for one way to do that for a custom skin: > > > http://www.mediawiki.org/wiki/Extension:Semantic_Forms#Semantic_Forms_issues > > -Yaron > > > On Fri, Jun 24, 2011 at 2:11 PM, Laurent Alquier <la...@al...>wrote: > >> Hi >> >> I am running a custom skin based on jQuery. >> >> I recently switched from jQuery 1.4.3 to 1.6.1 and noticed that pages with >> the Exhibit format are now blank. >> Reverting to 1.4.3 brings them back. >> >> There is a javascript error as well : >> >> Error: uncaught exception: Syntax error, unrecognized expression: >> [rel=exhibit/data] >> >> Something to look into as people are going to eventually upgrade. >> >> -- >> - Laurent Alquier >> http://www.linfa.net >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense.. >> http://p.sf.net/sfu/splunk-d2d-c1 >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > -- - Laurent Alquier http://www.linfa.net |
From: Jeroen De D. <jer...@gm...> - 2011-07-11 00:45:54
|
Hey Laurent, Thanks for the patch, I applied it: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91856 If someone else could confirm it works as it should; I don't have anything setup to test Exhibit. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Markus K. <ma...@se...> - 2011-07-10 10:18:19
|
On 29/06/11 16:39, zehetner wrote: > Hi, > > does somebody know if SMW 1.6 still keeps for multivalue (record type) > properties the information about the order of the single values somewhere > in the database or if that got lost? > > Up to now in table atts2 the field p_id allowed to identify (with the help > of the smw_iw=':smw-intprop' values from table ids) the original order of > the values of value_xsd withing such a property. > > +---------+------+-----------+------------+-----------+ > | s_id | p_id | value_xsd | value_unit | value_num | > +---------+------+-----------+------------+-----------+ > | 3950215 | 24 | Source1 | | 0 | > | 3993424 | 23 | Name3 | | 0 | > | 3950216 | 23 | Name2 | | 0 | > | 3950216 | 24 | Source2 | | 0 | > | 3950215 | 23 | Name1 | | 0 | > | 3993425 | 24 | Source4 | | 0 | > +---------+------+-----------+------------+-----------+ > > So in this case it was e.g. [[Prop::Name1;Source1]] and [[Prop::Name3;?]] > and [[Prop::?;Source4]] etc. > > Now with SMW 1.6 the field p_id contains a smw_id value which points to > the property type of the record field in table ids > > +---------+---------+-----------+-----------+ > | s_id | p_id | value_xsd | value_num | > +---------+---------+-----------+-----------+ > | 3912158 | 3993483 | Source4 | 0 | > | 3904473 | 3993483 | Source2 | 0 | > | 3904473 | 3993483 | Name2 | 0 | > | 3904472 | 3993483 | Name1 | 0 | > | 3904472 | 3993483 | Source1 | 0 | > | 3904474 | 3993483 | Name3 | 0 | > +---------+---------+-----------+-----------+ > > So from this info one can not see anymore if the property was e.g. > [[Prop::Name1;Source1]] or [[Prop::Source1;Name1]] > and [[Prop::Name3;?]] or [[Prop::?;Name3]] etc. > > Is the order now maybe stored somewhere else in the DB tables? > Would be most grateful if someone could give me a hint. On the data level, records are "containers" and store data without any order. Containers are basically like "Factboxes" in SMW: sets of property-value pairs. Type:Record used to use special properties "_1", "_2", ... to encode the order, but the order was still unknown to the store (it was just the higher level of the Record that interpreted these special properties as ordinal). In the current code, the declaration of Type:Record still uses an ordered list of properties, so the order is known on this level. When Records are displayed or queried, this information is still available (as before, but not with fixed property names "_1", "_2", ...). As before, the order is not considered to be part of the data. [Potential weakness of allowing arbitrary property names instead of _1, _2, ...: they will not work well when the same property is used more than once. This also affects the use of "type properties" like "String" that are now supported. In general, Record should become part of an extended set of container datatypes that provide more features than just storing finite lists of properties -- future improvements on this level should be part of this effort.] A recent change in SVN (Jeroen?) has moved the creation of value lists to the container dataitem of SMW which (as explained above) cannot possibly reconstruct the order. So code relying on this method will confuse the order now. This needs to be fixed by moving the list creation back into the datavalue code. Regards, Markus |
From: Jeroen De D. <jer...@gm...> - 2011-07-10 13:10:35
|
Hey, > A recent change in SVN (Jeroen?) has moved the creation of value lists to the container dataitem of SMW which (as explained above) cannot possibly reconstruct the order. Indeed, I was not aware that order is relevant in that code. Will have a look at it soonish; these changes address some other issue which I can't recall ATM. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- |
From: Markus K. <ma...@se...> - 2011-07-10 13:45:47
|
On 10/07/11 14:10, Jeroen De Dauw wrote: > Hey, > > > A recent change in SVN (Jeroen?) has moved the creation of value > lists to the container dataitem of SMW which (as explained above) cannot > possibly reconstruct the order. > > Indeed, I was not aware that order is relevant in that code. Will have a > look at it soonish; these changes address some other issue which I can't > recall ATM. I think this list should mainly affect the printout modifier that allows you to specify that only one position of a record should be printed. In the end, this code will need to be reworked anyway, and I don't really see how we can keep Record (DV) specific code in QueryResult. The code should at most be Container (DI) specific. But still good if we could fix it for the moment. Markus |