If you read only one topic about the direct save and no-preview debate, make it this one. If you don't know which one to start with, start here. |
When in edit mode, I'd like to get an additional submit button or another link close to the 'Preview Changes' button to be able to save my modifications without previewing. It would be faster for small modifications that do not require layout visual inspection and would motivate user to fix typos or such minor errors. -- GaelMarziou - 30 Aug 2002
You can acheive this functionality today by running
KoalaSkin. See
SavemultiCgiScript for discussions about moving this functionality into the core.
Merging
KoalaSkin features into TWiki core is in
FeatureUnderConstruction.
A simple work-around is to substitute
preview with
save within the edit-template, like mentioned in
SingleStepSave.
This feature seems to be already implemented in TWiki. We can use the existing save cgi, because it simply works. The only thing missed is an appropriate skin (installed on twiki.org) which makes use of this feature...
The skip preview feature is very much needed. I do not agree that it is a simple matter of changing two lines of code. Reading the preview code, these items need to be addressed and tested before it can go into the core code:
There is a possibility that TWiki forms proably do not work properly. This is because the preview script merges topic data and form data, and the contributed code
[which code, exactly, is being refered to?] calls the save script instead of the preview script, bypassing the form merge.
1. Change form needs to work as expected
Change form works as expected when added as a button.
2. Don't notify switch needs to work as expected
Skin related, add Don't notify switch to edit.
3. Form template setting needs to work as expected
There are reports from many different users on many sites who have been using form templates and SavemultiCgiScript for years. Forms are working as expected (why shouldn't they not?)
4. The "after edit" callback needs to be called also if preview is skipped, that is TWiki::Plugins::afterEditHandler needs to be called
The plugin hook mentioned is only needed by ActionTrackerPlugin & TranslateTagPlugin. This of course should be solved, but it is not relevant for the skin on twiki.org. The author of the action tracker plugin has said that eliminating the afterEditHandler is not a problem for him (see SingleStepSave).
This not releated to TWiki.org, it can easily be solved *by changing some skin elements and we have the long awaited SaveWithoutPreview feature*
5. Edit sends the main topic next and all form fields separately. They need to be merged. Specifically, preview has:
if( $meta->count( "FORM" ) ) {
$formFields = &TWiki::Form::getFieldParams( $meta );
}
This only to render the metadata prettily in the preview and has no effect by saving directly
6.
cmd=repRev
and
cmd=delRev
need to work if preview is skipped, or at least be transparently passed to save
Skin related, this can be added in edit too.
7. Special chars need to be encoded
encode special chars looks unnecessary with this. All it does is encoding of a few chars in the text - however it's not necessary to do in the direct save scenario. (You need it in preview since the text is hidden, and needs to be serialised. You don't need to do this in a no-preview scenario)
I thought this was all resolved on SavemultiCgiScript. What, specifically, isn't?
If
checkpoint (from
KoalaSkin) is the problem, let's get rid of it. Anybody can change
ClassicSkin to get rid of preview (see
SingleStepSave), making save twice as fast and reliable (Sourceforge is acting up again), and lowering server load in half. What we are waiting for?
I think that no preview should be the default, unless their is a problem with the
WikiML entered. For example, I think that writing an
UnresolvedLink should cause the preview to be shown.
MartinCleaver,
PeterThoeny,
ColasNahaboo,
PeterMasiar,
AndreUlrich,
RandyKramer,
ArthurClemens,
MattWilkie,
There are a number of topics whose contents largely overlap this one. Their core ideas are being merged into this one, slowly. With your help it could happen less-slowly. The (known) candidates for merging are: