uAutoPagerize ver 0.1.7の仕様変更について その2

Grieverさんからのコメントにお答えします。

私の使いたい XPath と多野さん(?)が作り上げてきた XPath が大きく違い編集しづらいこと、pageElement の取得・継ぎ足し時に JavaScript でチェックと補正を掛けたいのが大きな理由です。


動作サイトについては死ぬほどテストしたので減ってはいないと思います。

uAutoPagerize ver 0.1.7の仕様変更について - 1300

コメントありがとうございます。もちろんGrieverさんが優秀な技術者なのは認めますが、JavaScript自体が使えるとしても誤動作に気を使いながら400や649を無効にしてこれまでと同様の動作サイト数を維持するのは難しいはずです。すごい気迫ですね。

これまでと何がどう違うのかを確認したいのですが、日頃の行いが悪いのか独自設定が機能しているサイトがほとんど確認できません。MY_SITEINFO無しで以下全てのサイトが機能していません。

wedata URL
400_a https://www.newyorker.com/magazine/food-and-drink
400_b https://gadget-shot.com/
400_c https://www.jinnsblog.com/
400_d http://bash.org.pl/latest/
400_e http://octech.jp/modules/wordpress/
649 https://blog.nicovideo.jp/3d/2014/06/pmx.html
650 http://majikichi.com/
85437 https://oiio.jp/

Grieverさんのコメントを読む限り、これらのサイトを切り捨てているとは思えません。私が何かを見落としているはずです。

追記


無事アップデートで上記サイトが機能しています。素早く対応していただき助かりました。

uAutoPagerize ver 0.1.7の仕様変更について

Build-in SITEINFO
誤作動の多い items/400 と items/649 を無効化して独自の汎用サイト設定を組み込んだ。
正確には items/80660, items/430, items/401 以外の https://www.example.com/ にマッチする SITEINFO を無効にした

400や649といった汎用のsiteinfoは無効化され、独自の設定だけで動作するようです。

これまでより動作するサイトが限定されるのが不満な方はMY_SITEINFOに400や649からコピペして設定されるのをお勧めします。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
アイテム: hAtom - データベース: AutoPagerize - wedata

参考までに私の設定を置いておきます。
http://plsk.net/uap_set_general

一つ心配していることがあります。Grieverさんがこの仕様変更に踏み切った理由は、wedataのsiteinfoに不満があるからと考えるのが自然です。おそらくその原因の一つは400への私の対応でしょう。

もしこれまでより独自設定で動作するサイトが減れば、uAutoPagerizeユーザーにとっては動作する範囲が狭くなって手間が増えたと責められるのではないでしょうか。我ながら小物の発想ですね。

幸いにして今のところそういった動きはありません。uAutoPagerizeユーザーはGrieverさんに似て理性的な方ばかりでよかったなと思います。

400や650が採用されないのは悲しいですが致し方ありません。コーダーは感情に流されてはなりません。その瞬間瞬間でベストを尽くすしかありません。

wedata:400でcount()を使用した意図 その5

このシリーズはひとまずこれで終わりにしたいと思っています。
codepen.io
昨日やり残していたEntry + subとEntry 非 article + subですが、対応が難しいです。メイン側とサイドバー側をXPathで汎用的に見きわめる方法がないからですね。

多野さんの意図を自分なりに書くという当初の目的は現状で十分に果たされていますので、今後の課題として残しておきます。

自分でコードを書くのにこだわらず、もっと早い段階で多野さんやGrieverさんのコードを受け入れていればそう苦労しなかったはずです。wedataコーダーの皆さんには、ご迷惑をおかけしました。私が狭量と言ってしまえばそれまでですが保守の手間を考えればそう悪くないのかなとも感じています。

最初にexampleUrlを整理していたのがまさかA or B - A and Bの発想で活かせるとは思っていませんでした。幸運に恵まれた結果です。

Grieverさんのおかげで、XPathと向かい合う時間を作れました。コードにどういう意図があるのかを明確に伝えるのが大事だとよくわかりました。厳しい目を持ってコーディングと向き合わねばならないと教えられた気がします。ありがとうございます。

最後にこれから挑戦される方のために、メイン(メインエントリ側)とサブ(サイドバー側)に適用される数でそれぞれ現状と理想の動作を表にしておきます。n>1です。

メイン サブ 現状 理想
0 1 機能しない 機能しない
0 n サブ側で機能する 機能しない
1 0 機能しない 機能しない
1 1 機能しない 機能しない
1 n サブ側で機能する 機能しない
n 0 メイン側で機能する メイン側で機能する
n 1 メイン側で機能する メイン側で機能する
n n 機能しない メイン側で機能する

wedata:400でcount()を使用した意図 その4

また更新しました。Grieverさんのコメントを私なりに生かそうとしています。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata

今日もGrieverさんからのコメントにお答えします。

関連記事を取得したくないのではなく、関連記事を取得しそうな場合は AutoPagerize を動作させないという意図ですよね?

wedata:400でcount()を使用した意図 その2 - 1300

そもそもsiteinfoの作成に関しては優先順位をつけています。通常通り機能できればベストですが、ワーストはsiteinfoの適用によりデザインが崩れる場合です。ダミーコードが必要になるような事態は極力避けたいですね。
tanyao.hatenadiary.jp
サイトデザインの崩壊が想定される場合は機能自体を避けるべきだと考えています。機能はしませんがその分悪影響もありません。ベターと言えるでしょう。表にしておきます。

機能 優先順位
通常どおり機能 1
機能しない 2
誤ったsitienfoが機能(デザインの崩壊) 3

count()を使用したのはワーストの3を回避しベターの2にするためです。ご指摘のcaseAに関しては.sub側(サイドバー)のノードが適用されるのを避けて、機能自体をしないようにしています。もしサイドバー側へ適用されれば、デザインが崩れダミーコードが必要になる可能性が高いからです。
codepen.io
当然ながら通常通り機能させたいのはやまやまですが、下手に弄ればどう転ぶものかと腰が引けています。まず最初にここから説明するべきだったのかもしれません。

追記

なんとかもっとわかりやすくできないかと弄っていたのですが、こういうケースで異常動作を防げない事に気が付きました。
codepen.io
count(//*[./article[starts-with(@id,"post-")]])=1で条件式のチェックを通ってしまいます。どうしたものでしょうか。

追記2

なんとか対応したつもりです。これだけ頭を使うのは久しぶりですね。
http://wedata.net/items/400?rev=154714

追記3

Grieverさんからこのエントリにコメントをいただきました。

数える対象を間違えている気がします。
取得するのは『article が複数ある場合』なので数えるべきは『article を複数もつ親』では無いでしょうか?

テストケースと『article を複数もつ親』が複数ある場合は動作しない例を用意しました。
https://codepen.io/Griever2/pen/YzqGNNQ

wedata:400でcount()を使用した意図 その4 - 1300

ありがとうございます。これだけ多くのテストケースを書かれている労力を考えると私より大変な思いをされている気がします。お疲れさまです。

articleとidの関係が2倍で取得する場合の条件式をより厳しくしました。
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata
article 4 id 2やarticle-id 4 article 2に関してはこれで対応できるはずです。問題はEntry + subとEntry 非 article + subですね。少しだけ覚悟を決める時間をください。

wedata:400でcount()を使用した意図 その3

よく考えてみると、現状の私案だとこういうケースに対応できない事実に気が付きました。Grieverさんはこれにも対応させたいのかもしれません。
codepen.io
多野さん案なら対応可能なはずです。

どうしたものでしょうか。アイデアをお持ちの方はぜひ教えて下さい。とりあえずいい考えが浮かぶまでは、誤って動作させるのが怖いので現状を維持しようと思います。

追記

更新しました。また長くなりましたがこれなら上記のケースもどうにかなりそうです
アイテム: Generic Posts Rule - データベース: AutoPagerize - wedata

wedata:400でcount()を使用した意図 その2

前回のエントリにGrieverさんからコメントを頂きました。

前回の記事も読ませていただいきましたが、私は items/400 は 2 パターンだと解釈しています。
(//article | //*[starts-with(@id, 'post-')]) と id('content')/div[contains(@class,'post')] ですね。


article も starts-with(@id, 'post-') も単体ではどこにマッチするかわかりませんが、兄弟が複数存在する場合に限定することで「記事一覧」にマッチするように仕組まれています。(ときどき個別記事の関連記事一覧を取得して誤爆していますが…)
実際に div[@id='post-1234'] や article[@id='post-1234'] のような使われ方のページが非常に多く、区別する必要がないと思っています。


id('content')/div[contains(@class,'post')] は別パターンですが一応 div を数えて複数存在する場合に動作させようという意図が見えます。


この「複数存在する場合」という条件が Generic Post"s" Rule の要だと思います。


また重複を気にされてますが、同じ要素を二重に取得するわけではないので重複しても問題ないですが…。

wedata:400でcount()を使用した意図 - 1300

さきほどupdateを行いました。しつこいようですがこれしかできません。
http://wedata.net/items/400?rev=154703

コメントありがとうございます。//articleと//*[starts-with(@id,"post-")]のいずれか、あるいはこの重複に適用されるかを明確にしなければどこに適用されるか怖いと思うのですが…単に私が小心者なだけでしょうか。

exampleUrlを5ケースに分離したのはそれなりに意義があると言わせてください。なぜ骨を折ったのかと悲しくなります。機能上は構わないのかもしれませんがexampleUrlを整理したのが無駄とは考えたくありません。

同一階層内に複数存在するかどうかの見落としに関しては、完全に私のミスです。親ノードから見てこんな条件式を付け加えました。

count(./article)>1 or count(./*[starts-with(@id,"post-")])>1

一応提示していただいたテストケースには対応しているようです。まだおかしな点があれば遠慮なくおっしゃってください。

追記

以下の条件式で適用を回避したいケースを簡単に書きました。意図が伝わるでしょうか。

count(//article)=count(//*[starts-with(@id,"post-")]) or count(//article)=count(//*[starts-with(@id,"post-")])*2 or count(//article)*2=count(//*[starts-with(@id,"post-")]) or count(//article)<2 or count(//*[starts-with(@id,"post-")])<2

codepen.io

wedata:400でcount()を使用した意図


>単一の article 要素まで取得しているのは意図的なんでしょうか?
完全にミスです。すみませんでした。

そもそもなぜ手を入れたかですが、多野さん(Tanookirby)が自分の編集案(rev=153802)を強く押すのであれば、私は手を入れるつもりはありませんでした。しかし結果的に多野さんは村雨さん(apuser4)のロールバックを受け入れています。

これを見て400の管理に対して情熱を失っていると判断しました。そこで私なりに多野さんの意図を引き継げるよう解釈して分かりやすくシンプルにできないかやってみたのですが、難しいですね。

count()を使用した意図としては、誤って適用されるのを防ぐため前回説明したパターン1とパターン2、そしてその重複の3パターンいずれに適用するかを明確にしたいです。当初の条件式はこうでした。

[count(//article)=count(//*[starts-with(@id,"post-")]) or count(//article)=0 or count(//*[starts-with(@id,"post-")])=0]

count(//article)=count(//*[starts-with(@id,"post-")])なら重複、count(//article)=0ならパターン2、count(//*[starts-with(@id,"post-")])=0ならパターン1です。

これに今日以下の条件を付け加えています。

count(//article)=count(//*[starts-with(@id,"post-")])*2

85453を見て//article[starts-with(@id,'post-')][count(.//article)=1]へ対応したいと考えました。
アイテム: VOZ Next - データベース: AutoPagerize - wedata
本来適用されるべきでないケースに偶然適用される可能性も考えられますが、この程度なら大丈夫だろうと判断しています。

以上です。結果多野さん案よりごちゃごちゃしていますね。力量不足です。