Hi devs,
Remote observation manager receive remote events and convert before
injecting it in a specific thread. For this to work properly as usual
the execution context need to be initialized for this thread.
Initialize ExecutionContext is pretty clean and component oriented but
we also need a stub XWikiContext initialized in the ExecutionContext.
I propose to implements a generic stib xwiki context initializer and
provider: the initializer react to ExecutionContextInitializer, when
receiving the first ExecutionContext initialization containing a
XWikiContext it call XWikiStubContextProvider.initialize to create a
XWiki context independent from the request but still containing
scheme/host/port information and when ExecutionContextInitializer is
called with a ExecutionContext which doe snot contains any
XWikiContext a clone of the stub XWikiContext is injected in the
Execution context.
To resume, it uses the first request generated XWikiContext to create
an XWikiContext independent form the request and use it to generate
default XWikiContext for thread not generated by the application
server when theses are initializing ExecutionContext.
WDYT ?
--
Thomas Mortagne
The idea is that if you have programming rights you should probably be
allowed to access components and possibly even register new components.
WDYT?
Thanks
-Vincent
Hi,
After discussing with thomas here's what we propose:
* remove the org.xwiki or com.xpn.xwiki part before the module name
* use <module>.<propertyName>. Ex: rendering.linkLabelFormat
* for submodules use <module>.<sunmodule>.<propertyName>. Ex:
rendering.macro.velocity.filter.
** Note1: the current property for the macro velocity filter is
wrongly named: macro.velocity.filter. That would need to be fixed at
some point.
** Note2: the configs in xwiki-rendering-xwiki module should be named
rendering.xwiki.linkLabelFormat. We'll need to fix this at some point
or rename that module to some other name. Or find a sub rule to handle
this case.
* use camelcase for the property name itself. ex: linkLabelFormat
Here's my +1
Thanks
-Vincent
Hi,
After a discussion with Thomas we'd like to propose the following
format for defining macro categories in xwiki.properties:
rendering.macroCategories = <macro id>=<cateogory name>
Ex:
rendering.macroCategories = toc:presentation
rendering.macroCategories = velocity=code
Internally the config will be available from RenderingConfiguration:
public interface RenderingConfiguration
{
/**
* A link label format is the format used to decide how to
display links that have no label.
* By default the page name is displayed. However it's possible
to customize it using the
* following tokens:
* <ul>
* <li><strong>%w</strong>: wiki name</li>
* <li><strong>%s</strong>: space name</li>
* <li><strong>%p</strong>: page name</li>
* <li><strong>%P</strong>: page name with spaces between camel
case words, i.e. "My Page"
* if the page name is "MyPage"</li>
* <li><strong>%t</strong>: page title</li>
* </ul>
* Note that if the page title is empty or not defined then it
defaults to %p. This is also the case
* if the title cannot be retrieved for the document.
*
* The default is "%p". Some examples: "%s.%p", "%w:%s.%p".
*
* @return the format to use to display link labels when the user
hasn't specified a label
*/
String getLinkLabelFormat();
/**
* @return the category names to use for the macros. These are
the categories under which they'll be listed
* in UIs for example. If a category for a macro is null
then the category defined in the macro
* descriptor (ie defined by the macro author) will be used
*/
Properties getMacroCategories();
WDYT?
If no negative comments are given I'd like to implement this ASAP.
Thanks
-Vincent
Sorry for being late with this message! The deadline for paper
submission is 10 August 2009, but only now I've regained access to the
nepomuk-kde list.
Greetings,
Ricardo
--
Ricardo Rodríguez
Your EPEC Network ICT Team
Hi All,
When working on officeimporter document splitting feature we wanted to make
it possible to provide hooks so that the whole import process can be
customized external to the officeimporter module via a groovy class (on a
wiki page). Since we were in a little hurry, the solution we devised might
be called "hackish"; we provided the following interface which can be
implemented in groovy:
<code>
public interface OfficeImporterFilter {
void filter(String documentName, Document document);
void filter(String documentName, XDOM xdom, boolean isSplit);
String filter(String documentName, String content, boolean isSplit);
void setDocBridge(DocumentAccessBridge docBridge);
}
</code>
Now, Officeimporter application would pass a parameter into
DefaultOfficeImporter indicating the wiki page which contains the groovy
filter implementation. Then we do something like:
<code>
String groovyFilterParam = params.get("groovyFilter");
String groovyScript = docBridge.getDocumentContent(groovyFilterParam);
GroovyClassLoader gcl = new GroovyClassLoader();
OfficeImporterFilter importerFilter =
(OfficeImporterFilter) gcl.parseClass(groovyScript).newInstance();
importerFilter.setDocBridge(docBridge);
return importerFilter;
}
</code>
The purpose of setDocBridge() method is to inject the DAB into the filter so
that it can access wiki documents. Now I question myself why it is not
possible for a groovy class to access wiki documents without the DAB. This
also proves that this solution was not well planned or discussed with the
community. Another problem with the filter interface is that it does several
things. It would have been better to have three filters instead.
Now to the topic of this email; if we can allow groovy code to implement
XWiki components (if it is possible), we can make this whole thing very
simple. For an example, officeimporter application would pass the role-hint
of the component implementing a particular filter (which is a groovy
implementation) and DefaultOfficeImporter will simply lookup this component
and use it.
As for implementing this kind of a mechanism, we can follow something
similar to what we did with wiki macros. A special class
XWiki.XWikiComponent would contain fields like componentRole (String),
roleHint (String) & groovyClass(TextArea) and when a document with an object
of XWiki.WikiComponent is saved, we can register a new component against the
CM.
This idea was suggested to me by vincent & I thought it's time to start a
discussion about this to see what others think. Although I have few unclear
points (like how dependency injection would work), I think it would be a
handy tool to have.
Thanks in advance for your comments & suggestions :)
- Asiri
PS: OfficeImporter code has been polluted a lot because I have stuffed a lot
of features into it without properly designing them. I will be refactoring
officeimporter a little by little in coming days (as time permits).
Hi,
I'm proposing to remove the TxManager. Reason:
* We need to offer a way for users of the rendering to control which
transformations are executed.
* It'll become clear to users of the rendering api how their XDOM will
be transformed. Right now they didn't even know they were running
macro transformation when they used the TxManager.
Here's my +1
Thanks
-Vincent