On devel mode- I have contacted the maintainer of the Shaker package in hopes of getting it to build with ghc7 so that using Shaker can be better investigated- it seems to already take the approach that we want, so it may have already solved some of our problems. I have also requested a cabal-dev library api (instead of just a command line interaction), which would make it easier to use cabal-dev in development mode.<div>
<br></div><div>As for storing rendered web pages- if you are displaying a link to them it seems that you need a database entry. This kind of entry doesn't seem like it makes sense in an hledger journal unless there is a section for configuration. I don't know if you already have config files- seems like it could be there. Otherwise a sqlite database could be used. Normally database entries point to external files rather than embed the file directly for performance reasons that may not concern you. An approach for external files could be a directory structure within a config directory. I think the community is in need of some re-usable file attachment code that makes it easy to save a file and switch between the local file system or Amazon S3, etc.</div>
<div><br></div><div>Greg weber<br><br><div class="gmail_quote">On Mon, May 30, 2011 at 4:56 PM, Simon Michael <span dir="ltr"><<a href="mailto:simon@joyful.com">simon@joyful.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 5/30/11 4:54 PM, Simon Michael wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I sent some experience notes on these earlier today, but it doesn't seem to want to show up on this list and I got no<br>
bounce. Let's see if this one gets through ?<br>
</blockquote>
<br></div>
Ha! Quickly, now:<br>
<br>
<br>
<br>
(Fourth attempt to cc web-devel .. moderator, please reject the previous if they show up in your queue)<br>
<br>
Hi all,<br>
<br>
if you watch the hledger repo or #ledger irc channel, you'll have noticed that hledger-web was upgraded from yesod 0.6 to 0.8. Also I adopted the organization of yesod's scaffold template app, then simplified that in a way that I like, and finally moved all the inline hamlet templates to files (in hledger-web/.hledger/web/templates). I updated the hamlet syntax by hand; if I did it over, I would try harder to move to files first and then use the conversion tool provided by hamlet. For interest, all this took about 20 hours.<br>
<br>
Learning yesod, it sometimes feels over-intricate and obstructive (like when learning haskell..) However all the problems I've hit so far had solutions, everything has its place and once you fit the pieces together it all works really well. And all the necessary pieces exist. And many of them have great documentation. BIG thanks to Michael and the yesod team!<br>
<br>
I'm still learning how best to do things but developing the web app has become quite pleasant - I invite you to join in and build some really useful financial uis. Here are some notes on running the app:<br>
<br>
- The default build, aka yesod's "debug mode", reacts immediately to changes in static files and lucius/cassius/julius templates, but not hamlet templates. To see hamlet changes you need to also touch the affected hs files (or all of them) and rebuild. Or, use "yesod build" which touches the hs files for you (but doesn't work for me on mac yet.)<br>
<br>
- "yesod devel" runs the app in "devel mode", which should quickly rebuild and restart when any template or code file changes. I haven't got this to work yet ("Testing files.." repeatedly, nothing running) but this will be the way to go.<br>
<br>
- The wai-handler-devel package provides an alternate (deprecated ?) devel mode, which reacts to code changes (but not hamlet changes, so touch the hs files for those). I heard it's slower than yesod-devel but it's quicker than a normal rebuild/restart. I've got it working with some hardcoded values, let me know if you need that code.<br>
<br>
- The "production mode" build (cabal configure -fproduction) has all templates embedded. It still needs to serve the static files from disk though, so my write-out-files-on-startup hack is still needed (see EmbeddedFiles.hs). We'll probably figure out how to embed the static files too, and then production mode won't need anything from disk.<br>
<br>
Next steps: now it's easier to move the web ui forward, and I've been forming some plans<br>
(see <a href="http://twitter.com/#!/simonkwmichael/status/74966725057191936" target="_blank">http://twitter.com/#!/simonkwmichael/status/74966725057191936</a>). FYI <a href="http://demo.hledger.org" target="_blank">http://demo.hledger.org</a> will keep running the latest release, for new visitors, and there's now <a href="http://demo.hledger.org:5001" target="_blank">http://demo.hledger.org:5001</a> which runs directly out of the trunk repo; this will be the place to preview and experiment.<br>
<br>
Finally, a random brainstorming question: I'd like to be able to push a button to save the current filtered view as a named favourite, and link these in the navigation area for quick access. What's the best scope for these "canned reports" - current (top-level) journal file, current directory, current user, ... ? And related but orthogonal: where to store them - embedded in the journal, saved in a separate db (using yesod's persistent), attached to the authenticated user's settings, ... ?<br>
<br>
Best,<div><div></div><div class="h5"><br>
-Simon<br>
<br>
<br>
_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org" target="_blank">web-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</div></div></blockquote></div><br></div>