Open naholyr opened 11 years ago
I can't comment on the specifics (I just don't have that great an understanding) but I have developed a feeling that Punch's content processing is a bit limited and simplistic. Being able to stack handlers would help. As would being able to run helpers on content before handlers, rather than just in templates.
Most of the issues can be got around by writing custom content handlers but those are harder to re-use on different projects and you can't share with the wider community so easily.
The recommended way to have multiple content handlers is by using the delegation pattern. If you look at the blog-content-handler's code it's implemented this way (by delegating to default content handler when it cannot handle something).
I will write a better tutorial to make this more clear.
@adrinux I'm considering on the idea of making helpers accessible from content handler. Will do some experimentation on that.
Delegation can't be enough, it prevents building efficient third party content handlers. Let's take an example:
punch-blog-content-handler
.getPosts
for example).Maybe we could address this issue by providing a helper or snippet to allow configuring delegation (I could say in config.json that I want comments-content-handler to delegate to rss-content-handler instead of directly blog-content-handler, and it would be enough). But in the end, it will the same than providing an ordered list of handlers instead of a single one ;)
Well, actually I'll make my RSS generator a generator_hook, but the need still is here in my opinion. That's why I was wondering if there was a true limit or if there was some space for extra work ;)
I guess what we need here is a routes-content-handler
which can sit on the top and do the delegation based on the URL paths.
I'll try to make it to work during the weekend.
Oh yeah that could do the trick very nicely, perfect idea! Keep in touch :)
Just as another use for the content handler: I'm currently working on a content handler that, given a picasa album name in the original json expands that json by including urls to the images in that album. I can do this with the current delegation, however I don't think a routes-content-handler will help me here. Or should I be doing this in a completely different way?
Why can't delegation work here ? Your negotiateContent calls the original one, expands content, and run callback. Won't it work ? I agree though that I'm not fond of this principle because the notion of "base content handler" is very project-specific and if you want to share your plugin you will have to let user be able to configure it (dependance injection or module's name in configuration). Le 11 févr. 2013 23:53, "frankct310" notifications@github.com a écrit :
Just as another use for the content handler: I'm currently working on a content handler that, given a picasa album name in the original json expands that json by including urls to the images in that album. I can do this with the current delegation, however I don't think a routes-content-handler will help me here. Or should I be doing this in a completely different way?
— Reply to this email directly or view it on GitHubhttps://github.com/laktek/punch/issues/63#issuecomment-13408280.
Content delegation does work, but the routes-content-handler will not. I was hoping to provide some more input here with other use cases. Thanks for the input, though!
We can have many helpers, hooks, etc… but only one content handler, this makes it quite uneasy to append new content handlers above existing ones. For example in my case I use:
Maybe the
content_handler(s?)
option could be an array, and core would:I don't think this would be too hard to do. What do you think? Do you see major issues with this vision (before I start working on PR)?