Hi devs.
I almost completed implementation of QueryManager (see
http://markmail.org/message/l3zlqq4kqndokkif )
I think we should use named queries in core whenever possible, because
it reduce code size and independent from query languages. It is also
best practice in db world.
I would like to discuss about:
How we should store/load named queries?
1. Hibernate
Named queries in hibernate usually stored in mapping files. (see
http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#obj…
)
I think we should use this way too.
So I propose to add queries.hbm.xml - special hibernate mapping for queries.
Here is example:
{code}
<hibernate-mapping>
<query name="getSpaceDocsName">
select distinct doc.name from XWikiDocument doc where doc.space=:space
</query>
...
{/code}
2. JCR
Analogue for named queries in JCR is queries stored in special jcr
nodes. So queries stored *inside* repository. Queries are content.
But there is a problem how to initialize them at startup:
2.1) We can use standard import feature of JCR and import queries from
xml file at startup.
-: import needed for all workspaces (all virtual xwiki)
-: increase time of startup
-: slightly verbose xml file (<testquery jcr:primaryType="nt:query"
jcr:language="xpath" jcr:statement="//*"/>)
+: potentially faster quering.
2.2) Or we can don't use queries as nodes feature of JCR and store/load
queries by self for example in standard java.util.ResorceBundle (for
example jcr/Queries.properties).
+: simple, universal, independent.
There is another way: use ResourceBundles for both Hibernate and JCR.
But I think we should use Hibernate's way for named queries.
There is no standard way for init named queries in JCR except import.
But import has much disadvantages. So I'd like to use ResourceBundle for
jcr named queries.
So, in short, I propose:
add Queries.hbm.xml for hibernate named queries.
add jcr/Queries.properties for jcr named queries. (xpath)
WDYT?
--
Artem Melentyev
Hi,
I'm currently trying to debug XWiki with Eclipse. I set up everything as
explained in
http://dev.xwiki.org/xwiki/bin/view/Community/DebugXEWithEclipse and
everything runs fine. Also debugging works, but my problem is that the
downloaded xwiki-core JAR is used instead of my xwiki-core project in my
Eclipse workspace. If I attach the the xwiki-core project as the source to
that JAR (Eclipse asks me for that) the lines don't correspond if I set a
breakpoint and try to step through the program.
I set my xwiki-core project as a J2EE module dependency and also as project
dependency of my xe-debug-web project.
Any ideas what goes wrong?
Thanks a lot,
Markus
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
Hi devs,
I've been working on the Collaborative Business Drawing Framework API and
integration with the xwiki and have a small demo of my current work:
http://carmarket.gotdns.com:8090/xwiki/bin/view/Main/CBDF
Known bugs:
- When in select mode, if you click on another object, the transform
points became appearing out of place
- When you execute bring to front, the object stays in front of the
transform points
I'm sure it has more bugs, and i hope you guys help me finding them :)
Small regard on the user experience:
- To do the last point of a polyline use double-click instead of click.
- To edit a object property you have to select it first!
The bugs listed are easily solved, except in the case of the transform
points out of place, but it's a Tatami's bug and i found i workaround so
after my exam i'll solve them and hopefully continue developing.If you want
to have a look at my messy source code, its located at
https://svn.xwiki.org/svnroot/sandbox/xwiki-product-cbdf/
All kinds of comments are appreciated, enjoy your drawing!
Best Regards,
Miguel Bento.
I've followed the instructions on the readme and try to connect to
http://localhost:8080/xwiki-webdav/root/
When I try to launch the wiki using a web browser I get this error:
http://127.0.0.1:8080/xwiki-webdav/
or
http://localhost:8080/xwiki-webdav/bin/view/Main/
Caused by:
java.lang.ClassCastException: org.apache.maven.plugin.MavenPluginDiscoverer
at
org.codehaus.plexus.component.discovery.DefaultComponentDiscovererManager.initialize(DefaultComponentDiscovererManager.java:94)
at
org.codehaus.plexus.container.initialization.InitializeComponentDiscovererManagerPhase.initializeCoreComponent(InitializeComponentDiscovererManagerPhase.java:36)
at
org.codehaus.plexus.container.initialization.AbstractCoreComponentInitializationPhase.execute(AbstractCoreComponentInitializationPhase.java:37)
at
org.codehaus.plexus.DefaultPlexusContainer.initializePhases(DefaultPlexusContainer.java:914)
at
org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:858)
at
org.codehaus.plexus.DefaultPlexusContainer.construct(DefaultPlexusContainer.java:834)
at
org.codehaus.plexus.DefaultPlexusContainer.(DefaultPlexusContainer.java:204)
at
com.xpn.xwiki.plugin.webdav.XWikiDavServlet.getComponentManager(XWikiDavServlet.java:279)
--
Ludovic Dubost
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hi Ludovic,
I have added PUT / MKCOL support for xwiki-webdav but MKCOL support is
limited at this point. Users can add spaces, pages (into spaces), edit /
write changes into pages. But i've hit a wall trying to implement
prent-child relationships (adding child pages).
At this point i have to emphasize that we need to refactor our code base
before moving any further, because XWikiDavResourceImpl is really huge and
it's complexity drives me nuts at some points (sooo many if-else switches).
At a first glance i see following class structure,
DavResource
|
+ - XWikiDavResource (abstract)
|
+ - XWikiRootDavResource (for views)
|
+ - XWikiSpaceDavResource
|
+ - XWikiPageDavResource
|
+ - XWikiAttachmentDavResource
I've almost hit a dead-end with the current code base (because i was trying
to stick with it) and i seriously believe we have to refactor.
I can complete this refactoring within a week's time so that it won't affect
my time line.
Ludovic, what so you think ?
If any of you have comments about the design i propose, please let me know.
Thanks.
- Asiri
Hi Wang,
I haven't run your code yet but I've looked at it and I wanted to send
you a quick review before the end of the midterm.
* General comment: good work! This is promising. Now we need to work
on making it generate xwiki syntax and in making the XHTML parser work
fine. I'd expect your help on this now that you've done the basic work
for the rest.
* Please use the following issue to notify about your progress from
now on: http://jira.xwiki.org/jira/browse/XSANDBOX-32. Also whenever
you do a commit you should now refer to this issue in your commit
comment.
* Some comments on OfficeImporter interface
public interface OfficeImporter
{
/**
* convert the inputStream which contain the office document to a
outputStream which contain the result html code
*
* @param inputStream
* @param inputfileExtension the extension of source content
* @param outputStream
* @param outputfileExtension the extension of target content
*/
void convert(InputStream inputStream, String inputfileExtension,
OutputStream outputStream,
String outputfileExtension);
a) The javadoc should be improved. I had to look at the source code to
understand the meaning of inputfileExtension... which doesn't look
like a file extension at all :)
I think it's a file type rather than an extension. Thus I suggest to
create an OfficeDocumentType enum class to list all supported file
types and use that enum for input and output file types.
b) Also I think the output stream should be returned instead of being
passed as a parameter. It would also be more homogeneous with the
byte[] convert() method which returns the results as an array of bytes.
c) Since it's an importer the method should be named import(). However
I think it's a converter more than an importer so I'd rather you
rename it to OfficeConverter. WDYT?
* OfficeImporterFactory. What is this required for?
* We need to discuss on the list about how to best integrate your work
in XE. This includes discussing the needs for an application or a
macro (I'm not sure they are required and in any case should be left
for later IMO).
* ImporterServerConnectionFactory. IMO should be renamed to
OfficeServerConnection and should be implemented as a Plexus component
(singleton).
* OfficeImporterImp should also be implemented as a Plexus component
and should extend AbstractLogEnabled.
* OfficeImporterImp: what is this method used for: convert2HTML? It
doesn't seem to be used. Same for convert2PDF. They are also not in
the interface so I'm not sure what they are for.
* Need better exception handling. You need to create a
OfficeConverterException exception IMO.
* We're using dom4j and not jdom in xwiki so I think it would be
better if you could use it instead of jdom. WDYT? (unless there's a
good reason of course :))
* I think it would be better to transform your Util class into a set
of Filters. Basically the idea would be to implement a Filter chain
that would be executed against the generated XHTML and before passing
the XHTML to the XWiki XHTML parser. You would implement them as
components and have one Filter component per filtering needed (one for
removing PinLi, one for transforming the images elements, etc).
* BTW I need to check but it's possible that you don't need to
transform the img elements into {image} macros since this might be
done by the XHTML parser automatically. Same for removing the HTML,
HEAD or BODY elements.
* Note that xwiki has some util method for creating temporary
directories so you shouldn't create them yourself with:
// create the new temp folder
String oriTempDir = System.getProperty("java.io.tmpdir");
File tempFile = new File(new File(oriTempDir),
"xwikiOfficeImportTemp");
if (!tempFile.exists()) {
tempFile.mkdirs();
}
System.setProperty("java.io.tmpdir",
tempFile.getAbsolutePath());
* The build doesn't work right now. It's missing some artifacts in
maven remote repositories. We need to work on making it even more
simpler to use.
* The tests should be improved (better tests, no try catch, etc).
Could you send an email on the list asking for feedback from xwiki
committers for defining the integration points for this office
converter feature?
Thanks
-Vincent
Hi Fabio/Venkatesh,
I have committed my work to the svn.I have fixed the problem of syntax
colouring.
At the present code there are only 5 partition types including the
default.At present both List and text enhancements(bold,italic ...) are
taken as default partition type.But I think text enhancements and list
should be taken as different partitions.Also Headings should belong to
another partition.
Shall I do the above changes next ?
WDUT
On Fri, Jul 11, 2008 at 9:46 AM, malaka ekanayake <
malaka.ekanayake(a)gmail.com> wrote:
> Hi Fabio/Venkatesh,
>
> I have fixed the syntax coloring problem in the org.xwiki.eclipse.ui
> plugin :D.
> As far as I can understand was the partitioning of the document.As I
> suspected the class which suppose to do the partitionning in the
> org.xwiki.eclipse.ui plugin won't execute .In the standalone plugin written
> by venketesh works fine because in that,those code are executed through a
> extention point.So I move that code inside to the PageDocumentProvider's
> createDocument which provide the document.
>
> I have also remove some classes which are not used in the new code.
>
> But My ADSL connection is still down.So I'm sending the modified code as a
> attachment.Peace look at it and let me know that my fix is correct or not.I
> will commit the code ASAP
>
> cheers
> -- Malaka Ekanayake
> CSE UOM
--
Malaka Ekanayake
CSE UOM
Hello,
I'm trying to build XWiki but some tests are not passing. They are related
to rendering, apparently an expected line feed is not being printed. Take a
look at one of the errors:
junit.framework.ComparisonFailure: expected:<beginDocument[
onMacro: [testsimplemacro] [param1=value1|param2=value2] [
content
]
endDocument
]
> but was:<beginDocument[
onMacro: [testsimplemacro] [param1=value1|param2=value2] [
content
]
endDocument]
>
This has been happening since yesterday, so I'd like to know if it's really
happening to everybody or if I did something stupid here.
I am indeed trying to change one of XWiki's macros, the GraphViz one, I'm
adding some functionalities to it - allowing it to use more features that
GraphViz provides. But I really don't see how the code I did would break
this rendering mechanism, I don't render anything there except the GraphViz
stuff.
--
Tiago Rinck Caveden
http://caveden.multiply.com
Hi guys!
Here is my problem:
I have a function that xwiki.myplugin.showdata(command, visualtype)
but I need the username and password in the function to show the data.
The easy way would be to make it possible to insert username and password
"xwiki.myplugin.showdata(command, visualtype, username, password)"
but that wouldn't be safe because if anyone edited the page they would see
the users password. What I would like to do is be able to in the function
showdata() access the information I need: username and password.
Can anyone help out?
--
View this message in context: http://www.nabble.com/Username-And-Password-session-variables-tp18405471p18…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
I have created the PhotoAlbumClassTemplate in new space called "My Space",
so in template file i have include the form as
#includeForm("UPM Subscriber Demo.PhotoAlbumClassSheet") - no issue till
now.
Now, if i try to add new Photo album then below url get submitted
* URL : *//<myserver>/xwiki/bin/inline/This
Space/NewAlbum?parent=Photos.WebHome&template=This+Space.PhotoAlbumClassTemplate&sheet=1&webname=This+Space&name=NewAlbum
Due to empty space ("My Space" - between My and Space ), Add photo album
page get loaded without inline form
Thanks in advance
Hi David and Ludovic,
I have finished implementing distributed search for XWiki using the existing
plugin "lucene".
In short what the new code does. (on each individual installation)
1. As soon is XWiki is started, lucene plugin is initiated, during the
process of initialization, the machine makes is index remote available.
2. A Parallel searcher is created over all the remotely available indexes,
during the initialization of lucene plugin.
These 2 steps will achieve a simple distributed search. But Index updates
would not be reflected.
3. As and when there is an index update, index reader which was made
remotely available earlier in step 1 is re-opened and is made remotely
available.
With this Index updates on remote machines are reflected in search process.
But what if one the machines go down during the process ??
4. When ever there is an error while performing distributed search, the
parallel searcher in step 2 is redefined, i.e instead of searching 'n'
machines (earlier) it will search only 'n-m' machines.
At some point the machines went down will be started again. How to search on
these machines again?
5. A thread keeps on checking if searcher is set to search over all the
slaves defined in xwiki.cfg or not . If it is not searching on all the
slaves, It will try to redefine the searcher in step 2 as did in step 4.
6. I have modified existing XWiki.Results to make compatible to both
distributed/normal search.
7. Modified xwiki.cfg.vm, to have fews options for distributed search.
I have tested this on a cluster of 5 machines and it is working fine.
In addition to distributed search I have also attempted to fix 2
bugs/issues in earlier implementation of lucene.
a. Fix Lucene plugin scoring algorithm --
*XPLUCENE-8<http://jira.xwiki.org/jira/browse/XPLUCENE-8>
*b. Remove duplicates from Lucene search results --
*XPLUCENE-5<http://jira.xwiki.org/jira/browse/XPLUCENE-5>
*All these changes exist in the modified version of lucene plugin.
*Cannot commit the source code :
*I was trying to commit the source code to
https://svn.xwiki.org/svnroot/sandbox/plugins/lucene, but I couldn't
This is what I did,
1. svn co
https://pvsaikrishna@svn.xwiki.org/svnroot/sandbox/plugins/~/xwiki-sandbox-…
2. svn export lucene ~/xwiki-sandbox-plugins
3. cd ~/xwiki-sandbox-plugins
4. svn add lucene
5. svn commit --username pvsaikrishna -m 'distributed search using lucene'
*I got the following error*
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/sandbox/!svn/act/e5cbc51c-1643-4805-9019-0ce92d036d2b': 500
Internal Server Error (https://svn.xwiki.org)
--Sai Krishna
Hi!
I'm currently adding OpenID authentication support to XWiki but I'm
experiencing some problems with the current architecture.
First of all the current architecture doesn't support multiple
authenticators simultaneously (at least I didn't find how). I wanted to add
OpenID as an additional (optional) authentication method as shown in my
proposal at http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn. This is
not possible with the current design - at least not in an elegant manner.
Should I add OpenID so that it is always shown if the MyFormAuthenticator is
used? Or should I think about how we could make XWiki more flexible?
I can't implement the whole XWikiAuthService interface because OpenID
doesn't use passwords. This could cause problems. Should we change that
interface or create a new one for authentication methods that rely only on
XWikiContext?
I need a mechanism to handle the response of the OpenID provider (at a known
URL). What's the best approach for that? Using an action, a servlet, ...? I
need to parse and evaluate the response and depending on return to the login
form showing an error message or logging in the user and forwarding it to
the requested resource.
Thanks,
Markus
Hi xwikiers,
I'm reopening the old thread at http://markmail.org/message/qnfqvdaxyt46hdll.
Now that the problem related at
http://markmail.org/message/5hola4gk5mvcggq3 is "fixed" I propose to
revote for it.
So to summarize the goal is to provide an more clear extension to
exported wiki pages. To be completed, this means :
- modify the core packager plugin to add extension to pages (I think
we should make it configurable in xwiki.cfg and maybe in
XWikiPreferences)
- rename the files in subversion server
Here is my +1 (and +1 for making the extension configurable).
WDYT ?
--
Thomas Mortagne
Hi,
I have developed the basic prototype for Wysiwyg editor for creating
Presentation Applications in Xwiki.
You can test the editor at http://www.arpitjain.com/xwiki/editor.html
The features that are available right now are:
1.) Basic text editing features : Bold/Italic underline
2.) Indentation
3.) Bullets
4.) Support for colors/images/links is in progress and not complete. (You
might see a popup for insering colors/images/link, but it is not working
fine)
5.) Tables (TODO)
*Right now, there are two type of slide templates : *
1.) Title or Cover slides
2.) Regular bulleted list slides
Each template has fields that you can click on. When the field is undefined
it shows an explanatory text, e.g. click to add title. This disappears when
you click on it and restores if you move elsewhere without having typed, or
if you delete what you wrote before. This is working fine in IE but not in
Firefox. (Event handlers are not working on dom node elements in Firefox,
any help ??)
*In a bulleted list item(in Regular slides), first Enter starts a paragraph.
The second Enter starts the next bullet. To indent or outdent a list item as
a whole, you click on the appropriate button or press tab or shift + tab.
*
You can read more about it and other keypress events at
http://arpitjain.com/xwiki/design-notes.html
You can insert new slides, but transition between slides is not available
right now and I am working on it. Once this is complete, I would work on
saving the slides by AJAX and then creating layouts/themes for them.
I have tested the features in Firefox(2 and 3) and IE. It should work fine
in Safari also as standard workarounds have been taken care of, though I am
not sure.
@Jerome: It is now working fine for Firefox 2 and Flock in Debian.
Please let me know, if you find some issues in other browsers.
Thanks
--
Arpit Jain
Senior Undergraduate Student
Department of Computer Science & Engineering
Indian Institute of Technology, Kharagpur, India.
Web: http://www.arpitjain.com
PickensPlan:
Michael "Ollie" Oliver has invited you to join PickensPlan
--------------------
Energy Plan. Don't you think it is at least worth a look?
Check out PickensPlan:
http://push.pickensplan.com/?xgi=8PYl4lu
If your email program doesn't recognize the web address above as an active link,
please copy and paste it into your web browser
--------------------
Members already on PickensPlan
Bill Broadhead, Rob Meyer, Chris Bushnell, Bob, Heather
--------------------
About PickensPlan...
19127 members
401 photos
35 videos
743 discussions
12 events
90 blog posts
--------------------
To control which emails you receive on the corner, or to opt-out, go to:
http://push.pickensplan.com/profiles/profile/emailSettings
Hi,
I want to print the page creator in the panel.
And i have used the following code:
#panelheader($doc.web)
#foreach($subdoc in $xwiki.getSpaceDocsName("$doc.web"))
#set($web = $doc.web)
#set($page = $subdoc)
#set($document = "$web.$page")
$document.getCreator()
#end
#panelfooter()
but it seems not working.
--
Prathap
Hi David and Ludovic,
I have finished implementing distributed search for XWiki using the existing
plugin "lucene".
In short what the new code does. (on each individual installation)
1. As soon is XWiki is started, lucene plugin is initiated, during the
process of initialization, the machine makes is index remote available.
2. A Parallel searcher is created over all the remotely available indexes,
during the initialization of lucene plugin.
These 2 steps will achieve a simple distributed search. But Index updates
would not be reflected.
3. As and when there is an index update, index reader which was made
remotely available earlier in step 1 is re-opened and is made remotely
available.
With this Index updates on remote machines are reflected in search process.
But what if one the machines go down during the process ??
4. When ever there is an error while performing distributed search, the
parallel searcher in step 2 is redefined, i.e instead of searching 'n'
machines (earlier) it will search only 'n-m' machines.
At some point the machines went down will be started again. How to search on
these machines again?
5. A thread keeps on checking if searcher is set to search over all the
slaves defined in xwiki.cfg or not . If it is not searching on all the
slaves, It will try to redefine the searcher in step 2 as did in step 4.
6. I have modified existing XWiki.Results to make compatible to both
distributed/normal search.
7. Modified xwiki.cfg.vm, to have fews options for distributed search.
I have tested this on a cluster of 5 machines and it is working fine.
In addition to distributed search I have also attempted to fix 2
bugs/issues in earlier implementation of lucene.
a. Fix Lucene plugin scoring algorithm --
*XPLUCENE-8<http://jira.xwiki.org/jira/browse/XPLUCENE-8>
*b. Remove duplicates from Lucene search results --
*XPLUCENE-5<http://jira.xwiki.org/jira/browse/XPLUCENE-5>
*All these changes exist in the modified version of lucene plugin.
*Cannot commit the source code :
*I was trying to commit the source code to
https://svn.xwiki.org/svnroot/sandbox/plugins/lucene, but I couldn't
This is what I did,
1. svn co https://pvsaikrishna@svn.xwiki.org/svnroot/sandbox/plugins/~/xwiki-sandbox-…
2. svn export lucene ~/xwiki-sandbox-plugins
3. cd ~/xwiki-sandbox-plugins
4. svn add lucene
5. svn commit --username pvsaikrishna -m 'distributed search using lucene'
*I got the following error*
svn: Commit failed (details follow):
svn: MKACTIVITY of
'/svnroot/sandbox/!svn/act/e5cbc51c-1643-4805-9019-0ce92d036d2b': 500
Internal Server Error (https://svn.xwiki.org)
--Sai Krishna
Hi,
Does anyone know why we have the following LANG property defined in
our startup scripts:
#!/bin/sh
export LANG=fr_FR.ISO8859-1
JETTY_HOME=.
JETTY_PORT=8080
JAVA_OPTS=-Xmx300m
java $JAVA_OPTS -Dfile.encoding=iso-8859-1 -Djetty.port=$JETTY_PORT -
Djetty.home=$JETTY_HOME -jar $JETTY_HOME/start.jar
I think this is bad as it's french and I don't think we should set it
for the user.
That said, if it's there its probably because it was required in the
past, hence my question here.
To summarize: anyone sees any issue if I remove that "export LANG" line?
Thanks
-Vincent
The XWiki development team is pleased to announce the release of XWiki
Watch 1.0 RC 2.
Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download#HXWikiWatch !
This is the second and hopefully the last release candidate for the 1.0
version. It fixes several bugs, notably the ones regarding skin and
browser compatibility. The final release is planned for the next week.
Changes from 1.0RC1:
* Inconsistencies caused by feed renaming are now all fixed
(XWATCH-122, XWATCH-158, XWATCH-175, XWATCH-173)
* XWiki Watch is now fully compatible with the toucan skin (XWATCH-113)
* Performance has been improved and bugs have been fixed for uniform
usage across browsers (XWATCH-161, XWATCH-167, XWATCH-172)
* Various bug fixes and improvements: (XWATCH-143, XWATCH-170,
XWATCH-171)
For more information see the Release notes at:
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWatch10RC2
Thanks
-The XWiki dev team
I'd like to bring forward the release dates for XE 1.5 final, as follows:
* 1.5RC1 - 07/07
* 1.5Final - 15/07
I'd also like to create a branch for 1.5 since it's now in RC stage
and trunk will become 1.6-SNAPSHOT so that committers eager to work on
1.6 can start doing so and so that we're not tempted to push non bug
changes in 1.5.
Reasons:
* Some of us would like to work on 1.6 (like Jerome who'd like to fix
our captcha mechanisms)
* There's an ongoing vote to drop the 1.3 branch, as usual we'd have 2
branches with 1.4 and 1.5 (our standard rule is to support 2
versions).
Here's my +1 to both the new dates and the branch creation.
Thanks,
JV.
First release candidate of the XWiki Enterprise 1.5 version.
Main changes:
* Updated french translation
* Updated spanish translation
* LDAP authenticator no longer creates a local user if it exists at
the global level
* Mail sender plugin now supports SMTP authentication
* Arguments passed to radeox macros like {image} or {attach} are not
rendered anymore
* UTF-8 characters are now all correctly rendered in PDF exports
* Statistics database mapping working well under oracle
For more details about this 1.5 Release Candidate 1 release, see :
http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWikiEnterprise15RC1
Thanks
-The XWiki dev team
Hi vincent
Now I'm working on the costume implementation of the IDocument Partitioner
which uses the XDOM parser.
But in order to to register partitions with the IDocument,requires the
offset and the length of each token returned by the parser.
But the current implementation of the parser don't have that information.Do
I need to look at that issuer as well or what?
I have very little understanding of the implementation of the parser and I
will be difficult for me to implement that functionality.
Vincent can you help me on this issuer.
-- Malaka Ekanayake
CSE UOM
Hi,
I have created a new group in the space, then i have added a new user, while
creating a new user
i need that user to be moved in the newly created group by default. Already
the users are adding in the
XWikiAllGroup (Default group in xwiki).
Is there any document to do this...?
--
Prathap