15 Aug
2009
15 Aug
'09
2:24 a.m.
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
15 Aug
15 Aug
10:11 a.m.
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
19 Aug
19 Aug
1:07 a.m.
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
20 Aug
20 Aug
2:34 a.m.
New subject: [xwiki-devs] {platform} A few minor bugs
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.
31 Aug
31 Aug
1:11 a.m.
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
15 Aug
15 Aug
12:15 p.m.
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/
5624
days inactive
5639
days old
5 comments
4 participants
participants (4)
-
Andreas Schaefer -
Caleb James DeLisle -
Sergiu Dumitriu -
Vincent Massol