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
Hi,
For network event distribution I need to be able to receive all events
(because it's not done by ObservationManager itself but by an external
module).
Currently ObservationManager only match events with the exact same
class so it's impossible to match all events or event several events
of same subject like documents event for example.
I don't have time to design a generic multievent matcher and a
redesign of the OM is already started for activity stream so for now I
propose to introduce a special AllEvent event ObservationManager will
trait as a particular case when returned by a listener (with lots of
comments of course).
WDYT ?
here is my +1
--
Thomas Mortagne