From: Benjamin P. <bjp...@gm...> - 2013-11-20 21:43:15
|
Issue 1: I have a category of pages called Canyons and I've designed my Semantic Form to allow entering a bunch of simple data followed by a number of pre-determined sections. This is great for creating pages, but SF seems to choke when parsing the page content back into the pre-determined sections if subsections (=== subsection ===) are used. For example, this page works fine -- view the form to see all the content placed into the correct section boxes: http://ropewiki.com/index.php/Test_Canyon_2 But, this page is hopelessly mangled -- view the form to see content placed all over the place (and partially duplicated!): http://ropewiki.com/index.php/Test_Canyon As you can see, the Approach content is truncated at the subsection marker, the rest of the Approach content is put into Free text, the Descent section is also put into Free text (!) but also duplicated in Descent, the Exit info is appended to Descent, etc, etc Is there already a known bug for dealing with this problem? Is there anything I can do differently to get things to work properly (other than not using subsections -- that's not an acceptable solution)? Issue 2: What I'd really like to do is to not have a section header for Introduction so that the text in that box gets placed above the table of contents. Basically, I want the result to look like this: http://ropewiki.com/index.php/Eaton_Canyon Is it possible to define a section-headerless page section in a Semantic Form and also have Free text at the end (or where ever)? Where in the SF code should I go to find the routine that parses current page content into a form to see how it works? Thanks, and thanks for creating such a great product! --Ben |
From: Yaron K. <ya...@wi...> - 2013-11-20 22:23:34
|
Hi Ben, Wow, great! I believe this is the first real-world usage that I've seen of the new "section" feature in Semantic Forms. (It was added in version 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever bug report. :) Your diagnosis is correct - the subsections within that section are messing up the parsing. I guess we didn't think about the possibility of users adding subsections when we planned this feature. We'll look into this - maybe there's an easy fix. If you want to look into it yourself, I think the relevant code is around lines 1415-1450 of /includes/SF_FormPrinter.php. To answer your other question: you can make an output like that, via a hack: make the top introductory text be another field within the main template, and then have the template display that field by itself, above the infobox table. (You could also, in theory, take that same approach for all the page sections below the infobox - and some people have done that - although that's an even bigger hack, and it leads to various problems, most notably that parsing gets messed up if there's a "|" anywhere in the text.) -Yaron On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier <bjp...@gm...>wrote: > Issue 1: > I have a category of pages called Canyons and I've designed my Semantic > Form to allow entering a bunch of simple data followed by a number of > pre-determined sections. This is great for creating pages, but SF seems to > choke when parsing the page content back into the pre-determined sections > if subsections (=== subsection ===) are used. > > For example, this page works fine -- view the form to see all the content > placed into the correct section boxes: > http://ropewiki.com/index.php/Test_Canyon_2 > > But, this page is hopelessly mangled -- view the form to see content > placed all over the place (and partially duplicated!): > http://ropewiki.com/index.php/Test_Canyon > As you can see, the Approach content is truncated at the subsection > marker, the rest of the Approach content is put into Free text, the Descent > section is also put into Free text (!) but also duplicated in Descent, the > Exit info is appended to Descent, etc, etc > > Is there already a known bug for dealing with this problem? Is there > anything I can do differently to get things to work properly (other than > not using subsections -- that's not an acceptable solution)? > > Issue 2: > What I'd really like to do is to not have a section header for > Introduction so that the text in that box gets placed above the table of > contents. Basically, I want the result to look like this: > http://ropewiki.com/index.php/Eaton_Canyon > > Is it possible to define a section-headerless page section in a Semantic > Form and also have Free text at the end (or where ever)? > > Where in the SF code should I go to find the routine that parses current > page content into a form to see how it works? > > Thanks, and thanks for creating such a great product! > --Ben > > > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up > now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > Semediawiki-devel mailing list > Sem...@li... > https://lists.sourceforge.net/lists/listinfo/semediawiki-devel > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Benjamin P. <bjp...@gm...> - 2013-11-20 22:41:22
|
Ah, nice, I didn't realize the "section" feature was that recent -- I just discovered Semantic a week or two ago and the process is just beautiful (I'm not yet finished with it). I'll let you guys take a look [at the subsection parsing thing] first since it would take me a fair amount of effort to spool up my understanding of how everything works. But if it turns out to be difficult then maybe I can give it a shot because I'd really like to have subsections work with the section feature. Thanks for the code line pointer -- I'll take a look at that for background regardless. The separate Introduction input makes sense -- that seems like a pretty reasonable hack and I think I'll adopt that approach. I should be able to instruct my users to use {{!}} instead of | in the Introduction and everything will work, right? (I already have the ! Template defined) I think I understand the benefits and drawbacks to property-izing the content and you're correct, I don't want to do that. I'm a little surprised about the | issue though -- on the one hand, I understand why that could cause problems. But on the other hand, wouldn't it be possible to sanitize and desanitize the content? Or do extensions dynamically generate wiki code rather than HTML code? (I'm not familiar with MediaWiki's architecture) Thanks again! --Ben On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <ya...@wi...> wrote: > Hi Ben, > > Wow, great! I believe this is the first real-world usage that I've seen of > the new "section" feature in Semantic Forms. (It was added in version 2.6, > about a month ago.) Unfortunately, it's accompanied by the first-ever bug > report. :) Your diagnosis is correct - the subsections within that section > are messing up the parsing. I guess we didn't think about the possibility > of users adding subsections when we planned this feature. We'll look into > this - maybe there's an easy fix. If you want to look into it yourself, I > think the relevant code is around lines 1415-1450 of > /includes/SF_FormPrinter.php. > > To answer your other question: you can make an output like that, via a > hack: make the top introductory text be another field within the main > template, and then have the template display that field by itself, above > the infobox table. > > (You could also, in theory, take that same approach for all the page > sections below the infobox - and some people have done that - although > that's an even bigger hack, and it leads to various problems, most notably > that parsing gets messed up if there's a "|" anywhere in the text.) > > -Yaron > > > On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier <bjp...@gm...>wrote: > >> Issue 1: >> I have a category of pages called Canyons and I've designed my Semantic >> Form to allow entering a bunch of simple data followed by a number of >> pre-determined sections. This is great for creating pages, but SF seems to >> choke when parsing the page content back into the pre-determined sections >> if subsections (=== subsection ===) are used. >> >> For example, this page works fine -- view the form to see all the content >> placed into the correct section boxes: >> http://ropewiki.com/index.php/Test_Canyon_2 >> >> But, this page is hopelessly mangled -- view the form to see content >> placed all over the place (and partially duplicated!): >> http://ropewiki.com/index.php/Test_Canyon >> As you can see, the Approach content is truncated at the subsection >> marker, the rest of the Approach content is put into Free text, the Descent >> section is also put into Free text (!) but also duplicated in Descent, the >> Exit info is appended to Descent, etc, etc >> >> Is there already a known bug for dealing with this problem? Is there >> anything I can do differently to get things to work properly (other than >> not using subsections -- that's not an acceptable solution)? >> >> Issue 2: >> What I'd really like to do is to not have a section header for >> Introduction so that the text in that box gets placed above the table of >> contents. Basically, I want the result to look like this: >> http://ropewiki.com/index.php/Eaton_Canyon >> >> Is it possible to define a section-headerless page section in a Semantic >> Form and also have Free text at the end (or where ever)? >> >> Where in the SF code should I go to find the routine that parses current >> page content into a form to see how it works? >> >> Thanks, and thanks for creating such a great product! >> --Ben >> >> >> ------------------------------------------------------------------------------ >> Shape the Mobile Experience: Free Subscription >> Software experts and developers: Be at the forefront of tech innovation. >> Intel(R) Software Adrenaline delivers strategic insight and game-changing >> conversations that shape the rapidly evolving mobile landscape. Sign up >> now. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >> _______________________________________________ >> Semediawiki-devel mailing list >> Sem...@li... >> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |
From: Yaron K. <ya...@wi...> - 2013-11-20 23:26:05
|
Hi Ben, Well, maybe it's not surprising that the first person to use the "section" tag is a new user. You have a blank canvas for your data! You should be able to tell people to use "{{!}}", yes. Escaping and un-escaping pipes would be difficult, actually - there are various complications, like that the form can't know for sure what the intended variant was, and that (contrary to what I said before) sometimes pipes *are* allowed - if you have a parser function like "{{#if:...", I think pipes within there are fine. (That is, they're fine for template calls - SF fails on them, I believe.) Semantic Forms' handling could definitely be improved, but I don't think it'll ever be perfect. -Yaron On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier <bjp...@gm...>wrote: > Ah, nice, I didn't realize the "section" feature was that recent -- I just > discovered Semantic a week or two ago and the process is just beautiful > (I'm not yet finished with it). I'll let you guys take a look [at the > subsection parsing thing] first since it would take me a fair amount of > effort to spool up my understanding of how everything works. But if it > turns out to be difficult then maybe I can give it a shot because I'd > really like to have subsections work with the section feature. Thanks for > the code line pointer -- I'll take a look at that for background regardless. > > The separate Introduction input makes sense -- that seems like a pretty > reasonable hack and I think I'll adopt that approach. I should be able to > instruct my users to use {{!}} instead of | in the Introduction and > everything will work, right? (I already have the ! Template defined) > > I think I understand the benefits and drawbacks to property-izing the > content and you're correct, I don't want to do that. I'm a little > surprised about the | issue though -- on the one hand, I understand why > that could cause problems. But on the other hand, wouldn't it be possible > to sanitize and desanitize the content? Or do extensions dynamically > generate wiki code rather than HTML code? (I'm not familiar with > MediaWiki's architecture) > > Thanks again! > --Ben > > > On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <ya...@wi...> wrote: > >> Hi Ben, >> >> Wow, great! I believe this is the first real-world usage that I've seen >> of the new "section" feature in Semantic Forms. (It was added in version >> 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever >> bug report. :) Your diagnosis is correct - the subsections within that >> section are messing up the parsing. I guess we didn't think about the >> possibility of users adding subsections when we planned this feature. We'll >> look into this - maybe there's an easy fix. If you want to look into it >> yourself, I think the relevant code is around lines 1415-1450 of >> /includes/SF_FormPrinter.php. >> >> To answer your other question: you can make an output like that, via a >> hack: make the top introductory text be another field within the main >> template, and then have the template display that field by itself, above >> the infobox table. >> >> (You could also, in theory, take that same approach for all the page >> sections below the infobox - and some people have done that - although >> that's an even bigger hack, and it leads to various problems, most notably >> that parsing gets messed up if there's a "|" anywhere in the text.) >> >> -Yaron >> >> >> On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier <bjp...@gm... >> > wrote: >> >>> Issue 1: >>> I have a category of pages called Canyons and I've designed my Semantic >>> Form to allow entering a bunch of simple data followed by a number of >>> pre-determined sections. This is great for creating pages, but SF seems to >>> choke when parsing the page content back into the pre-determined sections >>> if subsections (=== subsection ===) are used. >>> >>> For example, this page works fine -- view the form to see all the >>> content placed into the correct section boxes: >>> http://ropewiki.com/index.php/Test_Canyon_2 >>> >>> But, this page is hopelessly mangled -- view the form to see content >>> placed all over the place (and partially duplicated!): >>> http://ropewiki.com/index.php/Test_Canyon >>> As you can see, the Approach content is truncated at the subsection >>> marker, the rest of the Approach content is put into Free text, the Descent >>> section is also put into Free text (!) but also duplicated in Descent, the >>> Exit info is appended to Descent, etc, etc >>> >>> Is there already a known bug for dealing with this problem? Is there >>> anything I can do differently to get things to work properly (other than >>> not using subsections -- that's not an acceptable solution)? >>> >>> Issue 2: >>> What I'd really like to do is to not have a section header for >>> Introduction so that the text in that box gets placed above the table of >>> contents. Basically, I want the result to look like this: >>> http://ropewiki.com/index.php/Eaton_Canyon >>> >>> Is it possible to define a section-headerless page section in a Semantic >>> Form and also have Free text at the end (or where ever)? >>> >>> Where in the SF code should I go to find the routine that parses current >>> page content into a form to see how it works? >>> >>> Thanks, and thanks for creating such a great product! >>> --Ben >>> >>> >>> ------------------------------------------------------------------------------ >>> Shape the Mobile Experience: Free Subscription >>> Software experts and developers: Be at the forefront of tech innovation. >>> Intel(R) Software Adrenaline delivers strategic insight and game-changing >>> conversations that shape the rapidly evolving mobile landscape. Sign up >>> now. >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Semediawiki-devel mailing list >>> Sem...@li... >>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>> >>> >> >> >> -- >> WikiWorks · MediaWiki Consulting · http://wikiworks.com >> > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Benjamin P. <bjp...@gm...> - 2013-11-20 23:31:27
|
Awesome, sounds good. I'll implement the changes on my wiki and look forward to finding out whether the subsection fix would be easy. If it isn't, I'll see if I can dig in to changing it myself. Does SF have a bug reporting system for me to list this bug in? Thanks once more for all the responses! On Wed, Nov 20, 2013 at 3:25 PM, Yaron Koren <ya...@wi...> wrote: > Hi Ben, > > Well, maybe it's not surprising that the first person to use the "section" > tag is a new user. You have a blank canvas for your data! > > You should be able to tell people to use "{{!}}", yes. > > Escaping and un-escaping pipes would be difficult, actually - there are > various complications, like that the form can't know for sure what the > intended variant was, and that (contrary to what I said before) sometimes > pipes *are* allowed - if you have a parser function like "{{#if:...", I > think pipes within there are fine. (That is, they're fine for template > calls - SF fails on them, I believe.) Semantic Forms' handling could > definitely be improved, but I don't think it'll ever be perfect. > > -Yaron > > > On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier <bjp...@gm...>wrote: > >> Ah, nice, I didn't realize the "section" feature was that recent -- I >> just discovered Semantic a week or two ago and the process is just >> beautiful (I'm not yet finished with it). I'll let you guys take a look >> [at the subsection parsing thing] first since it would take me a fair >> amount of effort to spool up my understanding of how everything works. But >> if it turns out to be difficult then maybe I can give it a shot because I'd >> really like to have subsections work with the section feature. Thanks for >> the code line pointer -- I'll take a look at that for background regardless. >> >> The separate Introduction input makes sense -- that seems like a pretty >> reasonable hack and I think I'll adopt that approach. I should be able to >> instruct my users to use {{!}} instead of | in the Introduction and >> everything will work, right? (I already have the ! Template defined) >> >> I think I understand the benefits and drawbacks to property-izing the >> content and you're correct, I don't want to do that. I'm a little >> surprised about the | issue though -- on the one hand, I understand why >> that could cause problems. But on the other hand, wouldn't it be possible >> to sanitize and desanitize the content? Or do extensions dynamically >> generate wiki code rather than HTML code? (I'm not familiar with >> MediaWiki's architecture) >> >> Thanks again! >> --Ben >> >> >> On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <ya...@wi...> wrote: >> >>> Hi Ben, >>> >>> Wow, great! I believe this is the first real-world usage that I've seen >>> of the new "section" feature in Semantic Forms. (It was added in version >>> 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever >>> bug report. :) Your diagnosis is correct - the subsections within that >>> section are messing up the parsing. I guess we didn't think about the >>> possibility of users adding subsections when we planned this feature. We'll >>> look into this - maybe there's an easy fix. If you want to look into it >>> yourself, I think the relevant code is around lines 1415-1450 of >>> /includes/SF_FormPrinter.php. >>> >>> To answer your other question: you can make an output like that, via a >>> hack: make the top introductory text be another field within the main >>> template, and then have the template display that field by itself, above >>> the infobox table. >>> >>> (You could also, in theory, take that same approach for all the page >>> sections below the infobox - and some people have done that - although >>> that's an even bigger hack, and it leads to various problems, most notably >>> that parsing gets messed up if there's a "|" anywhere in the text.) >>> >>> -Yaron >>> >>> >>> On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier < >>> bjp...@gm...> wrote: >>> >>>> Issue 1: >>>> I have a category of pages called Canyons and I've designed my Semantic >>>> Form to allow entering a bunch of simple data followed by a number of >>>> pre-determined sections. This is great for creating pages, but SF seems to >>>> choke when parsing the page content back into the pre-determined sections >>>> if subsections (=== subsection ===) are used. >>>> >>>> For example, this page works fine -- view the form to see all the >>>> content placed into the correct section boxes: >>>> http://ropewiki.com/index.php/Test_Canyon_2 >>>> >>>> But, this page is hopelessly mangled -- view the form to see content >>>> placed all over the place (and partially duplicated!): >>>> http://ropewiki.com/index.php/Test_Canyon >>>> As you can see, the Approach content is truncated at the subsection >>>> marker, the rest of the Approach content is put into Free text, the Descent >>>> section is also put into Free text (!) but also duplicated in Descent, the >>>> Exit info is appended to Descent, etc, etc >>>> >>>> Is there already a known bug for dealing with this problem? Is there >>>> anything I can do differently to get things to work properly (other than >>>> not using subsections -- that's not an acceptable solution)? >>>> >>>> Issue 2: >>>> What I'd really like to do is to not have a section header for >>>> Introduction so that the text in that box gets placed above the table of >>>> contents. Basically, I want the result to look like this: >>>> http://ropewiki.com/index.php/Eaton_Canyon >>>> >>>> Is it possible to define a section-headerless page section in a >>>> Semantic Form and also have Free text at the end (or where ever)? >>>> >>>> Where in the SF code should I go to find the routine that parses >>>> current page content into a form to see how it works? >>>> >>>> Thanks, and thanks for creating such a great product! >>>> --Ben >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Shape the Mobile Experience: Free Subscription >>>> Software experts and developers: Be at the forefront of tech innovation. >>>> Intel(R) Software Adrenaline delivers strategic insight and >>>> game-changing >>>> conversations that shape the rapidly evolving mobile landscape. Sign up >>>> now. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> Semediawiki-devel mailing list >>>> Sem...@li... >>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>>> >>>> >>> >>> >>> -- >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>> >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |
From: Yaron K. <ya...@wi...> - 2013-11-20 23:36:48
|
Hi Ben, Yes, you can use the Wikimedia Bugzilla: https://bugzilla.wikimedia.org/ Select the "MediaWiki extensions" product, and the "SemanticForms" component. On Wed, Nov 20, 2013 at 6:31 PM, Benjamin Pelletier <bjp...@gm...>wrote: > Awesome, sounds good. I'll implement the changes on my wiki and look > forward to finding out whether the subsection fix would be easy. If it > isn't, I'll see if I can dig in to changing it myself. Does SF have a bug > reporting system for me to list this bug in? > > Thanks once more for all the responses! > > > On Wed, Nov 20, 2013 at 3:25 PM, Yaron Koren <ya...@wi...> wrote: > >> Hi Ben, >> >> Well, maybe it's not surprising that the first person to use the >> "section" tag is a new user. You have a blank canvas for your data! >> >> You should be able to tell people to use "{{!}}", yes. >> >> Escaping and un-escaping pipes would be difficult, actually - there are >> various complications, like that the form can't know for sure what the >> intended variant was, and that (contrary to what I said before) sometimes >> pipes *are* allowed - if you have a parser function like "{{#if:...", I >> think pipes within there are fine. (That is, they're fine for template >> calls - SF fails on them, I believe.) Semantic Forms' handling could >> definitely be improved, but I don't think it'll ever be perfect. >> >> -Yaron >> >> >> On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier <bjp...@gm... >> > wrote: >> >>> Ah, nice, I didn't realize the "section" feature was that recent -- I >>> just discovered Semantic a week or two ago and the process is just >>> beautiful (I'm not yet finished with it). I'll let you guys take a look >>> [at the subsection parsing thing] first since it would take me a fair >>> amount of effort to spool up my understanding of how everything works. But >>> if it turns out to be difficult then maybe I can give it a shot because I'd >>> really like to have subsections work with the section feature. Thanks for >>> the code line pointer -- I'll take a look at that for background regardless. >>> >>> The separate Introduction input makes sense -- that seems like a pretty >>> reasonable hack and I think I'll adopt that approach. I should be able to >>> instruct my users to use {{!}} instead of | in the Introduction and >>> everything will work, right? (I already have the ! Template defined) >>> >>> I think I understand the benefits and drawbacks to property-izing the >>> content and you're correct, I don't want to do that. I'm a little >>> surprised about the | issue though -- on the one hand, I understand why >>> that could cause problems. But on the other hand, wouldn't it be possible >>> to sanitize and desanitize the content? Or do extensions dynamically >>> generate wiki code rather than HTML code? (I'm not familiar with >>> MediaWiki's architecture) >>> >>> Thanks again! >>> --Ben >>> >>> >>> On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <ya...@wi...>wrote: >>> >>>> Hi Ben, >>>> >>>> Wow, great! I believe this is the first real-world usage that I've seen >>>> of the new "section" feature in Semantic Forms. (It was added in version >>>> 2.6, about a month ago.) Unfortunately, it's accompanied by the first-ever >>>> bug report. :) Your diagnosis is correct - the subsections within that >>>> section are messing up the parsing. I guess we didn't think about the >>>> possibility of users adding subsections when we planned this feature. We'll >>>> look into this - maybe there's an easy fix. If you want to look into it >>>> yourself, I think the relevant code is around lines 1415-1450 of >>>> /includes/SF_FormPrinter.php. >>>> >>>> To answer your other question: you can make an output like that, via a >>>> hack: make the top introductory text be another field within the main >>>> template, and then have the template display that field by itself, above >>>> the infobox table. >>>> >>>> (You could also, in theory, take that same approach for all the page >>>> sections below the infobox - and some people have done that - although >>>> that's an even bigger hack, and it leads to various problems, most notably >>>> that parsing gets messed up if there's a "|" anywhere in the text.) >>>> >>>> -Yaron >>>> >>>> >>>> On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier < >>>> bjp...@gm...> wrote: >>>> >>>>> Issue 1: >>>>> I have a category of pages called Canyons and I've designed my >>>>> Semantic Form to allow entering a bunch of simple data followed by a number >>>>> of pre-determined sections. This is great for creating pages, but SF seems >>>>> to choke when parsing the page content back into the pre-determined >>>>> sections if subsections (=== subsection ===) are used. >>>>> >>>>> For example, this page works fine -- view the form to see all the >>>>> content placed into the correct section boxes: >>>>> http://ropewiki.com/index.php/Test_Canyon_2 >>>>> >>>>> But, this page is hopelessly mangled -- view the form to see content >>>>> placed all over the place (and partially duplicated!): >>>>> http://ropewiki.com/index.php/Test_Canyon >>>>> As you can see, the Approach content is truncated at the subsection >>>>> marker, the rest of the Approach content is put into Free text, the Descent >>>>> section is also put into Free text (!) but also duplicated in Descent, the >>>>> Exit info is appended to Descent, etc, etc >>>>> >>>>> Is there already a known bug for dealing with this problem? Is there >>>>> anything I can do differently to get things to work properly (other than >>>>> not using subsections -- that's not an acceptable solution)? >>>>> >>>>> Issue 2: >>>>> What I'd really like to do is to not have a section header for >>>>> Introduction so that the text in that box gets placed above the table of >>>>> contents. Basically, I want the result to look like this: >>>>> http://ropewiki.com/index.php/Eaton_Canyon >>>>> >>>>> Is it possible to define a section-headerless page section in a >>>>> Semantic Form and also have Free text at the end (or where ever)? >>>>> >>>>> Where in the SF code should I go to find the routine that parses >>>>> current page content into a form to see how it works? >>>>> >>>>> Thanks, and thanks for creating such a great product! >>>>> --Ben >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Shape the Mobile Experience: Free Subscription >>>>> Software experts and developers: Be at the forefront of tech >>>>> innovation. >>>>> Intel(R) Software Adrenaline delivers strategic insight and >>>>> game-changing >>>>> conversations that shape the rapidly evolving mobile landscape. Sign >>>>> up now. >>>>> >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>> _______________________________________________ >>>>> Semediawiki-devel mailing list >>>>> Sem...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>>>> >>>>> >>>> >>>> >>>> -- >>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>>> >>> >>> >> >> >> -- >> WikiWorks · MediaWiki Consulting · http://wikiworks.com >> > > -- WikiWorks · MediaWiki Consulting · http://wikiworks.com |
From: Benjamin P. <bjp...@gm...> - 2013-11-25 18:25:32
|
Just an update on this: I changed the regular expression on line 1422 to '/(^==[^=].*[^=]==\s*?$)/m' to get things working on my site. Unfortunately, this isn't a general fix because it 1) doesn't allow pre-defined section headings with only one character and 2) doesn't recognize predefined sections with any level other than 2. Neither of these problems are issues for my site so the fix works great, but it's not something I recommend merging into trunk. I am still having a few other difficulties with section parsing in Semantic Forms, but I'm still working on those to figure out what the root cause is. On Wed, Nov 20, 2013 at 3:36 PM, Yaron Koren <ya...@wi...> wrote: > Hi Ben, > > Yes, you can use the Wikimedia Bugzilla: > > https://bugzilla.wikimedia.org/ > > Select the "MediaWiki extensions" product, and the "SemanticForms" > component. > > > On Wed, Nov 20, 2013 at 6:31 PM, Benjamin Pelletier <bjp...@gm...>wrote: > >> Awesome, sounds good. I'll implement the changes on my wiki and look >> forward to finding out whether the subsection fix would be easy. If it >> isn't, I'll see if I can dig in to changing it myself. Does SF have a bug >> reporting system for me to list this bug in? >> >> Thanks once more for all the responses! >> >> >> On Wed, Nov 20, 2013 at 3:25 PM, Yaron Koren <ya...@wi...> wrote: >> >>> Hi Ben, >>> >>> Well, maybe it's not surprising that the first person to use the >>> "section" tag is a new user. You have a blank canvas for your data! >>> >>> You should be able to tell people to use "{{!}}", yes. >>> >>> Escaping and un-escaping pipes would be difficult, actually - there are >>> various complications, like that the form can't know for sure what the >>> intended variant was, and that (contrary to what I said before) sometimes >>> pipes *are* allowed - if you have a parser function like "{{#if:...", I >>> think pipes within there are fine. (That is, they're fine for template >>> calls - SF fails on them, I believe.) Semantic Forms' handling could >>> definitely be improved, but I don't think it'll ever be perfect. >>> >>> -Yaron >>> >>> >>> On Wed, Nov 20, 2013 at 5:41 PM, Benjamin Pelletier < >>> bjp...@gm...> wrote: >>> >>>> Ah, nice, I didn't realize the "section" feature was that recent -- I >>>> just discovered Semantic a week or two ago and the process is just >>>> beautiful (I'm not yet finished with it). I'll let you guys take a look >>>> [at the subsection parsing thing] first since it would take me a fair >>>> amount of effort to spool up my understanding of how everything works. But >>>> if it turns out to be difficult then maybe I can give it a shot because I'd >>>> really like to have subsections work with the section feature. Thanks for >>>> the code line pointer -- I'll take a look at that for background regardless. >>>> >>>> The separate Introduction input makes sense -- that seems like a pretty >>>> reasonable hack and I think I'll adopt that approach. I should be able to >>>> instruct my users to use {{!}} instead of | in the Introduction and >>>> everything will work, right? (I already have the ! Template defined) >>>> >>>> I think I understand the benefits and drawbacks to property-izing the >>>> content and you're correct, I don't want to do that. I'm a little >>>> surprised about the | issue though -- on the one hand, I understand why >>>> that could cause problems. But on the other hand, wouldn't it be possible >>>> to sanitize and desanitize the content? Or do extensions dynamically >>>> generate wiki code rather than HTML code? (I'm not familiar with >>>> MediaWiki's architecture) >>>> >>>> Thanks again! >>>> --Ben >>>> >>>> >>>> On Wed, Nov 20, 2013 at 2:23 PM, Yaron Koren <ya...@wi...>wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> Wow, great! I believe this is the first real-world usage that I've >>>>> seen of the new "section" feature in Semantic Forms. (It was added in >>>>> version 2.6, about a month ago.) Unfortunately, it's accompanied by the >>>>> first-ever bug report. :) Your diagnosis is correct - the subsections >>>>> within that section are messing up the parsing. I guess we didn't think >>>>> about the possibility of users adding subsections when we planned this >>>>> feature. We'll look into this - maybe there's an easy fix. If you want to >>>>> look into it yourself, I think the relevant code is around lines 1415-1450 >>>>> of /includes/SF_FormPrinter.php. >>>>> >>>>> To answer your other question: you can make an output like that, via a >>>>> hack: make the top introductory text be another field within the main >>>>> template, and then have the template display that field by itself, above >>>>> the infobox table. >>>>> >>>>> (You could also, in theory, take that same approach for all the page >>>>> sections below the infobox - and some people have done that - although >>>>> that's an even bigger hack, and it leads to various problems, most notably >>>>> that parsing gets messed up if there's a "|" anywhere in the text.) >>>>> >>>>> -Yaron >>>>> >>>>> >>>>> On Wed, Nov 20, 2013 at 4:43 PM, Benjamin Pelletier < >>>>> bjp...@gm...> wrote: >>>>> >>>>>> Issue 1: >>>>>> I have a category of pages called Canyons and I've designed my >>>>>> Semantic Form to allow entering a bunch of simple data followed by a number >>>>>> of pre-determined sections. This is great for creating pages, but SF seems >>>>>> to choke when parsing the page content back into the pre-determined >>>>>> sections if subsections (=== subsection ===) are used. >>>>>> >>>>>> For example, this page works fine -- view the form to see all the >>>>>> content placed into the correct section boxes: >>>>>> http://ropewiki.com/index.php/Test_Canyon_2 >>>>>> >>>>>> But, this page is hopelessly mangled -- view the form to see content >>>>>> placed all over the place (and partially duplicated!): >>>>>> http://ropewiki.com/index.php/Test_Canyon >>>>>> As you can see, the Approach content is truncated at the subsection >>>>>> marker, the rest of the Approach content is put into Free text, the Descent >>>>>> section is also put into Free text (!) but also duplicated in Descent, the >>>>>> Exit info is appended to Descent, etc, etc >>>>>> >>>>>> Is there already a known bug for dealing with this problem? Is there >>>>>> anything I can do differently to get things to work properly (other than >>>>>> not using subsections -- that's not an acceptable solution)? >>>>>> >>>>>> Issue 2: >>>>>> What I'd really like to do is to not have a section header for >>>>>> Introduction so that the text in that box gets placed above the table of >>>>>> contents. Basically, I want the result to look like this: >>>>>> http://ropewiki.com/index.php/Eaton_Canyon >>>>>> >>>>>> Is it possible to define a section-headerless page section in a >>>>>> Semantic Form and also have Free text at the end (or where ever)? >>>>>> >>>>>> Where in the SF code should I go to find the routine that parses >>>>>> current page content into a form to see how it works? >>>>>> >>>>>> Thanks, and thanks for creating such a great product! >>>>>> --Ben >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Shape the Mobile Experience: Free Subscription >>>>>> Software experts and developers: Be at the forefront of tech >>>>>> innovation. >>>>>> Intel(R) Software Adrenaline delivers strategic insight and >>>>>> game-changing >>>>>> conversations that shape the rapidly evolving mobile landscape. Sign >>>>>> up now. >>>>>> >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk >>>>>> _______________________________________________ >>>>>> Semediawiki-devel mailing list >>>>>> Sem...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/semediawiki-devel >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>>>> >>>> >>>> >>> >>> >>> -- >>> WikiWorks · MediaWiki Consulting · http://wikiworks.com >>> >> >> > > > -- > WikiWorks · MediaWiki Consulting · http://wikiworks.com > |