From: James H. K. <jam...@gm...> - 2011-01-14 17:38:49
|
Hi Stephan, Despite the fact that we can't get #floatlink to work, we managed to use #floatinput. The following call {{#floatinput:form=Glossary|size=50|query string=namespace=Glossary}} would allow to see a iframe with the related form. So far so good, the issues is now that within the form we have defined several tables such as {| class="formtable collapsible collapsed" style="width:100%; border:1px;" ! style="text-align: left; color: rgb(64, 62, 60); border-bottom-color: #ebeff9; font-size:105%; font-weight: bold; line-height:120%; padding:0.4em; background-color:#ebeff9; border-top:1px solid #d3e1f9; margin-bottom:10px; margin-top:10px;" border:1px; colspan="2" |Glossary Header |- ... those allow to have collapsed form inputs that works well in normal creation mode. But when presented in the iframe and one presses of of those collapsed tables the float window would stop and the original window that called the input form would show "javascript:collapseTable(0);" and display a "false". A comparable form can be found at http://mwjames.referata.com/wiki/Form:Glossary which we used as test for floatinput / floatlink. Hope this helps ... One thing though, we still use the Extensions:UsabilityInitiative, just as a hint not that this causes similar trouble as it was the case with the SemanticInputFormat. Cheers, MWJames On Fri, Jan 14, 2011 at 8:40 PM, James Hong Kong <jam...@gm...> wrote: > Hi Stephan, > > Looks nice, but we have some feedback (tested Chrome, Firefox): > > On our local test system the following test form and its inline > > {{#floatlink:form=Glossary|link text=Glossary|link type=link|query > string=Glossary%5Bterm%5D={{#replace:test| > |%20}}&form=Glossary&target=Glossary:test}} > > will not to open a float window but instead goes directly to the > special edit page of > > http://192.168.1.101:8080/a/index.php/Special:FormEdit/Glossary?Glossary[term]=test&form=Glossary&target=Glossary:test > > The Firefox error console shows the follwing message > > Error: params[i].split is not a function > Source File: http://192.168.1.101:8080/a/extensions/FloatEdit/libs/floatedit.js > Line: 80 > > Error: sfgAdderButtons[i].split is not a function > Source File: http://192.168.1.101:8080/a/extensions/SemanticForms/libs/SemanticForms.js?270 > Line: 789 > > The call {{#floatlink:form=Book|link text=Reference|link > type=link|query string=form=Reference&target={{{1}}}}} > > produces a sever error as at the time the link is clicked {{{1}}} is > not defined and the website encountered an error while retrieving > http://192.168.1.101:8080/a/index.php/Special:FormEdit/Book?form=Reference&target={{{1}}} > > It would be nice to define height and width of the float window per > form, as those can vary in size due to the data in preparation for > input. > > System environment: > > MediaWiki 1.16.0, PHP 5.2.13 > > Semantic Compound Queries (Version 0.2.6) (r77478), Semantic Drilldown > (Version 0.8) (r78485), Semantic Forms (Version 2.0.8) (r79826), > Semantic Forms Inputs (Version 0.4 alpha) (r79339), Semantic MediaWiki > (Version 1.5.5 alpha) (r80031), Semantic Result Formats (Version > 1.5.2) (r80031) > > We think this could be useful extension but a SVN version would be > nice otherwise updating and track keeping gets a bit difficult. > > Cheers, > > MWJames > > > On Fri, Jan 14, 2011 at 7:04 PM, Stephan Gambke <f....@gm...> wrote: >> Hi Patrick, >> >> thanks for the feedback. >> >>> This doesn't work for me - after saving the form, the resulting page >>> just loads in the iframe. When I close the iframe with the (X) on the >>> upper right, the parent page (that contains the #floatlink) does not >>> reload. >> >> This sounds as if the JavaScript inside the iframe breaks down somewhere. >> What browser do you use? And what version of MW? Oh, and what other extensions? Are there any JavaScript errors reported (e.g. on the FireFox error console)? >> >> >>> Currently, when clicking both type 1 and type 2 links, the iframe >>> disappears. I don't know much about iframes, but I guess this problem >>> won't be easy to solve. Hope there is a way though! >> >> It's not a bug, it's a feature. :) >> Currently an event handler is attached to all links in the form so when they are clicked, the iframe closes and the link is opened in the main window. This is to avoid "nested browsing". This means type 1 links can easily be fixed by checking the link's target attribute before redirecting it. I have to look into the HeaderTabs issue. >> >> Stephan >> -- >> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit >> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Semediawiki-user mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-user >> > |
From: Stephan G. <f....@gm...> - 2011-01-14 18:33:42
|
Hi James, thanks for your feedback. Am 14.01.2011 18:38, schrieb James Hong Kong: > ... > creation mode. But when presented in the iframe and one presses of of > those collapsed tables the float window would stop and the original > window that called the input form would show > "javascript:collapseTable(0);" and display a "false". It's that redirected links again! > One thing though, we still use the Extensions:UsabilityInitiative, > just as a hint not that this causes similar trouble as it was the case > with the SemanticInputFormat. I am not sure there is a real cure here, at least not for MW 1.16. The UsabilityInitiative uses it's own built-in jQuery, which in some situations clashes with the MW version of jQuery. I think there is a chance this gets cured in MW 1.17 with the new ResourceLoader. Stephan |