Hi all, I''ve tweaked Matteo''s blog support into my pages (see my signature, the "Notes" tab). First a couple remarks / feature requests for short-term things: - the feed generator puts raw markdown into the feed, it should format it - there is no way to add the RSS auto-discovery links to a page (I sent a mail about that some days ago) Then, taking a few steps back on the design, I think I would prefer if the blog generator was more like the feed one. It''s probably a bit far-fetched, but let me explain? currently it does several things at the same time: generate the post/tags page hierarchies, the paginations, and the blog entry point, all using a single template (the foo.blog file). Instead, I think it would be better if the foo.blog file was just for setting the configuration for generating the blog hierarchy. We would give it a pattern for post pages, templates to use for the list pages, and it would generate the basic content of the blog: - individual post pages, - the paginated lists of post abstract (the current way of numbering them from 1 for the earliest N entries is good because it won''t change once it''s generated) - archive pages, classifying posts per year, per tag? etc; those could each link to a large number of posts, if they only display the titles. My hierarchy is blogRoot/YYYY/post.page, so the per-year archive pages could be blogRoot/YYYY/index.N.html. Tag lists could be blogRoot/FOO/index.N.html? Then, any page could use a tag to include links to or the abstracts of the N most recent entries. My idea here is that I''d like to handle the lists of events on the front page of my site. This could be a separate blog, with very small entries, and the front page would display posts with a date in the future (events I''ll attend) and complete the list with a small number of past news/events I attended, each post being just an H6 header and a couple of lines. No pagination, no tags, no per-post individual pages, just the list on the main page and per-year archive pages. BTW, I tried to invoke a template for displaying post abstracts in the blog entry point, but I ran into problems passing information from the index.blog to the template? not sure it''s really feasible, or if meta info needs to be set in clever ways? Anyway, enough blabber, let me know what you think ;) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
2009/12/7 Damien Pollet <damien.pollet at gmail.com>> Hi all, > > I''ve tweaked Matteo''s blog support into my pages (see my signature, > the "Notes" tab). > > First a couple remarks / feature requests for short-term things: > - the feed generator puts raw markdown into the feed, it should format it > - there is no way to add the RSS auto-discovery links to a page (I > sent a mail about that some days ago) > > Then, taking a few steps back on the design, I think I would prefer if > the blog generator was more like the feed one. It''s probably a bit > far-fetched, but let me explain? currently it does several things at > the same time: generate the post/tags page hierarchies, the > paginations, and the blog entry point, all using a single template > (the foo.blog file). >After working on it for some time, I feel that this is not the right way to go. It''s too messy and it has clearly too much responsibilities. Moreover I think that the current blog addon is not fixable with this design, as you stated it has too many responsibilities.> Instead, I think it would be better if the foo.blog file was just for > setting the configuration for generating the blog hierarchy. We would > give it a pattern for post pages, templates to use for the list pages, > and it would generate the basic content of the blog: > - individual post pages, > - the paginated lists of post abstract (the current way of numbering > them from 1 for the earliest N entries is good because it won''t change > once it''s generated) > - archive pages, classifying posts per year, per tag? etc; those could > each link to a large number of posts, if they only display the titles. >I completely agree with you.> My hierarchy is blogRoot/YYYY/post.page, so the per-year archive pages > could be blogRoot/YYYY/index.N.html. Tag lists could be > blogRoot/FOO/index.N.html? >That would be nicer to have, but I fear that it may be difficult to build such a complex addon, at least without a good test suite. After every change to the current blog engine there are too many things to test manually, mostly due to the update step. In fact if there''s a change in one of the posts, all archive/tags nodes should be correctly regenerated.> Then, any page could use a tag to include links to or the abstracts of > the N most recent entries. My idea here is that I''d like to handle the > lists of events on the front page of my site. This could be a separate > blog, with very small entries, and the front page would display posts > with a date in the future (events I''ll attend) and complete the list > with a small number of past news/events I attended, each post being > just an H6 header and a couple of lines. No pagination, no tags, no > per-post individual pages, just the list on the main page and per-year > archive pages. >Well I personally don''t need it, but I fear that it won''t be easy to achieve. I think we should setup a git branch with the current blog addon and start refactoring it. Split it up in several files/classes, so the webgen related stuff won''t be mixed with the tag, archive and translation logic. Maybe some unit test also will help. I would like to end up with a git branch that can be easily included in a website through the use of git submodule, and initialized through a simple init.rb file in its root directory. What do you think? Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/webgen-users/attachments/20091211/f824218d/attachment.html>
Hi Matteo, I''ve started fiddling with a new implementation, taking bits and pieces from your code and from webgen source handlers like the Feed one. I can''t say if I will get much time to work on it (though I will very probably use that to fight boredom during the xmas break, rather than grade exams :), but I''ll put the code online when I have a first working prototype. The idea is to get the basic archive/tag nodes generation going, then we can add the templates/tags sugar and organize the code into a releasable shape. On Fri, Dec 11, 2009 at 09:44, Matteo Collina <matteo.collina at gmail.com> wrote:> > > 2009/12/7 Damien Pollet <damien.pollet at gmail.com> >> >> Hi all, >> >> I''ve tweaked Matteo''s blog support into my pages (see my signature, >> the "Notes" tab). >> >> First a couple remarks / feature requests for short-term things: >> - the feed generator puts raw markdown into the feed, it should format it >> - there is no way to add the RSS auto-discovery links to a page (I >> sent a mail about that some days ago) >> >> Then, taking a few steps back on the design, I think I would prefer if >> the blog generator was more like the feed one. It''s probably a bit >> far-fetched, but let me explain? currently it does several things at >> the same time: generate the post/tags page hierarchies, the >> paginations, and the blog entry point, all using a single template >> (the foo.blog file). > > After working on it for some time, I feel that this is not the right way to > go. > It''s too messy and it has clearly too much responsibilities. > Moreover I think that the current blog addon is not fixable with this > design, as you stated it has too many responsibilities. > >> >> Instead, I think it would be better if the foo.blog file was just for >> setting the configuration for generating the blog hierarchy. We would >> give it a pattern for post pages, templates to use for the list pages, >> and it would generate the basic content of the blog: >> - individual post pages, >> - the paginated lists of post abstract (the current way of numbering >> them from 1 for the earliest N entries is good because it won''t change >> once it''s generated) >> - archive pages, classifying posts per year, per tag? etc; those could >> each link to a large number of posts, if they only display the titles. >> > > I completely agree with you. > >> >> My hierarchy is blogRoot/YYYY/post.page, so the per-year archive pages >> could be blogRoot/YYYY/index.N.html. Tag lists could be >> blogRoot/FOO/index.N.html? >> > > That would be nicer to have, but I fear that it may be difficult to build > such a complex addon, at least without a good test suite. > After every change to the current blog engine there are too many things to > test manually, mostly due to the update step. > In fact if there''s a change in one of the posts, all archive/tags nodes > should be correctly regenerated. > >> >> Then, any page could use a tag to include links to or the abstracts of >> the N most recent entries. My idea here is that I''d like to handle the >> lists of events on the front page of my site. This could be a separate >> blog, with very small entries, and the front page would display posts >> with a date in the future (events I''ll attend) and complete the list >> with a small number of past news/events I attended, each post being >> just an H6 header and a couple of lines. No pagination, no tags, no >> per-post individual pages, just the list on the main page and per-year >> archive pages. > > Well I personally don''t need it, but I fear that it won''t be easy to > achieve. > > I think we should setup a git branch with the current blog addon and start > refactoring it. Split it up in several files/classes, so the webgen related > stuff won''t be mixed with the tag, archive and translation logic. Maybe some > unit test also will help. > I would like to end up with a git branch that can be easily included in a > website through the use of git submodule, and initialized through a simple > init.rb file in its root directory. > > What do you think? > > Matteo > > > _______________________________________________ > webgen-users mailing list > webgen-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/webgen-users >-- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
2009/12/15 Damien Pollet <damien.pollet at gmail.com>> I can''t say if I will get much time to work on it (though I will very > probably use that to fight boredom during the xmas break, rather than > grade exams :), but I''ll put the code online when I have a first > working prototype. The idea is to get the basic archive/tag nodes > generation going, then we can add the templates/tags sugar and > organize the code into a releasable shape. >Well, I look forward to see it. If you can put a branch on github I''ll certainly work on it during xmas break. I''m thinking about a nice way to decouple the blog addon from the translation stuff, maybe allowing a little bit of duplication in the site sources, but at least this might be stabler and easier to mantain. These is the harder part of the problem, because I''ve not yet understood how webgen handle translated nodes at all. A little note about license: I''ve released my code with the MIT license, however I''ve just noticed that webgen is GPL (v2 I think). So the blog addon must be GPL v2 too. I''m sorry for the mistake, I''m not really interested in licenses at all. Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/webgen-users/attachments/20091215/c5721068/attachment.html>