First of all, hi again!
I'm developing the collaborative business drawing framework to integrate on
XWiki and currently need some feedback.
In order to provide the abillity of drawing SVG/VML/Canvas objects in the
browser, this framework has many options that i shall explain:
*
A) Tatami, the GWT wrapper of the Dojo Toolkit library (
http://code.google.com/p/tatami/)*
This is by far the most used option, and the reasons are somewhat obvious.
- It wraps up the dojo toolkit code for GWT providing access to the GFX
package's functionalities and thus giving us the possibility to draw objects
in SVG/VML/Canvas. This is a very important point as it provides support for
Safari with canvas objects and IE with VML objects, accomplishing thus a
better product.
- Provides the creation of basic and advanced drawing figures from
squares to paths with drag and drop, scale, rotate and parameters
specification.
- It has the biggest active developer's base, having a lot of activity on
their forum (http://groups.google.com/group/tatami)
- It gives us efficiency and usability by being well developed.
Personally, this is a key point for me as i've seen a lot of svg drawing
boards slow and badly done.
A demo of the tatami can be found here (
http://tatami.googlecode.com/svn/trunk/site/samples/TatamiDemo/index.html )
but don't mind the slow reaction of the site as it's using aloot of dojo
objects(Fisheye, etc) and it's runing from the svn. After some coding with
it, i realized it can indeed be very fast.
IMHO, this looks like the winner.. we should use this wrapper for the job
and if necessary develop some new items on it to provide us the required
functionalities, which will also be needed in any other option.
*B) JSGraphic's library (
http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm)
*As it's the case with Dojo Toolkit, this library can be used in GWT by
including a wrapper on the project. The downsides of this alternative are
obvious as, for example, it doesn't support's drag and drop or any
interaction with the objects and is a one man project.
It's allways good to have options heh!
*C) Develop an API fit to the job*
As this option might bring some (? small) benefits in efficiency and
additional funcionalities, on the other hand, it's slowed by the time
required to develop the API knowing that there are some fully functional
good options out there.
Talking about functionalities, Tatami provides every svg object and property
that i remind me of and it's efficiency and usability are high, so there
shouldn't be much more to do in this area. (besides implementating screw
transformations, which aren't included in the latest realease of Tatami :)
In the next days i'll be building a propotype of a drawing API so please
give me your opinions.
My vote : +1 Tatami
Best Regards,
Miguel Bento.
Hi guys,
I'm just downloading the 1.5M2 release to test your new administration GUI.
The speed is currently 30KB/s....
I've a 100Mbit/s dedicated server located in Germany (Hoster: Hetzner). I
can spend, let's say 100GB/month at full speed, would that help?
Cheers,
Squirrel
PS: Will you sometime publish some statistics on this topic?
Hi,
I'd like to propose removing core 1.3 from Continuum. It's taking
resources and the build even fails.
Then I'd also like to propose removing branch 1.3 for Core/Web/XE since:
* We're no longer supporting it here.
* Apparently according to Ludovic it has some problems.
If someone needs to release a new 1.3.3 one day he can always take the
1.3.3 tag and branch it.
Here's my +1
Thanks
-Vincent
On Thu, Jun 26, 2008 at 7:00 PM, Evelina Slatineanu
<evelina.slatineanu(a)xwiki.com> wrote:
> Hi all,
>
>
>
> For the new Administration application to work properly in an empty wiki
> (create users, groups, set rights etc), the following files have to be moved
> from XE to Administration:
>
>
>
> Xwiki.Admin
>
> Xwiki.Users
>
> Xwiki.XwikiUserSheet
>
> Xwiki.XWikiUserTemplate
>
> Xwiki.AdminGroup
>
> Xwiki.AllGroup
>
> Xwiki.Groups
>
> Xwiki.XwikiGroupSheet
>
> Xwiki.XwikiGroupTemplate
>
> Xwiki.Rights
>
> Xwiki.GlobalRights
>
> Xwiki.DefaultSkin
>
> Xwiki.Skins
>
> Xwiki.XwikiPreferences
-1 for XWiki.XWikiPreferences at least the one from XE which contains
rights configuration in it.
Plus admin should be able to automatically create the
XWiki.XWikiPreferences page when needed.
>
>
>
> I already sent the patch to JV, we only need votes. I'm +1
>
>
>
> Thanks, Evelina
>
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
Hi,
In order to fix issue http://jira.xwiki.org/jira/browse/XWIKI-1325
(Renaming a web page only updates backlinks in one language version)
we need to store the language in the XWikiLink object/table.
One solution then it modify XWikiHibernateStore from List
loadBacklinks() which just return doc names to List<XWikiLink>
loadBacklinks().
I have it almost done here but I wanted to ask you what you think.
Another solution (but might be too complex for now) would be to
include the language in doc full name by inventing a new syntax.
For example: "wiki:Space.doc:language"
In this case there's no change required to XWikiLink object/DB, nor
for the loadBacklinks() method. The change is either in the code that
calls getBackLinks() or in XWiki.getDocument(documentName) so that
documentName supports language.
WDYT?
Thanks
-Vincent
Hi!
I just created the page
http://dev.xwiki.org/xwiki/bin/view/Design/SingleSignOn where I'll document
everything regarding my Single Sign-On project.
Since I didn't get any feedback the last time I asked this question I'll ask
it again:
Another question. Just looking at OpenID now. What are the plans for it?
Should it be enabled by default? Should it be possible to turn it off?
I would like to see OpenID support out of the box. I don't know if it makes
sense to turn it off.. What happens with existing OpenID users if someone
turns it off?
Should we really start with the integration of a big framework like OpenSSO?
Wouldn't it be better to implement OpenID support for example with a
dedicated OpenID
library? We should also consider the fact that ESOE for example simple uses
the OpenID4Java library and OpenSSO doesn't support OpenID (authentication)
at all.
I think it's much easier for the user if everything is bundled with XWiki so
that he doesn't need to install any other component or complex service like
ESOE or OpenSSO.
If it's OK for you I would start creating the architecture and describe
detailed how I would like to implement OpenID support with a OpenID library
the next days. Then ask for some feedback on that and finally begin to
implement this. My last exam is next Monday (July, 7th) so afterwards I'm
finally free to work exclusively for XWiki :-)
Cheers,
Markus
Hi devs,
Finally, i've had the time to put up a small demo of the drawing API using
Tatami(http://tatami.googlecode.com), i would like to commit it to the
sandbox, but in order to do that i need write permitions for the user
mjbento.
Now, regarding the demo, i've only implemented the basic objects and object
operations. Right now it's more of a case show of the Tatami performance
than the real deal, because, in order to do that it would have to be ported
into a API with all the functionalities implemented.
User tip: After you finish the drawing of an object, the Select tool is
automatically selected. In order to move the objects, simply click them in
Select mode.
So, finally, please check it out if you have some time, I would really
apreciate some feedback on this.
Best regards,
Miguel Bento.
I was trying to figure out how to dynamically create a panel so I was looking
at create.vm
shown here:
#if($tocreate=="panel")
#set($docname=$title.replaceAll("/", "%2F"))
#if(!$template || $template == "")
#set($template="Panels.PanelTemplate")
#end
#set($newdoc=$xwiki.getDocument($docname))
#if($newdoc.isNew())
#set($pcontent = "#")
#set($pcontent =
$pcontent.concat("panelheader('${title}')${xwiki.getNl()}${xwiki.getNl()}#"))
#set($pcontent = $pcontent.concat("panelfooter()"))
#set($pcontent = $util.encodeURL($pcontent))
$response.sendRedirect($newdoc.getURL("inline",
"template=${template}&Panels.PanelClass_0_name=${title}&Panels.PanelClass_0_content=$pcontent"))
#else
$response.sendRedirect($newdoc.getURL("view",
"xpage=docalreadyexists"))
#end #end
.
.
and I quickly got lost. It looks like you first create a document from in
panels space something like
XWikiDocument doc = context.getWiki().getDocument("XWiki.MyPanell",
context);
Then it looks like $pcontent concatenates some calls to velocity macros
together. Then it looks like it is url encoded so it can be passed as http
response. Then I am completely lost with the sendRedirect statement. Does
it redirect to process the templates and then return the response?
Is there a better example for me to look at or perhaps someone generous
enough to provide me with even more help? You guys have been very generous
with help and I would like to Thank you! BTW congratulations on the "Big
News"
Glenn Everitt
--
View this message in context: http://www.nabble.com/How-can-I-dynamically-create-a-panel--tp16406339p1640…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
How to change the "Redirects to the Main.WebHome" to some other page.
Need to change in the web.xml file.
<welcome-file-list>
<welcome-file>*SpaceName/PageName*</welcome-file>
</welcome-file-list>
--
Prathap
Hi list,
I am trying to use the addAttachment call to add an attachment to a page via
xmlrpc.
So far I have used groovy and python (code further down), both give me the
same error message:
xmlrpclib.Fault: <Fault 0: 'No method matching arguments: java.lang.String,
java.lang.String, java.util.HashMap, [B'>
After digging into the src I found addAttachment in:
XWikiXmlRpcClient.java (part of -core)
/**
* Add a new attachment.
*
* @param contentId Ignored. (It is here because the Confluence API signature declares it)
* @param attachment The Attachment object describing the attachment.
* @param attachmentData The actual attachment data.
* @return An Attachment object describing the newly added attachment.
* @throws XmlRpcException
* @category ConfluenceAPI
*/
public Attachment addAttachment(Integer contentId, Attachment attachment,
byte[] attachmentData) throws XmlRpcException
{
Object object =
invokeRpc("addAttachment", token, contentId, attachment.toMap(), attachmentData);
return (Attachment) new Attachment((Map<String, Object>) object);
}
As you can see contentId is defined as Integer not String. When using an integer
in the rpc call I get this error message:
xmlrpclib.Fault: <Fault 0: 'Failed to invoke method addAttachment in class
com.xpn.xwiki.xmlrpc.XWikiXmlRpcHandler: An XWiki id must be in the form
Space.Page[?param=value¶m=value&...]'>
When looking at the server log I can see:
Caused by:
java.lang.IllegalArgumentException: An XWiki id must be in the form
Space.Page[?param=value¶m=value&...]
at org.xwiki.xmlrpc.model.XWikiExtendedId.<init>(XWikiExtendedId.java:37)
at com.xpn.xwiki.xmlrpc.XWikiXmlRpcHandler.addAttachment(XWikiXmlRpcHandler.java:929)
...
And when looking at that method:
public XWikiExtendedId(String string)
{
if (string.indexOf(".") == -1) {
throw new IllegalArgumentException(
"An XWiki id must be in the form Space.Page[?param=value¶m=value&...]");
}
So question is, how do I actually add an attachment to a page?
Stefan
------ python -------8<----------------------
#!/usr/bin/python
import xmlrpclib
f = open('images/foo.jpg', 'rb') #Open file as a binary file
file = f.read()
data = xmlrpclib.Binary(file) #Make the byte array
server_url = 'http://localhost:8080/xwiki/xmlrpc/confluence';
s = xmlrpclib.Server(server_url);
token = s.confluence1.login('login', 'pass');
page_list = s.confluence1.getPages(token, 'MySpace') #Get the pages in the space
new_attachment = dict(id = '', pageId = '', title = '', fileName = 'filename', fileSize = '', contentType = 'content type', created = '', creator = '', url = '', comment = 'Some comment') #Make a attachment container
for page in page_list:
if page['title'] == 'AttachMe':
s.confluence1.addAttachment(token, page['id'], new_attachment, data)
------ python ------->8----------------------
------ groovy -------8<----------------------
import groovy.net.xmlrpc.XMLRPCServerProxy
import java.io.File
server = "localhost:8080";
username = "user";
password = "pass";
serverProxy = new XMLRPCServerProxy("http://${server}/xwiki/xmlrpc/confluence")
try {
println "Logging in...";
token = serverProxy.confluence1.login(username, password)
} catch (Exception e) {
println "Cannot login! Check username or password..."
throw e;
}
println "Logged in";
try {
def attach = [:];
# load file with PAGENAME<SPACE>IMAGETOATTACH per line
println "Loading image list";
new File("images.txt").eachLine { line ->
array = line.split(" ");
attach.put(array[0], array[1]);
attachment = [id : '', pageId : '', title : '', fileName : 'filename', fileSize : '', contentType : 'content type', created : '', creator : '', url : '', comment : 'Some comment'];
bytes = new File(array[1]).readBytes();
page = serverProxy.confluence1.getPage(token, "MySpace.${array[0]}");
serverProxy.confluence1.addAttachment(token, page.id, attachment, bytes);
}
} finally {
serverProxy.confluence1.logout(token);
}
------ groovy ------->8----------------------
regards
Stefan
--
I did it just to piss you off. :-P
-- Branden Robinson in a message to debian-devel