Hi Devs,
Currently DocumentNames generated by DocumentNameFactory contains the fully
qualified document name at all times. And when they are serialized using
DocumentNameSerializer, they result in the fully qualified document name
string like "wiki:space.name".
The problem with this is that new xwiki components using
DocumentAccessBridge cannot use relative document names. For an example,
"parent" field of a document cannot be set w.r.t the current wiki because
the "wiki:" part is always appended by default (by the serializer). So we
need a mechanism to specify "what kind of document name" we mean (relative
or absolute).
We can achive this in many ways:
1. Allow pasing a Serializer into methods which takes in a DocumentName.
2. Allow associating a Serilizer with a DocumentName.
3. Use Execution as a means of passing the preferred Serializer
4. Use a flag inside DocumentName (ABSOLUTE, WIKI_RELATIVE, SPACE_RELATIVE)
which will be intepretted by the Serializer appropriately whenever a
DocumentName is serialized.
None of the above approaches are perfectly clean. But the fourth approach
seems to make more sense.
I'm +1 for 4.
Thanks.
- Asiri
Hi
Beside the technical issues which are resolved now the other main
reason why I did not adapt XWiki so far is the available Skins. So far
I am running the Wiki based on Mac OS X Server 10.5 Wiki which looks
very slick. You can see under:
http://blogs.madplanet.com/groups/mpc-staff/
or something hat looks like my blog:
http://blogs.madplanet.com/users/schaefa/
XWiki only provides 2 skins which I don't think are very appealing for
readers even though Toucan gets the job done for a writer. So I tried
to figure out how to change a skin but could not find a lot of help on
how to wrap my head around probably because I am a developer and look
to far and think to complicated.
So first I am wondering why aren't there any other skins available?
Application like Drupal, Joopla and other have many available.
In case I want to change the images (let's say making it look like the
ones I mentioned above) do I then need to copy a skin directory and
start to change the images? And if yes which skin should I use? I seem
that 'toucan' has less items and is more up to date but I that is just
a hunch.
Has someone used the XWiki Skin Editor?
Thanks
Andreas Schaefer
CEO of Madplanet.com Inc.
Email: andreas.schaefer(a)madplanet.com
schaefera(a)me.com
Twitter; andy_mpc
AIM: schaefera(a)me.com
Hi devs,
Currently the above method is implemented so as to set the absolute name of
the parent document as the parent name of a page. Assuming we don't support
inter-wiki parent-child relationships, I propose we should modify this
method not to include the "wiki:" prefix in the parent name because it
breaks the wysiwyg (not displaying parent-child relationships correctly).
Now I'm not exactly sure whether it is the wysiwyg or this method that needs
fixing, but the latter is easier to fix.
If we do decide to modify this method, should i simply use:
<code>
public void setParent(DocumentName parentName)
{
this.parent = parentName.getSpace() + "." + parentName.getPage();
}
</code>
Or should I use a custom DocumentNameSerializer?
Thanks a lot.
- Asiri
Hello,
I try to create a page in XWiki/2.0 generating some JSON data but I have
some problems and I have to go back to XWiki/1.0...
* when you write this in a page MySpace.MyPage:
[
{ "field" : "value" }
]
you call MySpace.MyPage?xpage=plain and you get some HTML code:
<p><br/>.{ "field" : "value"...<br/></p>
this is not good for the JSON parser...
* So I try using the verbatim {{{}}}
{{{
[
{ "field" : "value" }
]
}}}
and I call again MySpace.MyPage?xpage=plain and I get:
<pre>
[
{ "field" : "value" }
]
</pre>
Ok for the JSON data but the <pre></pre> is not good also for JSON parser...
* If I write some velocity inside:
{{velocity}}
#doit()
[
{ "field" : "${value}" }
]
{{/velocity}
I get some <!-- velocity-macros --> comments or something like that before
my json encoded into HTML...
not good for the JSON parser also...
What's the solution in XWiki/2.0 to make a page generate JSON?
For the time being, I use XWiki/1.0 but this is not a viable solution.
thanks
Pascal
On Jun 1, 2009, at 4:12 PM, Sergiu Dumitriu wrote:
> vmassol (SVN) wrote:
>> Author: vmassol
>> Date: 2009-06-01 10:49:54 +0200 (Mon, 01 Jun 2009)
>> New Revision: 20681
>>
>> Log:
>> XWIKI-3913: Add support for Component Manager events
>>
>> * TODO: Refactor localization module to use the refactored
>> Observation module
>> * TODO: Refactor Rendering API module by removing notion of Source
>> Macro Manager (rollback as before) and instead use Component
>> Manager events to register Macros dynamically.
>>
>> Added: platform/core/trunk/xwiki-component/xwiki-component-default/
>> src/main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-component/xwiki-component-default/src/
>> main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java (rev 0)
>> +++ platform/core/trunk/xwiki-component/xwiki-component-default/src/
>> main/java/org/xwiki/component/manager/
>> ComponentDescriptorAddedEvent.java 2009-06-01 08:49:54 UTC (rev
>> 20681)
>> + public boolean matches(Object otherEvent)
>> + {
>> + boolean result = false;
>> +
>> + if
>> (ComponentDescriptorAddedEvent
>> .class.isAssignableFrom(otherEvent.getClass())) {
>> + ComponentDescriptorAddedEvent event =
>> (ComponentDescriptorAddedEvent) otherEvent;
>
> I'd like to support a wildcard here, like a listener for all component
> registrations (if getRole == null, return true).
>
> Also, why is getRole.getName compared to simply getRole?
Fixed, thanks.
>> + if (getRole().getName().equals(event.getRole())) {
>> + result = true;
>> + }
>> + }
>>
>> Modified: platform/core/trunk/xwiki-containers/xwiki-container-
>> servlet/src/main/java/org/xwiki/container/servlet/
>> XWikiPlexusServletContextListener.java
>> ===================================================================
>> // This is a temporary bridge to allow non XWiki components
>> to lookup XWiki components.
>> - // We're putting the XWiki Component Manager instance in
>> the Servlet Context so that it's
>> - // available in the XWikiAction class which in turn puts
>> it into the XWikiContext instance.
>> - // Class that need to lookup then just need to get it from
>> the XWikiContext instance.
>> - // This is of course not necessary for XWiki components
>> since they just need to implement
>> - // the Composable interface to get access to the Component
>> Manager or better they simply
>> - // need to define the Components they require as field
>> members and configure the Plexus
>> - // deployment descriptors (components.xml) so that they
>> are automatically injected.
>> servletContextEvent.getServletContext().setAttribute(
>>
>> org.xwiki.component.manager.ComponentManager.class.getName(),
>> this.componentManager);
>> }
>
> Why did you remove this comment?
Because It wasn't valid any more:
- we're not using XWikiAction
- there's no components.xml
- the compnent manager is now injected.
I thought it wasn't necessary to explain all this here and that saying
it's a temporary bridge that allows non components to lookup
components is enough.
>> Modified: platform/core/trunk/xwiki-core/src/test/java/com/xpn/
>> xwiki/XWikiTest.java
>> ===================================================================
>> --- platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/
>> XWikiTest.java 2009-06-01 07:45:41 UTC (rev 20680)
>> +++ platform/core/trunk/xwiki-core/src/test/java/com/xpn/xwiki/
>> XWikiTest.java 2009-06-01 08:49:54 UTC (rev 20681)
>> @@ -20,6 +20,7 @@
>> package com.xpn.xwiki;
>
> A bit of duplication here:
Actually I think that a bit of duplication isn't bad in tests if it
makes the test simpler to read. That's what I thought there.
>> - TestSaveEventListener listener = new
>> TestSaveEventListener();
>> + Mock mockListener = mock(EventListener.class);
>> +
>> mockListener
>> .stubs().method("getName").will(returnValue("testlistener"));
>> +
>> mockListener
>> .expects
>> (once()).method("getEvents").will(returnValue(Arrays.asList(new
>> DocumentSaveEvent("xwikitest:Some.Document"))));
>> +
>> ObservationManager om = (ObservationManager)
>> getComponentManager().lookup(ObservationManager.class);
>> - om.addListener(new
>> DocumentSaveEvent("xwikitest:Some.Document"), listener);
>> + om.addListener((EventListener) mockListener.proxy());
>> Modified: platform/core/trunk/xwiki-observation/src/main/java/org/
>> xwiki/observation/internal/DefaultObservationManager.java
>> ===================================================================
>
>> + for (Event listenerEvent : regListener.events) {
>
> Why do you check the class also? match() should take care of this, and
> it prohibits event inheritance.
Fixed, thanks.
Thanks for the review!
-Vincent