xwiki-devs July 2008

xwiki-devs@xwiki.org

54 participants
180 discussions

[xwiki-devs] [DEMO] Class/Object management improvement + editors refactoring

by Pascal Voitot

Hello guys, I'm back with my classes and objects... After some work in the middle of my other projects, I have finally something to propose to you. Now you can disable/remove properties and synchronize objects and I have refactored the class/object editor. I have launched a demo environment so that you can test the result of my study. Go to: http://feebrox.dyndns.org:8888/xwiki/ Everything is explained there... What do you think about this? You can disagree with everything and even with my graphical choices ;) best regards Pascal

16 years, 3 months

[xwiki-devs] Currikdevs

by Joshua Marks

Thank you Ludovic for making the Curriki-devs mailing list: http://lists.xwiki.org/mailman/listinfo/curriki-devs To join out project discussions, please sign-up. Joshua Marks CTO Curriki: The Global Education and Learning Community jmarks(a)curriki.org www.curriki.org US 831-685-3511

16 years, 3 months

[xwiki-devs] Debugging XWiki - xwiki-core

by Markus Lanthaler

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

16 years, 3 months

[xwiki-devs] [proposal] Named Queries in QueryManager

by Artem Melentyev

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

16 years, 3 months

[xwiki-devs] Debugging XWiki - xwiki-core

by Markus Lanthaler

16 years, 3 months

[xwiki-devs] [GSOC] CBDF application

by Miguel Bento

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.

16 years, 3 months

[xwiki-devs] [GSOC] [WEBDAV] Issue running the prototype

by Ludovic Dubost

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

16 years, 3 months

[xwiki-devs] [GSOC][WEBDAV] Need a complete refactoring of code.

by Asiri Rathnayake

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

16 years, 3 months

[xwiki-devs] [Office Import] Mid Term Review and todos

by Vincent Massol

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

16 years, 3 months

Re: [xwiki-devs] syntax coloring problem Fixed

by malaka ekanayake

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

16 years, 4 months

← Newer
1
...
10
11
12
13
14
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs July 2008