get-doc and get-metas don't work with ptree files #159

I'm a relative newbie to pollen, so I might be wrong, but it seems like get-doc and get-metas should also work with ptrees.

Thanks for such a nice tool!

I'm a relative newbie to pollen, so I might be wrong, but it seems like get-doc and get-metas should also work with ptrees. Thanks for such a nice tool!

Seems like it should. I’ll look into that. In the meantime you can retrieve doc and metas with dynamic-require like so:

(dynamic-require "my.ptree" 'doc)
(dynamic-require "my.ptree" 'metas)

Seems like it should. I’ll look into that. In the meantime you can retrieve `doc` and `metas` with `dynamic-require` like so: ```racket (dynamic-require "my.ptree" 'doc) (dynamic-require "my.ptree" 'metas) ```

The 'doc for a ptree is its pagetree, which you can retrieve with get-pagetree.

Having metas in pagetrees could be rather useful.

The `'doc` for a ptree is its pagetree, which you can retrieve with [`get-pagetree`](http://docs.racket-lang.org/pollen/Pagetree.html#%28def._%28%28lib._pollen%2Fpagetree..rkt%29._get-pagetree%29%29). Having metas in pagetrees could be rather useful.

Thanks!

On Wed, Dec 13, 2017 at 11:01 PM, Matthew Butterick <
notifications@github.com> wrote:

Closed #159 https://github.com/mbutterick/pollen/issues/159 via a731428
https://github.com/mbutterick/pollen/commit/a731428072b65581a342aa7bbc96b279896d395d
.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mbutterick/pollen/issues/159#event-1386960521, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGBYvowgNJ_7M4oYhl5EUhoApiDF7K0kks5tAJ2egaJpZM4Q_5v2
.

Thanks! On Wed, Dec 13, 2017 at 11:01 PM, Matthew Butterick < notifications@github.com> wrote: > Closed #159 <https://github.com/mbutterick/pollen/issues/159> via a731428 > <https://github.com/mbutterick/pollen/commit/a731428072b65581a342aa7bbc96b279896d395d> > . > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <https://github.com/mbutterick/pollen/issues/159#event-1386960521>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AGBYvowgNJ_7M4oYhl5EUhoApiDF7K0kks5tAJ2egaJpZM4Q_5v2> > . >

Having metas in pagetrees could be rather useful.

I’ve wondered at times whether permitting metadata (IOW, attribute fields) for each entry in the pagetree would be useful. I haven’t figured how to do it without making the pagetree structure itself unwieldy.

> Having metas in pagetrees could be rather useful. I’ve wondered at times whether permitting metadata (IOW, attribute fields) for each entry in the pagetree would be useful. I haven’t figured how to do it without making the pagetree structure itself unwieldy.

I’ve wondered at times whether permitting metadata (IOW, attribute fields) for each entry in the pagetree would be useful.

The way I understand it, the stated mission of the pagetrees is to avoid having to maintain ordering and grouping info within the document sources themselves. Maybe there are other kinds of such info that make more sense to centralize in the pagetree. But I think one attribute of such information is that, like ordering info, it would need to be something you already have to define for every single pagenode (at least, in order to be a good fit for being located in the pagetree).

Right now I’m working on a thing where every Pollen source could be part of multiple groups, and these memberships would change over time: for example, when a source is included in a print edition, it would be added to the group for that edition. (A) The group itself will have some information associated with it (dates, a name and description, etc.) and (B) ideally the templates would be able to access some info about each source’s membership.

I’m debating whether to have each source elect itself into these groups by defining metas, or whether to create separate pagetrees for each group. The main reason I’m considering pagetrees for this purpose is that it would probably result in faster build times.

Having metas available in each pagetree likely helps with my requirement (A), but in order to satisfy (B) I would likely still need to maintain metas in each source pointing back to the pagetrees of which that source is a member.

And that (B) requirement is also the reason that, in every use case I’ve thought of so far, metas in individual documents are more appropriate.

Admittedly, the thing I’m working on here falls near the edge or outside of Pollen’s remit as an environment for creating Books.

> I’ve wondered at times whether permitting metadata (IOW, attribute fields) for each entry in the pagetree would be useful. The way I understand it, the stated mission of the pagetrees is to avoid having to maintain ordering and grouping info within the document sources themselves. Maybe there are other kinds of such info that make more sense to centralize in the pagetree. But I think one attribute of such information is that, like ordering info, it would need to be something you already have to define for every single pagenode (at least, in order to be a good fit for being located in the pagetree). Right now I’m working on a thing where every Pollen source could be part of multiple groups, and these memberships would change over time: for example, when a source is included in a print edition, it would be added to the group for that edition. (A) The group itself will have some information associated with it (dates, a name and description, etc.) and (B) ideally the templates would be able to access some info about each source’s membership. I’m debating whether to have each source elect itself into these groups by defining metas, or whether to create separate pagetrees for each group. The main reason I’m considering pagetrees for this purpose is that it would probably result in faster build times. Having metas available in each pagetree likely helps with my requirement (A), but in order to satisfy (B) I would likely still need to maintain metas in each source pointing back to the pagetrees of which that source is a member. And that (B) requirement is also the reason that, in every use case I’ve thought of so far, metas in individual documents are more appropriate. Admittedly, the thing I’m working on here falls near the edge or outside of Pollen’s remit as an environment for creating Books.

something you already have to define for every single pagenode (at least, in order to be a good fit for being located in the pagetree).

I’ve wondered whether pagetree metadata should be an entirely separate thing, or if it should essentially act as a “batch meta”. For instance, a group of pages has a special template. I don’t want to add a template meta to every page. So I notate it in the pagetree, and then the pages behave as if that meta had been defined in the page itself. But even as I describe that, it sounds like global variables, which are bad for the usual reasons.

Having metas available in each pagetree likely helps with my requirement (A), but in order to satisfy (B) I would likely still need to maintain metas in each source pointing back to the pagetrees of which that source is a member.

Seems like you could do a hybrid approach where parts of the pagetree are dynamically generated from reading meta fields in source files? I did a similar thing in Beautiful Racket where most of the main pagetree is generated from directory listings of certain subfolders, but any source prefixed with ~ is ignored. This allowed me to rearrange things in the filesystem without having to repeatedly update the pagetree.

outside of Pollen’s remit as an environment for creating Books.

Let the authors decide 🤘

> something you already have to define for every single pagenode (at least, in order to be a good fit for being located in the pagetree). I’ve wondered whether pagetree metadata should be an entirely separate thing, or if it should essentially act as a “batch meta”. For instance, a group of pages has a special template. I don’t want to add a `template` meta to every page. So I notate it in the pagetree, and then the pages behave as if that meta had been defined in the page itself. But even as I describe that, it sounds like global variables, which are bad for the usual reasons. > Having metas available in each pagetree likely helps with my requirement (A), but in order to satisfy (B) I would likely still need to maintain metas in each source pointing back to the pagetrees of which that source is a member. Seems like you could do a hybrid approach where parts of the pagetree are dynamically generated from reading meta fields in source files? I did a similar thing in Beautiful Racket where most of the main pagetree is generated from directory listings of certain subfolders, but any source prefixed with `~` is ignored. This allowed me to rearrange things in the filesystem without having to repeatedly update the pagetree. > outside of Pollen’s remit as an environment for creating Books. Let the authors decide :metal:

Labels Milestones

get-doc and get-metas don't work with ptree files #159