Hi,
This is following the proposal done here some time ago:
http://markmail.org/message/nnybto3mluvp2rov
Since we now have a generic Script notion we need to revisit it in
that light. Also we really need to implement it now since more and
more components are put in the velocity context (office importer,
syntax factory, etc) and we need to bring some order.
Here's a new generic proposal:
Short term
========
* The variable "services" is bound in the script context. For ex in
Velocity: $services
* The Services object (ScriptServiceManager) has a ScriptService
get(String serviceName) method which returns the service
* We use the namespace: services.<module name>.<method>. Each module
provides only one service entry point.
* ScriptService interface (empty interface) represents a service to
be bound in the context
* ScriptServiceManager.get() looks for all components of role
ScriptService and returns the component matching the the name as the
component hint.
Ex:
@Component("mymodule")
public class MyModuleScriptService implements ScriptService,
MyModuleBusinessInterface
{
public void myMethod() {}
}
In script:
{{velocity}}
$services.mymodule.myMethod
{{/velocity}}
Medium term
==========
* We handle @authorization(Authorization.PROGRAMMING) annotations to
check for access rights. To do this in ScriptServiceManager.get() we
use a Dynamic Proxy to implement MyModuleBusinessInterface (we
probably need a ScriptService.getInterface() method to make it
unambiguous). The Dynamic Proxy checks the annotation before proxying
to the real object.
WDYT?
Thanks
-Vincent
PS: This is to answer Sergiu's question about where is
getAvailableParserSyntaxes() from my other mail... ;) Answer: It would
be in RenderingScriptService.
Hi devs,
We need to define a strategy for better handling translations. I've
had a call with Guillaume and Jean-Vincent and here's the process we'd
like to propose:
* One person is in charge of http://l10n.xwiki.org/. This means
monitoring the work there, coordinating validation of key values and
ensuring validated translations are incorporated in the source tree.
Guillaume is willing to take that role for now.
* The XE release manager has the responsibility of taking the
validated keys on l10n.xwiki.org and committing them during the
Milestone 2 dev (before the RC1).
* The l10n manager should ping the release manager whenever there are
translated and validated keys ready to be incorporated or if there
have been important changes to be included in the release after M2 has
been released.
* The l10n manager should test XE and the applications after the keys
have been applied to ensure quality. Basically the l10n manager is
responsible for the quality of translations in general.
Here's my +1
Thanks
-Vincent
Hi devs,
We need to decide what to do with html macro content (or any other
RawBlock content) in plain text renderer.
For me the rule of plain text renderer should be to print anything we
are able to print which mean printing any pure text content and skip
styles for which obviously we don't have syntax. RawBlock content is
pure text so we should print it.
Note that first version of plain text renderer was printing html
content and it was lost when introducing RawBlock.
Here is my +1 for printing RawBlock content in plain text renderer.
WDYT ?
--
Thomas Mortagne
Hello,
I am working on creating blog entries using xwiki. I was wondering if it would be possible to create a template for the blog entries so that they will be more structured?
Thank you for your time and help!
Hande Aksac
Hi,
Since I'm rewriting the new Rendering component
(see http://dev.xwiki.org/xwiki/bin/view/Design/NewRenderingArchitecture)
, we need to finalize the new syntax we want to have.
Right now I'v planned to use the same wiki syntax as now
(http://platform.xwiki.org/xwiki/bin/view/Main/
XWikiSyntax#HTextStyles) with only one change: all macros now need to
be closed.
For example: {macro}...{/macro} and {macro:text|param=value|.../}
Is that ok with everyone or do we want to make changes?
Thanks
-Vincent
Hello XWiki developers,
can someone explain me what is the strategy to define the mime-type of
an attachment?
I see not configurable map nor any setter on the attachment types.
Is there any way I can enrich this or is it simply taking over the
mime-type provided the browser (which, too often, ends up being
application/octet-stream) ?
thanks in advance
paul
Hi Devs,
right now an user can go to the Office Importer page and try uploading a
file even when the backend OOo server isn't running. This leads to usability
issues. Thus I'd like to send a vote on the following 2 items:
- On the Office Importer page, add the following message:
-
"You cannot import an Office document since the conversion
server has not been started. Please ask an administrator to get it
started for you."
-
If the current user is an admin, the message should read: "You
cannot import an Office document since the OpenOffice server has not
been started yet. You can start the OpenOffice server and manage it
from this page (link to the OOo server administration page)."
-
In the action bar: add a check to see whether the OOo server is
running and don't display the link if the OOo server is not.
Here's my +1 to both.
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Hi Andreas,
On Mon, Aug 31, 2009 at 1:11 AM, Andreas Schaefer <schaefera(a)me.com> 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. 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 ;-)
> Cheers - Andy
>
Good luck and thanks for all the nice work,
Guillaume
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/