Hi devs,
I'm currently doing some experiments about the wiki explorer and I've
started to play with smartGWT.
My initial plan was to use the new REST APIs to populate the wiki
explorer tree, the root node would have called /rest/wikis, wiki nodes
would have called /rest/wikis/WIKI/spaces, and so on. Unfortunately it
is currently impossible to use multiple sources (REST in our case) to
populate smartGWT TreeGrid, there are experiments in the field but
this is not yet supported [1]. Note that using a single DataSource
works like a charm but as far as I understand it is not designed to
lazily load bunch of items after bunch of items from the server (they
are lazily parsed/rendered though), in our case it means that we'd
have to build a huge XML file describing all the resources in the
wikis to feed the wiki explorer; of course this is not an option.
Here are the options I'm currently evaluating:
1) Continue with smart(client/GWT) and extend smartGWT TreeGrid to be
able to use multiple DataSource (if doable).
2) Develop a dynamic tree on top of GWT Tree widget and:
a) use the GWT XWikiService to populate the tree (need new methods,
doesn't take advantage of REST operations).
b) use restlet GWT REST client [2] to populate the tree from our
REST services.
c) use sonatype GWT REST client [3] to populate the tree from our
REST services.
[1]: http://forums.smartclient.com/showthread.php?t=3181
[2]: http://wiki.restlet.org/docs_1.1/13-restlet/144-restlet.html
[3]: http://svn.sonatype.org/nexus/trunk/sandbox/nexus-gwt-ui/sonatype-gwt-rest/
Thanks,
JV.
Arvind Gupta (arvind.bernaulli(a)gmail.com) wants to share their location
with you on Google Latitude. You need to sign in to Latitude with a Google
Account (eg @googlemail.com) and invite Arvind Gupta. To get started, or to
learn more about Latitude, click the link below.
http://m.google.com/latitude
(c) 2009 Google Inc., 1600 Amphitheathre Parkway, Mountain View, CA, USA.
Terms of Service | Privacy Policy
Maybe we could move to RC3?
-Vincent
Begin forwarded message:
> From: Guillaume Laforge <glaforge(a)gmail.com>
> Date: February 9, 2009 2:54:57 PM CEST
> To: Groovy User <user(a)groovy.codehaus.org>, dev <dev(a)groovy.codehaus.org
> >, announce(a)groovy.codehaus.org, Grails Users <user(a)grails.codehaus.org
> >, Gant_Users <user(a)gant.codehaus.org>
> Subject: [ossgtp] Groovy 1.6-RC-3 is released,
> Reply-To: ossgtp(a)yahoogroups.com
>
> Hi all,
>
> A quick message to tell you we've just released our third release
> candidate for Groovy 1.6.
>
> Hopefully this will be the last one, unless we uncover anything
> critical.
> But that's where YOU can help, by testing this RC thouroughly and
> report anything odd you may find.
> Thanks in advance for your help.
>
> You can download Groovy 1.6-RC-3 at the usual place:
> http://groovy.codehaus.org/Download
>
> You can see the list of JIRA issues fixed since the last RC here:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10242&fi…
>
> The Jars will soon hit the Maven repositories -- but are already
> available on the Codehaus repository.
>
> Big thanks to all the developers and contributors for your hard work!
>
> --
> Guillaume Laforge
In numerous places in the XE1.8m2 interface, the user is exposed to more
information than is necessary, when virtualhosting (
http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization ) is
enabled.
The current virtualhosting implementation seems to assume a shared farm of
wikis where one may want to expose other wikis in the farm. However, one
may also want to use virtualhosting in implementations where there is no
sharing between virtual hosts.
So for example, we have:
(1) the column 'Wiki' in Main.SpaceIndex ( e.g.
http://nielsmayer.com/xwiki/bin/view/Main/SpaceIndex?space=Main ) as well as
Main.WebSearch (e.g.
http://nielsmayer.com/xwiki/bin/view/Main/WebSearch?text=fedora&x=0&y=0 ) --
shows "host_xe_nielsmayer_dot_com" but it doesn't really need to. (should be
optional).
(2) in the wysiwyg editor's "link editor" ... there's an option-menu "Choose
a wiki: " that
exposes the names of all the wikis, and all their database names. (should be
optional: if "standalone" default to current wiki).
For these, and potentially other cases, I think this behavior should be
optional, not default. Most virtual wiki setups would not want their wikis
to "see" each other, IMHO. This includes a fairly common scenario -- the
private/public wiki setup -- people inserting links via wysiwyg in the
public wiki shouldn't see all the link-names and spaces in the private wiki.
Likewise, the notion of global and local users having potential access to
the wiki should be based on whether the virtual-wiki setup is "shared" or
"standalone."
Finally, exposing the database name of the virtual-wiki (to all search
engines as well) is a small, but unecessary security risk. In #2, for
example, the link editor allows people to see the database names of *all*
the virtual hosts. Also, if one ends up choosing unsightly but descriptive
names like host_xe_nielsmayer_dot_com, users shouldn't need to see it.
Niels
http://nielsmayer.com
Hello,
I would greatly appreciate a little clarification
clarification on the following two points regarding objects.
1. In current wiki page if I access an object attached to
a different page and then sets it's value, how do I save the property
values programmatically? Apparently the new property values appear in
the object view of the corresponding page but a database search does
not show the new values unless I manually save the page (to which the
object is attached).
2. In current wiki page I created a couple of objects and
then set the property values. $doc.save saves the objects but
seemingly has some interesting limitations. Number of property values
it can save is limited. Say for example: if I have 12 properties and
their values set, $doc.save works say, for example, after 6 of those
property values are set. If I put $doc.save after one additional
obj.set statement it gives error. I also found $doc.save to be
dependent on string length of the property values. If string lengths
are small it can save , for example, 13 properties. In such cases,
again, manual save works fine (although I want to avoid that).
A solution/workaround with a little code example will be
greatly appreciated.....
Thanks
Hi,
I need to create a page that lists all of the pages in the wiki with a
keyword in its title.
For example: List all pages with the phrase 'Class_' in the title.
It is important it is only the title that is searched - the body of the
pages may contain lots of mentions of 'Class_' but we don't want those
returned
I found threads that almost answer this but none that get me 100% of the
way so... How do I do this?
Many thanks,
Scott
____
This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful.
Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy.
Any views expressed in this message are those of the sender.
Dear devs,
I propose we bundle the "validation as you type" livevalidation.js
library [1] in XWiki, and use it to improve user experience on several
forms in XWiki Enterprise (I can think of registration form, export wiki
form, page creation panel, etc.) There are several advantages I see in
livevalidation compared to the other libraries I took a glance at :
* It's small (12Kb minified)
* It does not have any dependency (but there is version based on
prototype available, too)
* It is not intrusive. No need to modify the html structure or to add
css classes to input fields to add validation.
* It has an nice feature which allows you to precise the delay after
which the validation should occur once the user stopped typing
If you want to see it "live" in XWiki, I added some basic presence,
password confirm and email validation on the register form on
http://incubator.myxwiki.org
CSS-class based validation seems to be in some sort of fashion, though
I'm personally not very convince we can express all our validation using
only class names (sounds intricate to do cross-field validation for
example, or to validate against a custom regular expression), and for us
it is not really an option right now, since we would need to make
modifications in the core of XWiki for object fields displayer to add
the proper class names to the inputs when calling APIs like $doc.display
(or do it in javascript, but the CSS-based becomes pointless then).
Last, if we really want class based validation, I believe building it
with prototype and livevalidation would be very easy.
Here are the other alternative I looked at rapidly:
* JS-Validate [2] 67 Kb, requires prototype + scriptaculous, CSS-based ,
licence?
* really-easy-field-validation [3] requires prototype, CSS + JS based,
MIT licence
* wForms [4] 81Kb minified, CSS-based , LGPL
Better alternatives you would see?
Otherwise, my +1 for livevalidation,
Regards,
Jerome.
[1] http://www.livevalidation.com/
[2] http://www.jsvalidate.com/
[3] http://tetlaw.id.au/view/javascript/really-easy-field-validation
[4] http://code.google.com/p/wforms/
Hi dev,
We decided that spaces are meaningfull in XWiki 2.0 syntax with some
exception for lisibilities issue for lists and headers.
With embedded documents, the need for this appear for almost all
standalone blocks (tables, macros, etc.).
For example in:
* list item 1 (((
| cell1 | cell2
)))
* list item 2
the table will not be recognized because of the spaces before the "|"
that make the parser think it's a "|" in a paragraph and not a table.
We could add another exception for tables lke lists and header but I
would prefer to define a rule about all kind of standalone blocks.
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi all,
I have a growing interest on XWiki and willing to take part in its
development. I am also planning to apply for GSoC 2009 (yet to be announced)
and I have realised that XWiki is a challenging and promising open source
project for GSoC 2009.
When watching the developer list, I found this mail by Niels Mayer with the
subject,* "Social Networking via OpenID support in Xwiki?"*. And It looks
like an intersting idea. I also found that there was a GSoC 2008 project
related to this idea [1]. So is it possible to continue this project further
?
Other than the above idea, I would like to know the other possible project
ideas for GSoC 2009. If it is too early I am posting about this, then lets
leave it for the next couple of weeks. Anyway I am trying to get
familiarized with Xwiki until the GSoC 2009 is announced.
Thanks in advance.
best regards,
/ thilina
[1] -
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SSOAndOpenIDSupport