NewsAggregator. Inconsistent author name retrieval

[l.inc]

Good day. I noticed today, that my history for rss contacts was full of dummy e-mail placeholders. When I looked into the code I found, that for the atom feeds the author tag was handled by retrieving the name subitem and this way naturally omitting the e-mail (email subitem). Contrariwise the rss feeds handling of the author tag reported the whole tag contents disregarding separation of the e-mail and the name parts. I attached a very little patch to fix this. The "Feed Tag Help" should probably also adjusted accordingly, but it's not done by the patch.

While fixing the problem I also noticed that a db entry "e-mail" was set to the name subitem content of the author tag for atom feeds. I didn't investigate further, if this was meant to be like that, but still fixed this, as this was intuitively incorrect.

I'm nearly sure, my complaint isn't gonna change anything, but I really dislike the attempt of unification of the atom and rss tags. When I needed to compose an atom feed display format before, I just looked into the source of the feed in browser and put the tags into the text box of the RSSNews plugin. Now I also have to look into the source codes of the NewsAggregator plugin in order to find the corresponding equivalents for id (guid), for summary (description), and updated is not even available (same as pubDate for rss feeds), even though the "Change Feed" dialog clearly declares all item's tags to be valid. My preference would be to be able to use all tags exactly as those are specified in the actual feeds.

[Mataes]

hi!
Could you provide atom feed example and screenshots with errors?

[l.inc]

Mataes
I didn't say anything about visible errors in atom feeds. Thus, I don't think, I understand, what you're asking about.

[Mataes]

i don't understand about what you says. so i want that you illustrate your problem

[l.inc]

Mataes
Основная проблема с rss-новостями. В тег author в rss-новостях включается почтовый адрес и имя, но имя включается в скобках после адреса. Аналогично в atom-новостях включается почтовый адрес и имя, но отдельными xml-элементами. Так вот обработчик atom-новостей вместо author подставляет в шаблоне имя автора (что, собственно, обычно и ожидается), а обработчик rss-новостей пихает всё вместе в сообщение, не выполяя разбора. В результате, например, новости отсюда в логах содержат абсолютно бесполезный dummy@example.com .

Вторую ошибку, исправляемую патчем, "проиллюстрировать" будет сложнее, т.к. я не знаю, куда потом отправляется почтовый адрес, но это очевидный баг. В любом случае на мой взгляд исправления в патче настолько просты и очевидны, что не требуют пояснения.

Ну и в третьем абзаце я пожаловался на то, что унификация тегов в atom и rss — неудачная идея, просто добавляющая проблем. Я бы предпочёл указывать теги в настройках шаблонов новостей такими, какими они указаны в самих новостях. Это значит, что если я в atom-новости вижу summary, то я и хочу указать summary в шаблоне, а не выискивать по исходникам плагина, чем же автор решил его заменить.

[Mataes]

первое и второе теперь суть понятна. Посмотрю на досуге что и как там прилетает, думаю сделаю еще отдельный тег под email.
3. по мне так нормальная идея, потому что плагин будет показывать ровно те теги, которые в него заложены. в рсс и атоме по мне так реально хаос, каждый канал делает все по своему.

[l.inc]

Mataes
Отдельный тег под e-mail — это, может, и хорошая идея, но при раскрытии author очень желательно предусмотреть fallback к e-mail'у, если имя отсутствует. Сообственно, так, как это делает приложенный патч для rss.

по мне так нормальная идея, потому что плагин будет показывать ровно те теги, которые в него заложены

И что ж в этом хорошего? Это только ограничивает гибкость настройки. Да ещё и усложняет её, потому что проследить соответствие между желаемым отображением новости и ответственными за это тегами можно только посредством чтения исходников плагина.

каждый канал делает все по своему

И именно поэтому важна гибкость настройки, а не унификация.