#foswiki 2015-12-12,Sat

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
GithubBot[distro] gac410 pushed 1 new commit to master: http://git.io/v0OLo
distro/master 4554e77 George Clark: Item13880: Rendering issues in UserRegistrationParts zones...
[02:54]
***GithubBot has left [02:54]
FoswikiBothttp://foswiki.org/Tasks/Item13880 [ Item13880: WebCreateNewTopicComponents inserts malformed meta statement ] [02:54]
..................................... (idle for 3h0mn)
***gac410 has left [05:54]
..................... (idle for 1h40mn)
ChanServ sets mode: +o CDot [07:34]
................................................................................ (idle for 6h35mn)
ChanServ sets mode: +o gac410 [14:09]
.......................................... (idle for 3h27mn)
ChanServ sets mode: +o Lynnwood [17:36]
............ (idle for 57mn)
gac410It seems we don't "protect" <link ...> or <meta ...> tags, which can cause class names, ids and styles to be rendered as broken wikiword links
So there are various <literal> or <noautolink> tags added here and there to the %ADDTOZONE macros to prevent issues
Seems like the better solution to Item13880 is to add meta and link to the protected tags in Foswiki::Render
[18:33]
FoswikiBothttp://foswiki.org/Tasks/Item13880 [ Item13880: WebCreateNewTopicComponents inserts malformed meta statement ] http://trunk.foswiki.org/System/PerlDoc?module=Foswiki::Render [18:35]
gac410In addition, the current code to remove a tag uses /<tag .*>/i ... case insensitive. On perl 5.8.8, using /<[Tt][Aa][Gg].../ is 28109% percent faster. No that's not a typo
Even on perl 5.23.3 with improved unicode regex performance, character classes are still 7819% percent faster than case insensitive matching.
So Lynnwood ... this is the root cause of the broken WebCreateNewTopicComponents that you reported. UserRegistrationParts has the same issue.
we need to protect meta & link in addition to the head, textarea, script, style and literal tags already protected.
[18:37]
.... (idle for 17mn)
Lynnwoodgac410 that's very interesting...
just getting back from a 4-day trip. Went as chaperone on my 8th-grade son's field trip to Charleston.
big fun
nothing like hanging out with a bunch of emerging-teens to make you fill half way sane
[19:00]
gac410:) [19:02]
.................. (idle for 1h26mn)
rouiljHi folks: I am setting up foswiki using the nat skin as a knowledge base for items located in nagios. So when you look at a service check in nagios, there is a link into foswiki for a specific page name.
That page may or may not exist. Currently when the page doesn't exist, we get the standard 404 page with (equal weight) links for search, index, create, restart options.
I have figured out by changing the 404.nat.html page how to put create at the top of that list and to separate it with some whitespace, but it occurs to me that I really want the 404 page to redirect to a form that provides a structured way to fill in the target page. I already do this using the CommentPlugin for another application where people go to the index page and can create a new page from there.
However in this workflow I want to bypass the 404 page entirely and go to either one of two pages: NagSvcCreate, NagHostCreate based on some url parameters. If the url param "service" is defined go to NagSvcCreate otherwise if the param 'host' is defined and not 'service', go to NagHostCreate page.
Anybody got an idea on how I can skip the 404 page (or immediately redirect to the correct page when I hit the 404 page) when one of the proper url's is accessed in foswiki?
[20:28]
............. (idle for 1h2mn)
Also does anybody have any examples on creating a multi page wizard for creating new topics? So rather then entering 5 items in a single page, you move from page to page entering 1 or 2 items per page possibly with a different workflow based on the results of an earlier page. [21:38]
..... (idle for 23mn)
Lynnwoodrouilj - I have created applications like that. Only, rather than loading different topics, I load different defined sections in the same topic, using an url param.
and if you want to get a bit fancier, you could load those via an ajax call so the actual page doesn't reload.
but i only tend to do that kind of thing when subsequent form element depend on selections in earlier fields.
[22:01]
rouiljLynnwood, yeah I figured I could make them named sections of a single page. Do you have an example somewhere I can see? I wasn't planning on getting into ajax unless i really needed to. While most people will be working from a graphical browser with javascript, there are somepeople who may need to use a text mode browser like elinks or w3m. [22:06]
gac410rouilj: Regarding the 404, you could possibly build a custom WebCreateNewTopicTemplate for the specific web [22:06]
rouiljThis web includes many different topics besides just Nag* topics.
also I really got confused trying to use the AutoTemplatePlugin to set a pattern template for NagSrv*, NagHost* named pages.
[22:07]
Also would just creating a new: WebCreateNewTopicTemplate mean that the user never has to see the 404 page for a specific set of URL's? [22:16]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)