Re: [xwiki-devs] Blog Plugin Proposal
On Monday, August 31, 2009, at 12:46AM, "Vincent Massol" <[email protected]> wrote:
On Aug 31, 2009, at 9:28 AM, Guillaume Lerouge wrote:
Hi Andreas,
On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <[email protected]> wrote:
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.
My personal experience with velocity is more of a try & fail, try & fail, try and succeed one than anything else.
This is not really related to velocity which is the simplest language on earth. It's related to any language you type without an IDE to help you. Try using groovy in wiki pages you'll have the same problem (I know I have it, I need to preview 10 times to get something right).
That said, there are some velocity editing support in IntellilJ IDEA and I think there's also a plugin for Eclipse which might help. You can also use XEclipse which has syntax highlighting and some autocompletion for velocity (you'd need to use the 1.2RC1 version).
I can agree with that. Velocity might be the simplest language for you but for started I could not find a good Velocity language tutorial. Even though the support I get from IntelliJ is really helpful the strange syntax is making it difficult to code (return values through parameters for example) but the real difficulty comes from the fact that I cannot debug velocity in any efficient way but the real thing I cannot stand is the fact that Velocity just ignore any problems. This might be good for a simple web site but for an application like a blog this is not good in my view. At least with Groovy I have a fairly well defined language and some mailing lists that can help me with problems and it ensures that NPEs, undefined methods etc are handled.
What I found out is that I was msot of the time better off rewriting stuff starting with small chunks rather than trying to take existing code and reuse it all at once. The current blog is a fairly complex piece of velocity code (that is, given the lack of debugging tools when coding in velocity in the wiki). This is one of the reasons I think Sergiu's argument that "devs will be able to look at the code and learn from it" is not entirely true ;-)
What's really important for the blog is that it can be customized easily at 2 levels:
- Look: an user should be able to use the panels she wants for her blog - Deployment: an user should be able to create a new space blog or global wiki blog in any space she wants
Besides that the way the blog is code doesn't matter much for the end user.
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.
Then go ahead and give it a go :-)
One thing you need to be aware of when using Groovy inside the wiki is that your pages will haveto be saved using programming rights. This can cause a number of issues, don't forget to code with an user that has them, it will save yo ua lot of hassle ;-)
Yes and we might not be able to include it in the default distribution since our rule so far was only velocity in the default XE XAR.
I rather have a good, robust and reliable Blog application even if I would have to download it separately. But first I need to see how well a Blog in Groovy would work and what the limitations (like the programming rights) mean. To keep it easy I think I will start with implementing what we have in BlogSheet/BlogCode to just list the current entries in a blog. If I can then create a Blog Post Entry with Groovy I should pretty much be able to compare the two. Personally I am more interested to get the stuff going well for my own Blog but I am willing to go the extra mile to provide it to the community. Cheers - Andy
On Sep 1, 2009, at 1:08 AM, Andreas Schaefer wrote:
On Monday, August 31, 2009, at 12:46AM, "Vincent Massol" <[email protected]
wrote:
On Aug 31, 2009, at 9:28 AM, Guillaume Lerouge wrote:
Hi Andreas,
On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <[email protected]> wrote:
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.
My personal experience with velocity is more of a try & fail, try & fail, try and succeed one than anything else.
This is not really related to velocity which is the simplest language on earth. It's related to any language you type without an IDE to help you. Try using groovy in wiki pages you'll have the same problem (I know I have it, I need to preview 10 times to get something right).
That said, there are some velocity editing support in IntellilJ IDEA and I think there's also a plugin for Eclipse which might help. You can also use XEclipse which has syntax highlighting and some autocompletion for velocity (you'd need to use the 1.2RC1 version).
I can agree with that. Velocity might be the simplest language for you but for started I could not find a good Velocity language tutorial.
There are some good Velocity guides here: http://velocity.apache.org/engine/releases/velocity-1.6.2/user-guide.html http://velocity.apache.org/engine/releases/velocity-1.6.2/vtl-reference-guid... -Vincent
Even though the support I get from IntelliJ is really helpful the strange syntax is making it difficult to code (return values through parameters for example) but the real difficulty comes from the fact that I cannot debug velocity in any efficient way but the real thing I cannot stand is the fact that Velocity just ignore any problems. This might be good for a simple web site but for an application like a blog this is not good in my view. At least with Groovy I have a fairly well defined language and some mailing lists that can help me with problems and it ensures that NPEs, undefined methods etc are handled.
What I found out is that I was msot of the time better off rewriting stuff starting with small chunks rather than trying to take existing code and reuse it all at once. The current blog is a fairly complex piece of velocity code (that is, given the lack of debugging tools when coding in velocity in the wiki). This is one of the reasons I think Sergiu's argument that "devs will be able to look at the code and learn from it" is not entirely true ;-)
What's really important for the blog is that it can be customized easily at 2 levels:
- Look: an user should be able to use the panels she wants for her blog - Deployment: an user should be able to create a new space blog or global wiki blog in any space she wants
Besides that the way the blog is code doesn't matter much for the end user.
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.
Then go ahead and give it a go :-)
One thing you need to be aware of when using Groovy inside the wiki is that your pages will haveto be saved using programming rights. This can cause a number of issues, don't forget to code with an user that has them, it will save yo ua lot of hassle ;-)
Yes and we might not be able to include it in the default distribution since our rule so far was only velocity in the default XE XAR.
I rather have a good, robust and reliable Blog application even if I would have to download it separately. But first I need to see how well a Blog in Groovy would work and what the limitations (like the programming rights) mean. To keep it easy I think I will start with implementing what we have in BlogSheet/BlogCode to just list the current entries in a blog. If I can then create a Blog Post Entry with Groovy I should pretty much be able to compare the two. Personally I am more interested to get the stuff going well for my own Blog but I am willing to go the extra mile to provide it to the community.
Cheers - Andy
participants (2)
-
Andreas Schaefer -
Vincent Massol