Topic on Extension talk:NamespaceHTML/Flow

Hi

As per my earlier comment I've been testing this extension as tag function. Example of the test:

{{#tag:html| <form action="mailto:{{{email}}}" enctype="text/plain" method="post"> <p>Name: <input name="Name" type="text" id="Name" size="40"></p> <p>E-mail address: <input name="E-mail" type="text" id="E-mail" size="40"></p> <p>{{{Name}}}:</p> <p><textarea name="Comment" cols="55" rows="5" id="Comment"></textarea></p> <p><input type="submit" name="Submit" value="Submit"></p> </form>}}

So far using it as a tag functions seems to work just fine, which makes it possible to use MW variables inside the html tags. After I run a lot more tests I'll add a note on the front on doing it.

Having a secondary issue that I can't seem to get the extension to function in more then one namespace. Any thoughts on that? All the best

Good to hear that you're having success with it. What code are you using in LocalSettings?

Tried several settings in LocalSettings, but no matter what I tried I couldn't get more then one Namsspace to work.

On a different note, anyway to re-code the extension so it could work when something is tranincluded from one namespace to another, but without allowing the use of raw html in the Namespace it's tranincluded into? (except, of course, for the html transincluded) Ideally this would make it possible to restrict editing to the Template Namespace, with raw html enabled, but allow end users access to wiki variables inside that html.

I just tested it in two namespaces successfully. Your LocalSettings.php should look something like this (after extension inclusion):

$wgRawHtmlNamespaces = array( NS_MAIN, NS_PROJECT );

Transclusion is something I've been wondering about. Right now you cannot transclude from a raw-enabled namespace to a "normal" namespace. I was worried about the security implications, but I don't think that it's the right decision. Any code in a raw-enabled namespace is already presumably secure, so what's the harm in including it somewhere else?

I don't understand your particular use-case. But if transclusion was enabled would it help you?

Yes it would be great if transinclusion was possible. The user case is like I was describing in the first thread. Using the tag function wiki variables can be used with html, which opens up the possibility of templates where the user could set the variable, but not be able to add raw html themselves. In my case I operate a wiki that has the yellow pages data of the United States and by allowing the end users to set the variables I could add html to let them embed their Instragram, Pinterest, etc., per listing. Additionally I could pre-design forms in html, like a Contact page, Employment Application, etc., where the person editing the page could actually change the questions (have the questions set as wiki variable) and then present to the end reading user a form to fill out (kinda of like a form designing system seen on sites like Wufoo).

So, not to get long winded, transinclusion would be awesome, great and most, most helpful.

I'll try the settings you suggested and see if it solves the problem of only operating in One Naemspace. I thought I did have my code the way you show, but maybe I make a small syntax error. All the best and thanks again for the work.

Version 0.2 is now available and supports transclusion.

Tested version 2 and it's great. Thanks.

Additionally I've got the wiki variables working inside a template with the html. I can add some examples on the front page if you desire, or as sub-pages underneath the main extension page. All the best.

I think it just needs a line or two. I'll add it one of these days. Thanks.

Whatever you think is best. But I thnk I should mention a possibility that maybe you haven't considered, which is: that since the tag function can be used to mix html & mediawiki variables it's then possible for this extension to take over, or be used as an alternative to the Widgets, and the Widgetframework extensions. As a test I quickly templated out the code for youtube setting the id as a mediawiki variable -- it worked great. Anyways, I think, that your extension would allow for much faster creation of all sorts of "widgets" then the two I mentioned. A whole library of "widgets" etc., could be listed on subpages to the extension's parent page.

Anyways just a thought. All the best to you & thanks for creating this great extension.

I have thought of it. But I don't see why this extension is any faster or better than Widgets. And I still worry that maybe there's some way to inject nasty code into a template using this extension. (I haven't been able to in my tests, which is why I enabled passing parameters.) Widgets has tools for escaping user input.

Just a thought. The only reason, I think, it would be faster and easier to use then Widgets is it would allow users to just grab the embed code from most sites and by a minor modification allow a wikitext variable. No screwing around with smarty templates, etc., -- just the embed code from whatever site and a minor change to setting mediawiki variable. Of course with greater freedom there is a greater chance for security issues to arise. But it still seems it would encourage more "widget" creation -- my bet is that the library of possible widgets with this extension would exceed the Widget website within a month.

Anyways that's my half cent opinion. Once again all the best to you. Thanks