Will Paginate + групиране + тоталс

[Петьо Иванов]

Ръй!

Снощи в доста уморено състояние мъчех тефтерчето, та блъснах един леко
забавен момент, с който си мисля да ви посъбудя (сигурен съм, че ще
дадете по-добри предложения).

Става въпрос за следното парче код:

http://github.com/underlog/piggybank/blob/tefter/app/models/expense.rb#L14-23

Искам да изкарам разходите, но и да покажа тотал за всеки ден. Освен
това искам да paginate-на, без да правя умно "view".

Не ми харесва нуждата да връщам две стойности от функцията, защото
втората е необходима само за да кажа:

<%= will_paginate @expense_dates -%>

Има едни хватки с pager.replace в will_paginate, но пък и те не ми се
струват много чисти...

[Tihomir Georgiev]

Ако искаш да запазиш will_paginate, ще трябва да минеш или с някакъв
custom WillPaginate::Collection (pager.replace магариите), или с
някакъв custom renderer за collection-a. И в двата случая е повече
код, отколкото заслужава.

Защо не пробваш да abstract-неш кода, който групира по дата, така че
да можеш да го ползваш с произволен collection, а не само в комбинация
с paginate-ването? Така няма да имаш нужда да връщаш две стойности от
един метод.

И един малък въпрос: можеш ли да обясниш защо предпочиташ да използваш
.tap на места, където не chain-ваш методи и не го използваш вместо
returning?

Лек ден,
-Тишо

~ Quidquid latine dictum sit, altum sonatur.

2009/11/17 Петьо Иванов <unde...@gmail.com>:

[Петьо Иванов]

Да, аз исках да избягам от умни вюта и хелпъри и рендъръри. Първата
версия на вюто беше точно "умна" (по хисторито може да се види). Нещо
не ме накефи, тестовете стават по-сложни. Най-правилното май наистина
е custom WillPaginate::Collection - ще видя дали pager.replace ще
мрънка ако му дам хеш.

Иначе кода за групирането бих го абстрактнал като му дойде реда да го
ползвам другаде, което за момента не е така. Самоцелно да го дърпам...
май не разбирам какво точно имаш предвид, понеже не си представям как
ще ми спести двете стойности.

Иначе returning е rails идиом, tap е руби (от някоя версия натам).
Kарам с tap винаги, макар че понякога returning е по-"intention
revealing".

On Nov 17, 1:52 pm, Tihomir Georgiev <tihomir.georg...@gmail.com>
wrote:

> Ако искаш да запазиш will_paginate, ще трябва да минеш или с някакъв
> custom WillPaginate::Collection (pager.replace магариите), или с
> някакъв custom renderer за collection-a. И в двата случая е повече
> код, отколкото заслужава.
>
> Защо не пробваш да abstract-неш кода, който групира по дата, така че
> да можеш да го ползваш с произволен collection, а не само в комбинация
> с paginate-ването? Така няма да имаш нужда да връщаш две стойности от
> един метод.
>
> И един малък въпрос: можеш ли да обясниш защо предпочиташ да използваш
> .tap на места, където не chain-ваш методи и не го използваш вместо
> returning?
>
> Лек ден,
> -Тишо
>
> ~ Quidquid latine dictum sit, altum sonatur.
>

> 2009/11/17 Петьо Иванов <under...@gmail.com>:

>
>
>
> > Ръй!
>
> > Снощи в доста уморено състояние мъчех тефтерчето, та блъснах един леко
> > забавен момент, с който си мисля да ви посъбудя (сигурен съм, че ще
> > дадете по-добри предложения).
>
> > Става въпрос за следното парче код:
>

> >http://github.com/underlog/piggybank/blob/tefter/app/models/expense.r...

[Tihomir Georgiev]

Да дообясня. В момента in_pages_with_dates връща две стойности, чието
предназначение е за две различни части от приложението. Сам си каза,
че @expense_dates го връщаш само заради will_paginate. Другото е за
само за изчертаването на таблица във view-тo. Не виждам смисъл да са
на едно място. Имах предвид нещо по-просто, подобно на следното:

expenses_controller.rb:

@expenses = Expense.paginate options
@grouped_expenses = Expense.grouped_by_date_with_totals(@expenses)

Така поне е ясно кое какво връща. За extra sugar можеш да си добавиш
grouped_by_date_with_totals към Array, за да имаш
@expenses.grouped_by_date_with_totals.each {...}, но е малко мръсно.
Сега като се замисля, хич не ти и трябва тоя ред в контролера. Ако
искаш да спестиш малко код, можеш да изместиш
Expense.grouped_by_date_with_totals(@expenses).each { } направо във
view-то.

Относно tap ми е ясно чий идиом е, но ми е интересно защо изобщо го
използваш в случаи, в които няма очевидна полза от употребата му
(нямаш chaining и не връщаш tap-натия обект). Тези редове, например:

Month.current.tap do |current|
@month_total = current.total
@month_average = current.average
@categories = current.categories
end

Не могат ли да се заменят с:

current_month = Month.current
@month_total = current_month.total
@month_average = current_month.average
@categories = current_month.categories

С какво tap вариантът е по-различен и по-добър, или е въпрос на личен
стил на писане?

-Тишо
~ Quidquid latine dictum sit, altum sonatur.

2009/11/17 Петьо Иванов <unde...@gmail.com>:

[Петьо Иванов]

Да, разбрах какво имаш предвид вече. И май май се убедих, че най-
чистия вариант е да си оправя нещата както трябва в модела (къстъм
колекция). В противен случай контролера и вю спека ще станат целите
мок до мок.

Освен ако не преосмисля, че групирането е проблем на презентацията, не
на модела. Което е добър въпрос.

В конкретния пример tap-вам, за да не цапам scope-a, и е по-скоро
въпрос на вкус, отколкото практическа файда.Променливата current_month
после не ми трябва, за това я взимам само за блока.

On Nov 17, 3:20 pm, Tihomir Georgiev <tihomir.georg...@gmail.com>
wrote:

> 2009/11/17 Петьо Иванов <under...@gmail.com>:

[Tihomir Georgiev]

И аз се зачудих дали групирането да не става в хелпър, но се
саморазубедих заради изчислението на total-ите. Тия неща сякаш трябва
да си ги знае модела (ама е спорно, тъй че давай да спорим).

Разбрах за tap-а. Иде ми малко параноично в случая, но те разбирам.

-Тишо
~ Quidquid latine dictum sit, altum sonatur.

2009/11/17 Петьо Иванов <unde...@gmail.com>:

[Петьо Иванов]

tap-a мисля, че го прихванах от раганвалд, ама да не ме чуе, че
сигурно ще се смее...

Иначе за спор основа няма. Аз уж се водя от това кое е по-лесно за
тестване, и кое ще чупи тестовете по-малко при бъдещи промени. Всичко
друго е бошлаф, или "въпрос на вкус" За съжаление все още не съм
достатъчно нахитрял на спекове, за да мога да предвидя как ще се
развият нещата.

Като(ако) си вдигна гъза да го оправя от сегашното, ще постна пак
комита. Мерси за дискусията.

On Nov 17, 4:19 pm, Tihomir Georgiev <tihomir.georg...@gmail.com>
wrote:

> И аз се зачудих дали групирането да не става в хелпър, но се
> саморазубедих заради изчислението на total-ите. Тия неща сякаш трябва
> да си ги знае модела (ама е спорно, тъй че давай да спорим).
>
> Разбрах за tap-а. Иде ми малко параноично в случая, но те разбирам.
>
> -Тишо
> ~ Quidquid latine dictum sit, altum sonatur.
>

> 2009/11/17 Петьо Иванов <under...@gmail.com>:

[Петьо Иванов]

Снощи упражних насилие над уилиам пагинате, обаче той не прощя да му
викна pager.replace с хеш. Объркал съм се. Този проблем си е на
презентацията. Доказателството - с хелпър стана по-чисто. И моковете
ми се оправиха, не разхвърлям някакви празни масиви и хешове.

git diff --shortstat на комита дава
40+, 56-

http://github.com/underlog/piggybank/commit/494d4047607edc395645dd07a71145e8059fa506