[xwiki-devs] Blog Plugin Proposal
Now that the Blog Upgrade to 2.0 wiki syntax comes soon to a close I want to focus on the improving its performance and ease of use. As suggested beforehand I think creating a Blog Plugin would probably the best way to accomplish that. For that I would suggest that all methods in "Code" documents in the blog (BlogCode2, CategoryCode and if needed RssCode) become part of that plugin. Beside that I am also wondering if that plugin should become part of the Core (xwiki-core) like the Feed Plugin or a regular plugin like the Scheduler Plugin which I think would be the best. Cheers Andreas Schaefer
Hi Andreas, On Aug 15, 2009, at 2:24 AM, Andreas Schaefer wrote:
Now that the Blog Upgrade to 2.0 wiki syntax comes soon to a close I want to focus on the improving its performance and ease of use. As suggested beforehand I think creating a Blog Plugin would probably the best way to accomplish that.
For that I would suggest that all methods in "Code" documents in the blog (BlogCode2, CategoryCode and if needed RssCode) become part of that plugin.
I'd also love this to happen (I even suggested it in the past too). But there are some issues to resolve first: 1) the java classes should be APIs and not have UI-specific things in them IMO. They should be a toolbox that can be used in various scenarios. 2) we have to understand that it makes it harder to modify the blog so we'll still need some BlogCode page to offer some flexibility and do some UI outputing 3) the blog is an application and an optional one. It should not go into xwiki-core. We'd package it with XE by default though. 4) it'll be harder for users to install/upgrade the blog application since they'll need to install both a plugin + a XAR. And in addition there's a possibility they'll use a plugin version incompatible with a XAR version. It'll also cause problems for the first upgrade since users will need to not forget to modify their xwiki.cfg file (and they will forget for sure, hence the blog app will need to display some nice message if the plugin is not there). We could also introduce some internal version to ensure they are in sync or compatible. 5) we should use the (new) component-based architecture instead of plugins as much as possible since plugins are the old way of doing things. However it's possible that for this need it would be difficult to use components since our Document Access Bridge component would miss methods. This is to be checked. The biggest issues for me are 4) and 5). 1) needs to be careful done so that only pure data independent of UI gets out of the API but provided it's done it's ok. The solution to 4 is the famous Application Manager that we need to finish designing and implement (see http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationManager ). It won't be ready before 6 months at best IMO. 5) needs to be evaluated in term of API needs but it could be written as an old style plugin for now. Basically I'm fine to do it provided we are very careful with 4). Let see what others think. Thanks -Vincent
Beside that I am also wondering if that plugin should become part of the Core (xwiki-core) like the Feed Plugin or a regular plugin like the Scheduler Plugin which I think would be the best.
Cheers
Andreas Schaefer
Hi Vincent On Aug 15, 2009, at 1:11 AM, Vincent Massol wrote:
But there are some issues to resolve first:
1) the java classes should be APIs and not have UI-specific things in them IMO. They should be a toolbox that can be used in various scenarios.
My life blog needs around 9 to 10 seconds to render the Blog.WebHome page and it seems like a it chunk of that time is uses to retrieve and built the blog content. I do understand what you want but I am also concerned of the speed of the blog and so maybe it would be great to provide both.
2) we have to understand that it makes it harder to modify the blog so we'll still need some BlogCode page to offer some flexibility and do some UI outputing
For now I just took the Blog.BlogCode and converted it into the Blog Plugin. When everything is working I am going to test the speed and if there is enough gain I am going to create a second plugin which would contain the default blog UI. This way anyone can use Velocity to create their own Blog UI but if someone just takes what is provided then we might get a performance boost.
3) the blog is an application and an optional one. It should not go into xwiki-core. We'd package it with XE by default though.
I already create a Blog Plugin project.
4) it'll be harder for users to install/upgrade the blog application since they'll need to install both a plugin + a XAR. And in addition there's a possibility they'll use a plugin version incompatible with a XAR version. It'll also cause problems for the first upgrade since users will need to not forget to modify their xwiki.cfg file (and they will forget for sure, hence the blog app will need to display some nice message if the plugin is not there). We could also introduce some internal version to ensure they are in sync or compatible.
I will create a message page for that and add some checks when the plugin is loaded.
5) we should use the (new) component-based architecture instead of plugins as much as possible since plugins are the old way of doing things. However it's possible that for this need it would be difficult to use components since our Document Access Bridge component would miss methods. This is to be checked.
I guess for now I just go the old way. So far it was difficult enough to get my head wrapped around. Currently I have a prototype of the Blog Plugin deployed but there are many loose ends. Cheers - Andy
I'll be posting a few little things as minor bugs on jira unless anyone suggests otherwise. 1. postgres jdbc-8.4 (latest) is incompatible. changing the version given in platform/pom/pom.xml makes it (apparently) work okay. 2. Document.getChildren() skips pages which give the parent as wiki:docname This is an arcane method of linking but it works, I think it should be fully supported or should not work at all. 3. Object GUIDs are changed on document rename.
My try to deploy the Blog Plugin together with the updated Blog Application failed miserably today and my dislike of Velocity reach a new high. Because I see the value of the scripting nature of the Blog allowing users to customize their Blog to a quite large degree I don't want to ditch that but I have a lot of problems with Velocity and the way is plastering over issues. I rather fail fast than late with hardly a trail to understand what is going on. That said I still think that it might be a good idea to convert the scripted part of the Blog over to Groovy and keep the rest in the Blog Plugin. I don't have any experience with Groovy inside XWiki but for sure the documentation of Groovy outside is excellent compared to Velocity. I will use the next week to get up to speed and try to convert a piece of the Blog over to Groovy. Cheers - Andy
Andreas Schaefer wrote:
Now that the Blog Upgrade to 2.0 wiki syntax comes soon to a close I want to focus on the improving its performance and ease of use. As suggested beforehand I think creating a Blog Plugin would probably the best way to accomplish that.
For that I would suggest that all methods in "Code" documents in the blog (BlogCode2, CategoryCode and if needed RssCode) become part of that plugin.
Beside that I am also wondering if that plugin should become part of the Core (xwiki-core) like the Feed Plugin or a regular plugin like the Scheduler Plugin which I think would be the best.
I for one don't like this that much. It takes away the ability to edit the application inside the wiki (which is not a very big problem, since users should be satisfied with the existing functionality), but also the ability to easily study its code, which prevents learning. I like that in XWiki users are free to see, study, and change the code of applications, and I wouldn't like to loose that. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (4)
-
Andreas Schaefer -
Caleb James DeLisle -
Sergiu Dumitriu -
Vincent Massol