hledger-web: deprecated object-data-* dependencies

[Peter Simons]

Hi,

the hledger-web package depends on 'data-object' and 'data-object-yaml',
but those libraries are deprecated, and Michael Snoyman won't maintain
them any more. This situation is causing trouble for distributors (such
as me, trying to package hledger-web on NixOS), so I wonder whether
there are any plans to switch to another implementation that is still
being maintained?

Take care,
Peter

[Simon Michael]

Thanks for the heads-up. Yes indeed, a preliminary conversion to yesod 0.10 is already in darcs and just needs more testing/polish before release.

[David J Patrick]

On 5 March 2012 12:56, Simon Michael <si...@joyful.com> wrote:
> Thanks for the heads-up. Yes indeed, a preliminary conversion to yesod 0.10 is already in darcs and just needs more testing/polish before release.

Have you ever worked with a "grid system" for website layout, like fluid960gs ?
by any chance is there something equivalent for yesod ?

In the past I managed to bold 960gs to werc with surprising (to me)
success, it lends itself to easy description and consistently solid
effects, and a site that can be satisfyingly squeezed and stretched.

The other think I wanted to raise, as you assemble new web framework,
is the care and handling of the /static/ directory. In the recent
monster mock-ups I kludged together, I took the liberty of populating
the very top menu-bar with a slew of headings that represent possible
future functions. It occurs to me that the /static/ directory might be
handled in a more wiki way, much like the various no-sql websites,
werc, zim-wiki and others (and zwiki too, I think) so that those top
menu-bar choices are directly related to the (visible) folders under
/static, their actions related to index.html files in those folders,
submenu choices based on sub-folders, which are all based on whatever
templating/ markup engine you choose (but preferably markdown ;-).

This will allow/encourage variations, customisations and user
contributions, making is easier to develop enhanced functions for
hledger.

ideas4u
djp

--
d...@linuxcaffe.ca
OR
dava...@gmail.com
www.linuxcaffe.ca
geek chic and caffe cachet
326 Harbord Street,
Toronto, M6G 3A5,
(416) 534-2116

[Simon Michael]

Not yet, though I was learning about it just the other day.

I like your dynamic ideas of course. Those things can be hard to do with haskell. More importantly there's a metric ton
of things ahead of that in the queue and only little old me hacking in my copious free time. I need an intern I can
assign to djp... any takers ?

[David J Patrick]

On 6 March 2012 10:08, Simon Michael <si...@joyful.com> wrote:
> I like your dynamic ideas of course. Those things can be hard to do with
> haskell. More importantly there's a metric ton of things ahead of that in
> the queue and only little old me hacking in my copious free time. I need an
> intern I can assign to djp... any takers ?

I'm flattered that you think I need a handler ;-)
Of course I realise that the visual-feature-request bombs I have been
unleashing have back-end implications. Some of it should be trivial,
but some of it will require significant re-factoring. It's obviously
not going to happen overnight, but I DO hope it happens, for the
benefit of present and future *ledger users.

For now, just think "scaffolding", and then perhaps we can come up
with an implementation plan in phases. If the underpinnings are
comprehensible, I'm sure we can get some parallel development going.

In the mean time, there's more on the way :)