Add param section

See Bugs:Item2400

To create TWiki AJAX applications it is essential to pass a section as url parameter. For instance http://twiki.org/cgi-bin/view/Codev/TWikiAjaxFrameworkShowcaseTools?skin=text;section=weblist should show only the text within the section weblist.

See also: TWikiAjaxFrameworkShowcase

-- Contributors: ArthurClemens - 18 Oct 2006

Discussion

Good idea. I consider this a no-brainer enhancement since it does not impact current spec and use of TWiki.

-- PeterThoeny - 18 Oct 2006

What is a section parameter? Is this documented somewhere?

-- ThomasWeigert - 19 Oct 2006

That would be the new to-be-parameter. I believe sections would be text areas in a topic marked with TWiki.VarSTARTSECTION variables.

-- SteffenPoulsen - 19 Oct 2006

Correct.

-- ArthurClemens - 19 Oct 2006

Why don't we use existing techniques, such as the MultiEditPlugin for this? If the particular syntax of the variable is concerned, that could be adjusted to satisfy the needs of this variable...

-- ThomasWeigert - 19 Oct 2006

Please dicuss the wantedness of sections and overlap in functionality with other plugins in HarmonizeSectionParametersWithExistingPlugins.

Moved much of this discussion to HarmonizeSectionParametersWithExistingPlugins. That discussion should be considered when addressing this topic. -- TW

-- ArthurClemens - 19 Oct 2006

Arthur, perhaps it would be useful if you give an Use Case for this feature. In the border of my concious mind it seems like a sensible enhancement but can't quite put the finger on the "why". As I understand it, is not only about being able to edit just part of the topic, but to be able to "extract" part of the topic using an URL (perhaps for creating Portlets backed by TWiki). Am I right?

-- RafaelAlvarez - 19 Oct 2006

AJAX: the basic idea is to get contents in a container without page refresh. The most simple situation would be to fetch a piece of HTML and put this in the container - no XML needed. This is how AHAH works - no XML to HTML conversion (see MiniAhah for examples).

There are other possibilities of using asynchronous loading of content:

1. Use a complete TWiki page and use skin=text; this would mean specifically preparing topics that should be locked because no other contents like comments or a topic title should be in
2. Use a part of a TWiki page; this is part of the current proposal
3. Do a TWiki search and use the resulting HTML
4. Fetch XML and parse it to HTML
5. Using REST or XmlRpcContribDev

MiniAhah does work with topic sections but uses a trick by passing the section parameter to an INCLUDE. It basically uses a placeholder topic where data can be passed. It is difficult to wrap your head around and it is limited to the number of predefined name sections. See MiniAhah for more.

I think using parts of TWiki pages would be the most simple. Think of fetching user data (pictures!), an attach form in a topic, my (editable) favorite web links, dynamic help on variables and formatting in Edit, etcetera.

-- ArthurClemens - 19 Oct 2006

It seems to me that you are just trying to do what the above discussed plugins are already doing?

-- ThomasWeigert - 19 Oct 2006

It would be helpful if you could provide us with an example how these plugins would accomplish this.

-- ArthurClemens - 19 Oct 2006

I totally fail to see any overlap with the mentioned plugins.

Sven's InlineEditPlugin - which is still waiting for its first release - is not quite the same even if it uses the same kind of technology. It is a complete application that totally changes the way you edit Twiki topics in general. A feature that many of us look forward to having available as I personally think it will work better than Wysiwyg.

Thomas plugins are all about editing individual sections at a time. Also a cool feature. But requires that you submit and refresh the page each time. Again this is an entire complete application that the plugin delivers and is much more than a few lines of code.

What Arthur suggests reusing this existing core functionality and enabling the same feature client side via a simple URL parameter. This means that you can now write some cool javascript that can fetch dynamic data from TWiki without reloading the page all the time. In itself this does not add any feature you can use in topics as such. It is just the same kind of interface via the URL as we know from URLPARAM except here it enables fetching just a small section of a TWiki page.

We have an existing core feature where you can declare multiple sections in a twiki topic and include them from another topic - even with parameters. A very cool and already heavily used feature. It was discussed on Codev. Implemented in Dakar in September 2005. And well described in the release notes and in the documentation. What Arthur proposes is a simple enhancement of an existing feature so it is available also client side. And as far as I can tell it is a simple thing that should require very few code lines in core. So performance should not be affected, it is 100% compatible. And it enables creative Javascript wizards to make some pretty cool TWiki Applications using AJAX.

I agree with Peter's first statement that this is a no-brainer enhancement which in no way is disturbing the development or function of any Plugins etc.

Arthur - you normally do not touch the perl code - so I assume we need a core perl developer to commit to implement this before we can take it to a release meeting for a vote.

-- KennethLavrsen - 19 Oct 2006

Thanks for the clarification, Kenneth. I do sometimes touch Perl but this requires someone with insight in the mechanics.

-- ArthurClemens - 19 Oct 2006

To clarify, the overlap is not with the suggestion that Arthur had, but with the section feature which was introduced with complete disregard for existing plugins and now requires massive change of existing topics. An utter violation of the TWiki mission, I am sorry to add...

-- ThomasWeigert - 20 Oct 2006

It seems to be difficult to keep the two discussions seperate. This topic is about Arthurs proposal and HarmonizeSectionParametersWithExistingPlugins covers the discussion on the INCLUDE feature. I have copied some text from HarmonizeSectionParametersWithExistingPlugins back here. -- KennethLavrsen - 20 Oct 2006

And, I'd like to add that it also overlaps with the ajax functionality in InlineEditPlugin, and in the work we're attempting to do in the TopicObjectModel work. At best, I would suggest that there is zero need to talk of adding this to the core, as there are at least 3 bodies of work in Plugins, and moreso, that the work that both Thomas and I have done, is a superset of the proposal, and our work is a subset of what we are actually trying to achieve.

• What does "zero need to talk" mean? Accept or discard a url parameter? -- ArthurClemens - 19 Oct 2006

-- SvenDowideit - 19 Oct 2006

by zero need to talk of adding this to the core, i'm saying that there is no need, there is ample work showing that it can be done successfully and well in a plugin. especially as the functionality you talk of should be done better using TOM - so I'd consider the work that Thomas and I have done as investigation that leads to the real solution. (Otherwise we have to support a potentially inconvenient code set in the core)

Also, the core principle that is being used on both inline edit and TOM involves no modifications or markers in the topic text. the more non-user info that gets added into topic text, the more difficult everything (user useage, our coding, our docco and maintainence) gets.

-- SvenDowideit - 20 Oct 2006

There is obviously a need to discuss this proposal.

I cannot see what this proposal has to do with InlineEditPlugin or topic object models. This is a simple little enhancement supporting an already existing feature which Arthur can see immediate potential in for TWikiApplications. What is the real reason for being against it? And what exactly is it YOU will do to enable Arthur in doing what he wants to do?

-- KennethLavrsen - 20 Oct 2006

Given the ease of implementation and the clarity of the interface I am really surprised about the sharpness of the discussion. When I read Arthur's initial request and Peter's comment all seemed so clear to me - after all, I knew about the ugly hack I had to use to get MiniAhah working. And as Arthur already pointed out - none of my examples have any overlap with whatever *EditPlugin.

I just checked that SectionalEditPlugin uses sec and not section as URL parameter. So no need to change a plugin to accommodate, and no need to change any topic. I can't see any recent progress with TopicObjectModel, so if there's anything which collides with Arthur's request, then it is about time to reveal it right now.

-- HaraldJoerg - 20 Oct 2006

That is precisely the point. The same tags and the same url parameters should be used so there is leverage.

-- ThomasWeigert - 21 Oct 2006

Accepted at EdinburghReleaseMeeting2006x10x30. HaraldJoerg implements together with ArthurClemens.

It was agreed at the release meeting that this is a view script feature only. Editing of sections we leave to plugins. section URL parameter will have no effect on edit, save etc unless a plugin implements it.

-- KennethLavrsen - 31 Oct 2006

Followup-work is needed, Bugs:Item3170: When referencing a section with the section URL parameter, and the referenced section does not exist, an empty page should be returned. This is to make it consistent with Bugs:Item3158.

-- PeterThoeny - 18 Nov 2006

Agreed, and done!

-- HaraldJoerg - 20 Nov 2006