システム設定とバージョン変更：実行可能なフォームの進化

常に変化する二元論。



プログラムの設定は、コードに定数を設定として持つ最も古いアセンブラープログラムから長い間存在していました。 このようなプログラムの更新は、コードを完全に置き換えることで行われたため、設定システムを変更しても悪影響はありませんでした。 最悪の場合、インターフェイスの使用を再学習する必要がありました。 状況は、データ型とプログラム設定の連続性によって変わり始めました。 かつて、Microsoftはオペレーティングシステムでのプログラムとデータの互換性に大きな注意を払っていました。これが彼らの強みでした。 そして現在、XPモードのサポートは互換性ポリシーの継続です。 Webに関しては、ユーザーは以前のバージョン（Cookie、サードパーティデータベース）から残したデータと設定、およびプログラムのバージョン（サーバーまたはクライアントのスクリプト）が変更される状況にしばしば遭遇します。 プログラムとデータのバージョンの互換性の問題があり、互換性をサポートするためにいくつかのポリシーを開発する必要があります。 新しいバージョンはブラウザとの互換性のために機能しない可能性があり（バグまたは不完全なサポートのため）、バージョンの変更により番号が変わる可能性があるという事実にもかかわらず、バグを修正するための前のバージョンへのロールバックに設定の損失や歪みが伴うことはありません。



設定とその組織だけでなく、バ​​ージョンの変更と設定の継続性の問題にもアプローチが必要です。 Web上のプログラムは小さなステップで進化し、バージョンの変更は頻繁に発生します。 設定を操作する同じアプローチは、Webに接続されていないがバージョンが頻繁に変更される他のプログラムにも適用されます。 同様の考慮事項は、設定を保存するための形式だけでなく、プログラム内のすべてのデータの形式に起因する可能性があります。



この記事で導き出された主な論文：

*）設定-同様の動作をするプログラムおよびクライアントWebアプリケーションのオブジェクト。

*）デフォルト設定-メーカーの設定に関する推奨事項のみ。

*）プログラムのバージョンを変更する際の設定の変更は、製造元の推奨事項の変更です。 バージョンの変更は、設定を変更するためだけに存在する場合があります。

*）ユーザー設定-ユーザーの推奨事項。

*）エクスポート/インポート設定-ユーザー間の交換、推奨事項の保存、コンピューター間の転送。

（さらに-バージョンの変更について。）

*）メーカーによる設定のセマンティクスの変更（バージョンを変更する場合）-アップグレード中にロジック違反を引き起こすエラー-ダウングレード。

*）「戻る」ボタンをオンにして2つの設定状態を保存する場合、インターフェイスを複雑にすることなく多くの機能を使用できます。バージョンを変更するときに新しい設定を試し、古い設定にロールバックし、サードパーティの推奨事項を試し、保存します。

*）シンプルさを維持するために、より複雑な操作システムは望ましくありません。 すべての高度なアクションのエクスポートとインポートがあります。

*）メーカーの設定に戻ります-別の機能（「リセット」）;

*）メーカーの推奨事項はプログラムに「組み込まれている」ため、別の場所を占めることはなく、それらのいくつか（設定プロファイル）が存在する場合があります。他の推奨事項を保存するための「保存」ボタンがあります。



設定と推奨事項の問題の深さと一般性を確認したので、サポートしようとする一連の要件について概説します。 バージョンを変更するときに十分に機能し、開発できる、かなりシンプルで汎用的な設定システムが必要です。 結果は、指定された要件の範囲をサポートする実用的なアルゴリズムです。 アルゴリズムを構築した後、* .user.jsの設定サブシステムの実装と* .jsの別の手順を示します。 後で開発して自分の間違いを修正するよりも、自分とユーザーの設定を操作するためのルールをすぐに記述し、それを残さない方がよいという理由で作成されました。

要件のサークル：プログラムのバージョンごとに設定がどの程度互換性があるか

バージョンを変更すると、プログラム、設定、ロジック、セマンティクス（意味のある設定）など、すべてが変更されます。 バージョンの変更は、ロジックの開発の別の測定値であり、ダウングレードが発生した場合やプログラムの別のバージョンに設定が転送された場合に、新しいバージョンから古いバージョンからのデータの到着、それらからの設定、場合によってはその逆を考慮します。 バージョンを変更する状況をモデル化して、どのルールに従う必要があるか、どのような自由を残すことができるかを理解し始めます。 または、他の流行の言葉で、「設定」 デザインパターンを作成します。



互換性の問題に関して、各開発者は、 クライアントのポケットをよりうまくねじるために 、AdobeがPhotoshopバージョンのプログラムを配置した古典的な悪夢を鮮明に思い出します 。 ここでは、おそらく物語が他の高価なプログラムで繰り返されるため、彼女は意図的に行動しました。 主要な業界プログラムで1〜2年働いた-次の分割払いを支払う。 小さなプログラムとサービスではこの方法を使用できませんが、逆に、ブラウザの新しいバージョンがリリースされるたびに、ほとんどの場合無料でバージョンを変更する必要があります。 互換性設定をサポートするには、明確で相互に快適なバージョン変更が必要です。 （また、1対1-データ形式とそのセマンティクスですが、設定のみを検証します 。）この場合、異なるユーザーは以前のバージョンから大幅にアップグレードでき、ほとんどのユーザーは設定で作業する必要がありません。一般的には自動ですが、たとえば、システムにウィンドウのロケーションパラメータを保存します。



バージョンを保存および切り替えるシステムは、これらの事実を考慮に入れて、以下を提供します。

1）プログラムの現在のバージョンの設定の保存と復元。

2）プログラムを更新するとき-古いバージョンに戻る場合（少なくとも1ステップ前）に古い設定を忘れないでください。

3）arbitrarily意的に新しいバージョンの環境における古い設定の意味の不変性（意味論は変更すべきではない;理由-分析が低い）;

4）バージョン管理でユーザーを煩わせず、ユーザーに何らかのアクションを強制しません（最善は善の敵です。気を散らす必要はありません）。

5）巨人主義のために努力せず、設定に差異（差分）を保存する-最適化ステップ。



クライアント上の本格的なプログラムであることが判明したJSスクリプトのバージョンを使用する場合、バージョンを変更するときにユーザー設定を保存する問題が発見されました。 Photoshopバージョンと他のモンスターの互換性の問題をすぐに思い出しました。 そして、スクリプトが大衆になり、メモリからプログラムの新しいバージョンを手動で構成しなければならない不満を抱くユーザーが多数登場するか、さらに悪いことに古い設定が入るまで、初期状態のユーザー設定で正しく動作する問題を解決する方が良いと思いました新しいバージョンと矛盾すると、テストされていないバグが存在します。 ユーザーに「すべてをリセットし、新しい方法でインストールする」ことを提供することは、もちろん、洗練されたユーザーが遭遇した問題を解決するための有名でandい方法です。 （実際、トラブルよりも利益がある場合、Photoshopのメーカーで何ができるでしょうか？）バージョンを変更する際に、構成の競合を解決するための技術をプロジェクトにすぐに入れる方が良いです。 そのため、バージョンと設定を操作するためのルールが作成され、プログラムデザイナーが従うことができました。



次の記事の2番目の部分-JSでのテストページの実装-アプローチの操作性をテストできる既製のスクリプト。 スクリプトでは、ユーザー設定は任意のマルチレベル構造であるため、さまざまなプロジェクトに移植することができ、そこでは正しいバージョン変更の必要性も考慮されました。 または、最初と2番目の部分を使用して、別の言語でロジックを記述します。 努力が無駄になることはなく、次の内容の美しいタブレットの準備でデザイナーの作業を節約できます。

インストールする前に、以前のバージョンの設定を削除することをお勧めします...

新しいバージョンに切り替えるときにプログラム設定を保存するポリシーについて。

既に述べたように、プログラムのバージョンを変更することは、プログラムの1枚のコードのバグの問題を解決することから、開発の問題を解決することまで、新しい次元への道です。 開発者は、自分のプログラムの他の非常に重要な機能に長時間取り組んでいて、バージョンの変更の問題がフォアグラウンドにない場合、この分野の詳細をすぐに理解できないかもしれません。 しかし、彼が立ち上がると、進化が始まります。



恐竜の時代に何が起こったのか：新しいバージョンをインストールすると、プログラムの動作が不十分になるか、まったく動作しなくなります。 推奨事項：新しいプログラムをインストールする前に、以前のバージョンを削除します（そして、プログラムの古いバージョンのデータからレジストリとフォルダーファイルを消去します）。 特に深刻な場合-新しいバージョンのプログラムによって古いバージョンで作成されたデータを開かないでください。



もう1つの古いオプション：新しいバージョンに切り替えるときに、プログラムは設定が何であるかを尋ねません。デフォルトを設定し、ユーザーが手動で設定します。 プログラムの問題を回避する方法：それらは、iniファイル、レジストリ（winが検出された）、構成ファイルのデータを代用する場合があり、これにより構成作業の一部が省かれます。 別の解決策は、インストールされている仮想OSのイメージとともにプログラムを保存することです。 プログラムの動作中のカスタマイズされたイメージが作成され、再インストール用にパッケージ化された再配布可能パッケージをインストールします。 いくつかの深刻なプログラムで提供される設定で、静かなインストールを使用してください。



より適応した生命体の場合：プログラムは、以前のバージョンから残った古い設定を理解し始めます。 プログラムを作成するときに何をする必要がありますか？



プログラムについて、またはWebとサイトについて説明します。これは、議論の対象が1つしかないためです-ユーザーインターフェイス、製品のバージョンです。 入力ストリームのみが異なります。 プログラムの場合、これらは異なるバージョンによる設定とその継承であり、ウェブの場合、これらは異なるブラウザによるデータページとその表示です。 時々、このデータは設定に非常に似ているため、呼び出しを開始し、それらのWebページまたはウィジェットはアプリケーションと呼ばれ始めます。

新しい設定

プログラムの新しいバージョンが完全に新しい設定になったときがありました。 それから、相続の問題は単に立たなかった。 恐竜の時代のように、新しいバージョンではすべてを再インストールするか、デフォルト設定を使用するように求められます。 しかし、システム開発の基本的な特性としての遺伝は、この欠点をすぐに克服しました。 プログラムは、データの互換性だけでなく、設定による互換性も必要とするようになりました。 まず、恐竜、次に鶏が卵を要求し始め、以前に現れたものの問題の基礎を築きました。 新しいバージョンをインストールしました-以前に設定した設定（ウィンドウサイズやフォントなど）を失いませんでした。 しかし、バージョンごとの設定システムには開発する特性があるため、プログラムの開発、生命体の進化を考慮する必要があります。 さらに、プログラムは任意のバージョンに更新することができ、古いバージョンでも更新できます。つまり、以前の設定だけでなく、将来の形式の設定も正しく使用する必要があります。



たとえば、HTMLおよびXMLのタグと属性のシステムには、ルールがあります。新しい属性またはタグが見つかった場合、それは無視されます（その意味は不明です）。 明らかに、設定システムでは、新しいものがそれらを無視することは論理的です 。 そのため、HTMLページでは、以前のバージョンでも、同じプログラムの異なるバージョンのプログラム設定で、最初の単純な互換性ルールが導入されました。

既存の設定の解釈

ただし、設定が変更されていなくても、プログラムは（誤って）一部の設定を異なる解釈を開始する場合があります。 プログラムがユーザーから同じデータを受け取る異なるメーカーのものである場合、わずかに異なる意味でデータを解釈できます。 たとえば、画面サイズは最初のモニターで考慮されるものもあれば、接続されているすべてのモニターのグループからの最大測定値であるものもあります。 再びHTMLとの類似性に目を向けると、これはHTMLでブラウザーのデータ表現の互換性の問題として知られています。 同じデータ（テーブル、入力フィールド）でも、結果の表示がわずかに異なります。



問題があります-彼らはその解決策を取りました。 現在、「互換性のある」ビューがありますが、厳密なビューがあります。 ブラウザのバージョンが多いと、厳密な表現の数が増え、互換性のある表現ではさらに高速になります（2乗）。 各ブラウザとバージョンには、互換性に関する独自の考えがあります。



プログラムの設定の互換性についてこのようなアプローチを採用した場合、バージョン間で設定を転送するためのルールを作成する必要があります。 バージョンのインストールは常に連続して行われるとは限らないためです。 バージョンがジャンプし、古いバージョンに戻ります（たとえば、新しいバージョンのバグが原因です）。 このプロセスは、プログラムの2〜3バージョンのレベルで開始しても、開発者にすぐに飽きてしまい、最も関連性の高い互換性（古いバージョンから新しいバージョンへの移行）のみをサポートし始めることは明らかです。



行動の単一行を維持することは、バベルの塔を構築する最良の方法です。

古い設定またはそれらの値の一部が消える

設定で設定された値がプログラムの新しいバージョンでサポートされなくなった場合（または新しいスタートでも）、プログラムはこれに適切に応答する必要があります。



たとえば、同じ時代の恐竜では、すべての（または多くの）プログラムが画面の中央に表示され、画面の幅の約50％を占めると考えられていました。 ユーザーがウィンドウの位置とサイズを変更することにした場合、次回プログラムが新しい場所でウィンドウを開く必要はありませんでした。 なぜそう



プログラムがウィンドウの位置とサイズを記憶している場合は、モニターを変更すると、簡単に画面から外れてしまう可能性があります。 プログラムのサポートはより複雑になり、進化は常に複雑な生命体をサポートするとは限りません。 モニターと環境を見るには、開発されていないAPIで開発者に地獄を作った長い手順であり、それら（またはそれらからのこれらのアイデア）は、子孫さえ与えずに消滅しました-この静脈で動作するプログラム。 プログラムは非常に複雑な場合がありますが、実行中のプログラムでアクションを追加するたびに一連のバグが発生し、新しいテストサイクルが必要になる可能性があるため、プリミティブインターフェイスがあります。



しかし、数年が経過し、より高度なAPIと開発環境の出現により、開発者は将来の力と自信を得ました。 恐竜は羽が生い茂り、飛び始めました。 プログラムが設定から許容できない値を取得した場合、プログラムが苦痛を感じたり、ユーザーの性質の容赦ない手に流されたりすることはなく、合理的に機能することを確認するのは非常に現実的です。



合理的な代替案：

1）最も近い類似値を選択します。

2）デフォルト値を選択します。

3）パラメーターの変更には他の値の変更が必要になる場合があるため、関連する複雑な値の選択を提案する。



妥当なプログラムは、このバージョンの無効な値に応答します 。

セマンティクスの設定を変更する

これは、プログラムが以前の設定に絡まる最も難しいケースです。 設定の制御が各設定の名前+値の転送に基づいている場合、値の意味（つまり、プログラムの動作）のゆがみは、ユーザーによって制御されないプログラムの動作の変化につながります。



たとえば、以前の1つは全画面で開き、現在は大きなウィンドウで開くことです。

デフォルト設定の理解が変更され、デフォルト値は設定ファイルに保存されません。 明らかに、このような意味の変化が存在するとエラーが発生し、修正が必要になります。



したがって、ブラウザが白と白を呼び出す傾向があるように（たとえば、常にではありませんが、たとえば、ページの背景がカスタマイズされているため）、プログラムは、設定に含まれているものを設定で確認しようとします。 （windowWidth変数がウィンドウの幅を示している場合、新しいバージョンでは企業の従業員数を示すことは意味がありません。）



誰もがそれほど率直に言っているわけではありません。 ここに、意味の非常に秘密の変化の（仮説的な）例があります。 バージョンNより前は、OSのウィンドウの幅はウィンドウの内側の境界で開発者によって計算され、N番目で境界とともにカウントする方が正しいと判断しました。 そして、以前のバージョンでユーザーが以前に幅を100に設定した場合、N番目のバージョンでは、OS設定に応じて、98、96、または別の内部幅（以前と同様）が得られます。 開発者の代わりに、異なる幅を入力する必要がある場合は、別の名前（名前、設定のキー）を選択する必要があります。 また、前者は不要なため、完全に削除できます（またはバージョンの互換性のために変換手順を終了します）。



設定値のセマンティクスを変更することは、開発者エラーと見なす必要があります。

デフォルト値の変更

作業の中断につながる最も無害なケース。



たとえば、2つのチェックボックスがあり、両方が選択されています。 ユーザーは最初のチェックボックスをゼロに設定し、2番目にチェックボックスを配置しました（選択されていなかった場合、ユーザーは値0、1が必要なため選択していました）。 次のバージョンでは、製造業者は両方のチェックボックスを削除しました。 保存された設定のユーザーは、最初の選択肢0、Xのみを持ちます。Xはメーカーに選択肢を与えることを意味します。 また、インターフェースには2番目のチェックボックスのデフォルト値を修正する方法がなく、修正する方法がないため、問題があります。



その結果、ユーザーごとの設定システムの操作が不均一になります。 デフォルト設定の選択を修正できないアクティブなものにとっては、すべてがパッシブなものと問題の順です。 （これに続いて、関連する分野の専門家の推奨事項（CSSなど）がデフォルトで属性のアクションを考慮に入れて明示的に記述します（CSSリセット）。これにより、将来デフォルトポリシーを変更する場合、属性のその他の理解ができなくなります）



解決策は、デフォルト値であっても、設定を修正できるようにすることです。 言い換えると、ユーザーは、メーカーの設定（推奨）に対する受動的な同意ではなく、この値を設定するという明確な願望を表明します。 したがって、通常行われているように、ユーザーが現在と同じ値でユーザー設定を修正することを防ぐことはできません。 （これは非常に微妙な点でした。デフォルト設定を修正せずにシステムがクラッシュし、問題が解決されました。）



投票システムでは、誰かがすでにユーザーと同じ方法で投票している場合、ユーザーが同じ方法で投票できないことを意味しません。 同様に、設定で。 確認の可能性なしにデフォルト設定の選択を「容易にする」ことは、インターフェースでそれを修正することは「ベアサービス」であり、問​​題の原因です。 固定-メーカーの推奨事項とユーザーの選択が遵守されます。



チェックボックスを使用する場合、設定を変更できるだけでなく、それぞれの固定を示す必要があります。 プロセスを最適化するために、ユーザーが何かを変更した場合、これはすでにコミットを意味します。 しかし、今、あなたはそれを削除することができる必要があります-各設定について、再びデフォルト値に戻ります。 同様に、システムが設定の1つのプロファイルではなく、他の著作権設定のインポートもサポートする場合、別の権限のあるユーザーの選択に戻ります。



さらに、製造元は理由を変えて設定を変更するため、控えめなモードで設定を知ることは有用です。 ユーザーが設定に興味がある場合は、設定に最後にアクセスしてからユーザーに発生した新しい何かが表示されます。 彼が初めて来た場合、何も目立たず、すべてが新しい。 以前に何かを変更または修正し、製造元が推奨事項を変更した場合、ユーザーには変更が表示されます。 開発者は、デフォルト設定の変更の指示を提供します 。



質問は、ヘルプシステム、ヒント、情報、推奨事項の選択にスムーズに近づきます。 設定の変更に関する通知の場所は、一般的な設定またはそれらのプロンプトを説明する最適な場所でもあります。



そのため、設定選択インターフェイスは2つの要素に囲まれています。固定/固定の解除と、変更の履歴と一般的な設定の説明に関するヒントです。



このようなもの（リストされたコントロールのみ）：

[0] - _1 (?) _fix_ [1] - _2 (?) _unfix_ [__] - _3 (?) _fix_
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

角括弧内-チェックボックスの値。 疑問符-ヒント; 質問の色は、システムが変更について何か言いたいことがあることを示している場合があります。 アイコンの修正/修正解除-デフォルトの修正またはそれらに戻るためのリンク。 推奨者が複数いる場合、固定アイコンは複雑です。 設定には、この設定を選択したユーザーの表示（ステータスの数と数）、および開発者の設定の値を含めることができます。 このアプローチでは、設定はソーシャルネットワークの評価に似始めます。 おそらく、これはソフトウェアを共有するためのオプションの1つです。



固定メカニズムがない場合、インターフェイスとロジックに問題があります。 ただし、OSのチェックボックスインターフェイスでは、0、1、デフォルトの3つの状態を列挙することでこの問題を解決しました。 HTMLでは、無効にし、JSを使用してループすることで解決することもできます。 次に、少なくともチェックボックスとラジオボタンの場合、fix / unfix要素は必要ありません。

新しいバージョンが機能しなかった場合はどうなりますか？

この場合、明らかに、最新バージョンへのロールバックが必要です。 ただし、一部のデータは（通常はサブジェクトエリアから）新しいままである可​​能性があり、プログラム設定は古い設定から取得する必要がありますが、一部の新しい設定も有用であり、古い安定バージョンまたは新しい安定バージョンの推奨として保存される場合があります。



... 2度目の「推奨」という言葉が登場しました。 これは設定では珍しいことです。 開発者の推奨事項として「デフォルト値」があり、デフォルト値にリセットされる場合がありますが、推奨事項はありません。 設定のインポートがありますが、すべての設定は新しい値を取得し、変更前と比較することしかできません。 推奨事項は、設定またはそれらのグループを変更して、すぐに結果を確認して比較する機会です。



推奨と比較のアイデアは非常に強力です。 （したがって、偶然にも、進化は恐竜の時代にも機能しました。）多くの店舗サイトは、比較のためにできるだけ便利に製品を提示しようとしています。 これは、何らかの設定を行うための推奨事項と同じ推奨事項です。 したがって、プログラムでチューニングの推奨事項の結果を表示できた場合、同じツールでさらに多くの予期せぬ有用性を実現できる可能性が広がります。



ロールバックバージョンに戻りましょう。 完全にロールバックするには、プログラムは古い設定を無条件に忘れてはなりません。 彼女がプログラムのバージョンを変更する最後のステップを覚えていればより良い。 ユーザーが以前のバージョンのすべての機能を試す時間がない場合は、以前の手順を覚えておいてください。 その後、彼は最新の正しく動作するバージョンを識別する機会を得ます。 明らかに、これは開発とテストに役立ちます。 恐竜の時代には、これは起こっていません...

合理的なインターフェースの制限

確かに、一度に複数のセットで動作するように設定選択インターフェイスを複雑にしたくありません。 これはプロのテスターや他の開発者には適していますが、一括管理要素を作成するタスクがあります。そのため、できるだけシンプルで柔軟な方が良いでしょう。 通常、 柔軟性はエクスポートとインポートの設定によって実現されます 。 これにより、プログラムの外部の別の場所にいるユーザーは、バージョンのカタログ化と保存のためのシステムを実装できますが、これもまた困難です。 すべての強力なエクスポートシステムに加えて、可能な限りエクスポートに頼る必要のない単純なサブシステムがあると便利です。



設定のリストを 1つではなく、たとえば現在のバージョンと以前のバージョンに関連する1つまたは2つを保存してみましょう。 または、現在のバージョンと実験的なバージョン。 次に、設定を混乱させずに名前を入力して「マネージャー」を作成しないために、コントロールインターフェースに設定を切り替えるために必要なボタンは1つだけです（電卓のように「M」ボタン（メモリ））。 それだけではありません-エクスポートサービスがあります。 インターフェイスのこの基本的な簡素化により、実用的なモデルを構築でき、「M」ボタンのように直感的なままになります。



このようなアイデアの出発点は、新しいバージョンの確認や古いバージョンへのロールバックなど、ほとんどのアクションでは、3つ以上の設定リストを使用した操作は必要ないということです。 設定の1つの「セット」を保存して、誰かの推奨事項を確認することもできます。 次に、技術的な実装について説明します。



設定の保存-再起動に関係なく、ブラウザ内で使用するlocalStorageに保存することを意味します。 保存されたセットに加えて、保存されたセットに影響を与えることなく、一時的に他の設定をテストできます。 保存するには、「保存」ボタンを押すか、プログラムの新しいバージョンをダウンロードします。 新しい設定（デフォルト）または使用（ロールバック中に指定）を使用せずにロールバックできます。 任意の異なるバージョンに移動します-同じ2つを選択します。 バージョン番号が新しいキットの設定バージョンよりも大きい場合、新しい設定が選択されます。 2つのセットが同じ場合でも、2つのセットがあると見なされます。 それらは差分として保存されるため、差分が小さいほど、使用されるスペースが少なくなります。 現在の設定は、メーカーの推奨事項とユーザーの選択との差として保存されます。 違いは、ユーザーが選択した場合の設定の表示として（デフォルトと一致する場合でも）、それ以外の場合の表示の失敗として理解されます。



ブラウザには、ページの読み込みの開始時に設定を読み取り、それを定数と見なすことが最も簡単であるという別の技術的なポイントがあります。 設定を変更するプロセスには再起動が必要なため、一部のテストでは設定セットを保存する必要があります。ユーザーの設定を記憶するには、2セットを保存し、同じ「戻る」ボタンを使用して復元する必要があります。



2つの設定リストで何ができますか？ 完全なリストを収集します。

1. プログラムの新しいバージョンに移動し、そこから新しい設定をロードします。 古いものはロールバック用に残り、新しいものは引き続き機能します。

2.ロールバックが実行される場合、ユーザーが設定を変更した場合、 新しい設定のデータは 2番目のセットに保存されます。 同じバージョンまたは新しいバージョンに切り替えると、累積時間が使用されます。

3. 別の推奨事項を保存 （インポート-保存）すると、ロールバック用のデータが消去されるため、ブラウザーの再起動後に別の推奨事項の設定を確認できます。

4. 他の設定のテスト （設定-テスト-保存）。ブラウザーの再起動後およびページのリロード後も継続できます。



保存せずに設定をテストすることを妨げるものは何もありませんが、ページがリロードされるまでの時間制限によって制限されます。 このようにして、最も単純で最も迅速な設定をテストできます。 ほとんどの設定は、ページの読み込みの開始時にプログラムで値を設定するため、localStorageに保存しないとテストできません。 2セットの設定を保存するメカニズムにより、このような制限なしでテストが可能になり、スクリプトの機能に優れた追加が作成されます。

データ量とその制限になぜそれほど注意を払うのですか？

なぜなら、一方では、設定の単純さと明快さに対する欲求があるからです。 エンティティが少ないほど良い。 最も簡単なことは、「鉱山」という1つの設定セットを持つことです。 操作を最小限に抑えるために、「その他」の設定と唯一の「戻る」スイッチボタンを入力します。 混乱することは困難ですが、機能が追加されます。 問題には別の側面があります。



データベース内のサーバーに設定を転送することは難しいように思えますが、それらを操作することは困難です。バージョンごとに保存し、履歴を修正しますか？ ここで、タスクの他のいくつかのエンティティにアクセスします。 最初のものは、サーバーでの許可に関係なく設定を保存することになっています。 承認なしまたは別のタスク-承認も想定されていないクライアントのユーザー設定として。 ステートメントの2番目の本質は、エクスポート用の設定をテキスト形式で保存するには、最もコンパクトな形式の保存が必要になるため、最短で手動で編集した行が必要であることです。 したがって、2つのセットがあり、設定の違いのみが保存されるため、データが少なくなります。

設定スイッチインターフェイス

このセクションには、別の記事と別のブログが必要です。 以前に行ったことは「プログラムのアーキテクチャ」と呼ばれますが、そのようなブログはなく、「アーキテクチャ」というタグのみがあります。 説明を完了するために、結果を簡単に言葉で説明せずに説明し、詳細を別の記事に掲載します。 インターフェースのテキスト記述でいつものように、それは判明しました-それは退屈で読みにくく、同様に従事して結果を比較したい人だけを対象としています。



最初は、特別なアクションがなければ、ユーザーは、設定の変更を開始するまで、インターフェイスの追加要素を受け取りません。 デフォルトでは空の行をエクスポートすることはメーカーの設定と一致するため、[エクスポート]ボタンさえありません（またはアクティブ化されていません）。



ボタン（または入力フィールド）“ Import ”があります。これを使用して、JSON文字列または類似のものを入力フィールドからロードして、設定を変更します。 すぐに、これらの設定が設定インターフェイスに反映され、レコメンダーの名前、設定バージョン+設定されたプログラムのバージョンが表示されます。 任意のバージョンの設定をプログラムの別のバージョン（古いものまたは新しいもの）にロードすることは珍しいことではありません。 プログラムの現在のバージョンで見つかったキーを持つものは動作します。 呼び出しボタン「 テスト 」と「 キャンセル 」が表示されます。 2番目は設定のビューを復元し、何も行いません。1番目は読み込まれたインポートバージョンを現在のバージョンとして保存し、現在のバージョンを予約として保存し、他のバックアップバージョンがあればそれを消去します（シングルレベルスタック）。



保存されたバックアップバージョンの存在は、設定パネルに表示されます。 したがって、「テスト」をクリックするとすぐに、「 戻る 」ボタンが置き換えられ、保存されたバージョンのユーザーに関する情報が表示されます（ユーザー設定がない場合は存在しない場合がありますが、「テスト」モードは有効のままです）。 「受信」設定ブロックへの絶え間なくぶら下がっているリンクがページインターフェイスに表示されます（受信メールのリマインダーとして）



[戻る]をクリックすると、プログラムの設定（通常はページの再読み込み後に有効になります）、および設定パネル-テストの設定と[テスト]-[キャンセル]ボタン-前の操作ステップに戻ります。



localStorageの分析によって記録された新しいバージョンのスクリプト （プログラム）がロードされると、設定が一度変更された場合と同じように設定の状態に作用します。 古い設定のコピーが作成され、「テスト」と同様に、「 新しいバージョン 」通知が表示されます。 これを行わないと、プログラムの動作を変更するとユーザーが困惑します。 ここでは、このボタンを全員に表示するか、関心のある人にのみ表示するかという疑問が生じます。 ほとんどの場合、2番目ですが、誰にとっても-通知機能は設定パネルに隠れています。



バージョンの変更が繰り返し発生する場合、実際には何も変更されず、スクリプトの新しいバージョン（および新しい設定）の値のみが変更されます。 ユーザーが新しいバージョンの設定を変更した場合、表示される2つの設定グループ（新しいバージョンと古いバージョン）をクリックすると、「 保存 」ボタンが表示されます 。 「戻る」はバージョンのローテーションを引き起こします。「戻る」という単語は「テスト」の場合のように「新しい設定を適用する」に変わり、新しい設定に戻ります。 古いプログラムに戻るには、表示される「 ロールバック 」ボタンをクリックする必要があります。これは、古い設定を最後に編集したときに番号が記憶されているバージョンで発生します。 （このメカニズムには、リリースされたバージョンへのアクセスが必要です。）他のバージョンに切り替えるには、数字のドロップダウンリスト。



ユーザーが2つのセットが保存されたときに設定のセットを再度変更したが、プログラムの3番目のバージョンがある場合、スタックに新しい保存はなく、現在のグループのみが変更されます（[保存]をクリックした後）。



[設定の確認]ボタン-記憶状態の保存を拒否するには-ロールバック、新しいバージョンのまま（「新しいバージョン」アイコンが削除されます）。 状態が1の場合、ボタンは「設定の消去」または「 リセット 」と呼ばれ、メモリは設定から​​消去され、デフォルト設定が使用されます。 「リセット」は、誤って押すことから保護されています。



プリセットの数が2に制限されているため、テストアクションを実行するとロールバック設定が消去され、テストの終了時にそれらが復元されません。 それらを失わないようにするには、ユーザー設定があるときにアクティブになるエクスポートボタンを使用します。



ボタンと通知機能のリストとそれらのグループ化を再度リストします。

*インポート、エクスポート-文字列として入力設定を抽出するため。

*テスト、キャンセル-設定を適用し、設定のインポートの表示をキャンセルします。

*「テスト」-設定がテストモードであることを示す通知。

* Return-設定を復元し、テストを終了します。

*「新しいバージョン」-（設定パネルで）新しいバージョンのダウンロードについて通知する通知者。

*ロールバック-前のバージョンにロールバックするための「戻る」の類似物。

*コンボまたはバージョンのリスト-ロールバックされるバージョン。

*保存、キャンセル-ユーザーからの設定変更の確認。 「テスト」に似ていますが、通知はありません。

*設定を確認（「戻る」の代わりに）またはリセット-保存された設定を削除し、現在の（またはデフォルト）を適用し、通知「新しいバージョン」を削除します。

*新規適用-ロールバック後-設定の新しいバージョンに戻ります。



次のシリーズでは、これらすべてをライブで見ようとしますが、スクリプトではまだ機能しない可能性が高く、インターフェイスペインティングで記​​事を書く必要はありません。プログラミングはレイアウトなしで行われます。 次に、説明されたメカニズムを備えた公開スクリプトをデモとして待ちます。

まとめ

バージョンを変更するときにプログラムの開発を考慮に入れずに技術的な欠陥のない設定を操作するためのインターフェイスが取得されました。 「推奨」の概念が導入されており、いくつかの推奨事項と、あらゆる方向のプログラムバージョンと互換性のある設定形式で作業することが可能です。新しいバージョン（アップグレード用）と古いバージョン（ロールバック用）の両方で機能します。