Hi Henry, Thanks a lot for this detailed answer!
Le 28/12/2014 09:43, Henry Saginor a écrit :
Hi Sylvain, I hope I understand what you are trying to do. But here is what I would suggest.
Sorry if I wasn't clear. No specific plans actually beyond setting up a blog engine, and maybe replace my aging Drupal install with Sling :-)
1) Think about how you are going to structure your blog content ahead of time. I would suggest something like /content/blog/year/month/post/comments. This way your archive script does not need to query the repository but will simply know how to construct a path to a specific year (and month).
Got it. No need to query since archive would just consist in listing the children of the year and month nodes. And year/months with no posts would simply be absent in the hierarchy. Neat!
2) You could use a Sling URL selector for the year (example: /content/archives.2014.html where /content/archives has sling:resourceType = “blog/year-archive”). Sling provides API for getting URL selectors from request. This way /etc/map stuff is not needed. But either way your script will still have to extract the year from request. I don’t see any way around this. The selector based approach is an alternative to your /etc/map bridge if you don’t like it. But, actually, selectors seem to be less intuitive for end users in this case. You could also use suffixes (i.e. /content/archives.html/2014).
The problem with suffixes IMHO is that it leads to unusual URLs (I would even say "not nice"): even if nothing formally mandates it, we're used to having the extension as the very last element a URL path. So the mapping bridge seem to be the way to go here.
3) I would not actually store content with any particular markup. Just use default JCR backed Resource implementation and think of a blog post in terms of JCR nodes/properties (or resources/properties if you prefer higher level of abstraction :)). You should have a resource type like /apps/blog/post with scripts for rendering different markups if you want. Alternatively you could have just html rendering script (html.esp ?) and use Sling rewriter pipeline (http://sling.apache.org/site/output-rewriting-pipelines-orgapacheslingrewriter.html) to generate other markups. A resource like /content/blog/year/month/post should have sling:resourceType = “blog/post”. You don’t need an observation listener that generates and stores different markups. It’s also quite a bit of extra content you don’t need to store if you render markup when it’s requested.
Hmm... I think I wasn't clear. The different markups are for document authoring, not rendering. I have a long archive of blog posts written in HTML, but these days I prefer using lightweight languages like markdown and asciidoc. These need to be converted to html to be rendered.
A solution would be to add this conversion in the rendering script, but it doesn't feel "right" to put this logic inside the rendering layer. This why I thought of having an authoring area that would store content in its original format (html, asciidoc or markdown) and have an observer that converts this content to html and stores it in the publishing area under /content/blog/<year>/<month>/<post>
4) You also don’t need separate authoring and publish areas if you structure posts content as I suggested. All new posts should be created under /content/blog/currentYear/currentMonth/ anyway. This is both your blog’s authoring and publish/archive area. A basic implementation of an authoring script can be just an HTML form that does a POST to sling repository using default Sling Post Servlet - http://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html. You have a lot of control over how you structure content via this mechanism.
The Post Servlet is indeed quite powerful, but still doesn't solve the conversion to html problem :-) Or I could implement the conversion on the client side, but it sounds rather fragile. And would also prevent using what I consider a killer feature of Sling (or JCR actually): the ability to mount the repository via WebDAV, allowing me to use my favorite text editor to write blog posts rather than having to build an authoring webapp.
I hope this helps.
It does! What do you think of the input format to html conversion problem? Thanks, Sylvain -- Sylvain Wallez - http://bluxte.net
