- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] StringProp and LargeStringProp lengths

by Jeremie BOUSQUET

Hello, Writing a Java component that creates new XWiki pages and objects, I'd like to properly check the data before saving it to avoid some not-nice-and-avoidable exceptions to occur. Seems that in XWiki mappings, a StringProperty is limited to 255 chars and a LargeStringProperty to 60000 But as it's a hibernate mapping (meaning it's customizable by users), and also as it can possibly change with future versions of XWiki, I'd like to know if there is an easy way to programmatically check for the maximum authorized length of these fields from a Java component ? I'd prefer truncating the strings before trying to save the documents (or not saving them at all) ... I had horrible times dealing with objects incorrectly created because of strings too long ... (did not check with recent xwiki though). Thanks, Jeremie

13 years, 3 months

2
2
0 0

Re: [xwiki-devs] Is there any document about how to extend the wysiwyg

by liujinlong5788

Hello . I write a plugin in "org.xwiki.gwt.wysiwyg.client.plugin " as what other plugins do , a plugin ,a pluginfactory, and execuable class. And I package it with maven ,copy the jar to lib , restart the tomcat ,but I can't find the plugin written by me. And I even copy the whole format plugin to another package ,and change the name of it ,it can't be loaded neither. I mean I can't find them neither in administrator wiki wysiwyg editor nor when I edit the document. So ,I wander is there anything else needed to do ? change the *.vm file or js file ? Thanks a lot for helpping .

13 years, 3 months

2
1
0 0

[xwiki-devs] [GSOC] SOLR Search component

by savitha sundaramurthy

Hi all, I have come up with some basic set of API's for Solr search component. I have made it generic such that it can use solr or lucene as the backend. I have also documented in the DEsign proposal. http://dev.xwiki.org/xwiki/bin/view/Design/SOLRSearchIntegration *getBackend* public String getBackend() *Returns:* Returns the name of the backend which is currently in use. It could be Lucene or Solr. *rebuildIndex* * * *public int rebuildIndex(com.xpn.xwiki.api.XWiki wiki, com.xpn.xwiki.api.Context context)* Starts the rebuild of the whole index *Parameters:* wiki context *Returns:* Number of documents scheduled for indexing. -1 in case of errors * * *getSearchResults* * * * * * * * * public searchResponse *getSearchResults*(java.lang.String query, java.lang.string languages, com.xpn.xwiki.api.XWiki wiki) Searches the configured Indexes using the specified query for documents in the given languages. With virtual wikis enabled in your xwiki installation this will deliver results from all virtuall wikis. *Parameters : * query - query string given by the user languages - comma separated list of language codes to search in, may be null to search all languages. Language codes can be: - default for content having no specific language information - lower case 2- letter language codes like en, es , fr. *Returns:* a searchResponse instance containing the results (i.e) the response objects. *getSearchResults* public searchResponse *getSearchResults*(java.lang.String query, java.lang.String virtualWikiNames java.lang.string languages, com.xpn.xwiki.api.XWiki wiki) Searches the configured Indexes using the specified query for documents in the given languages belonging to one of the given virtual wikis. *Parameters : * query - query string given by the user languages - comma separated list of language codes to search in, may be null to search all languages. Language codes can be: - default for content having no specific language information - lower case 2- letter language codes like en, es , fr. virtualWikiNames - Names of the virtual wikis to search in. May be null for global search. *Returns:* a searchResponse instance containing the results (i.e) the response objects. I'm not sure on whether to expose the startIndex as API *Admin Module:* * * I has some thoughts on API's for admin settings where one could check the precision and recall results based on some known documents and could tweak the boost values accordingly. Thanking you, Savitha.

13 years, 3 months

3
2
0 0

[xwiki-devs] [Proposal] Add variable substitution support in hibernate.cfg.xml for the "connection.url" property

by Vincent Massol

Hi devs, I need to be able to configuration the location of the HSQLDB database/ directory in our installer when executing on windows7 (because on windows7 you cannot write to the ProgramFiles directory). I'm proposing to add variable substitution so that we can configure connectio.url for HSQLDB to point to the environment.permanentDirectory location. We would have: <property name="connection.url">jdbc:hsqldb:file:${environment.permanentDirectory)/database/xwiki_db;shutdown=true</property> Technical details: * I'll modify DBCPConnectionProvider. More specifically this part: String jdbcUrl = System.getProperty(Environment.URL); if (jdbcUrl == null) { jdbcUrl = props.getProperty(Environment.URL); } dbcpProperties.put("url", jdbcUrl); * And look for ${…} , extract the variable name and use the XWikiPropertiesConfigurationSource to get the value for that variable name, as a String. WDYT? Thanks -Vincent

13 years, 3 months

5
16
0 0

[xwiki-devs] Is there any document about how to extend the wysiwyg editor?

by jinlong liu

Hello ,I want to add a button which is not contained in xwiki by default, on the toolbar of the wysiwyg editor ,I have read the java source of it ,and still have some problems .So I want to know is there any document about this , for the plugin contains so complex and unfamiliar class to me that I was puzzled(Of course ,most of the reason is that I am a newbie in programmes. ) .Thank you .

13 years, 3 months

2
1
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello Friends, Here is a new set of mockup. [] http://jssolichin.com/public/4/1.%20Home.png [] http://jssolichin.com/public/4/2.%20Home-comm.png [] http://jssolichin.com/public/4/3.%20Home-navhover.png [] http://jssolichin.com/public/4/4.%20mobile.png [] http://jssolichin.com/public/4/5.%20mobile-menu.png What do you guys think? The idea is that the sidebar would be replicated, but hidden in the mobile (except for the hint that it's there. Everything non-content is combined. I think that if you are looking at the comments/attachment/other sections, you are not thinking about navigating away from the page so the nav section is not that needed. So this consolidates/saves space. Let me know if this is the wrong mentality. Thanks! Jonathan Solichin

13 years, 3 months

3
3
0 0

[xwiki-devs] Fwd: [CVE-2012-2098] Apache Commons Compress and Apache Ant denial of service vulnerability

by Vincent Massol

Funny that this should arrive today in my inbox… ;) -Vincent Begin forwarded message: > From: Stefan Bodewig <bodewig(a)apache.org> > Subject: [CVE-2012-2098] Apache Commons Compress and Apache Ant denial of service vulnerability > Date: May 23, 2012 4:00:48 PM GMT+02:00 > To: dev(a)commons.apache.org, user(a)commons.apache.org, dev(a)ant.apache.org, user(a)ant.apache.org, announce(a)apache.org, security(a)apache.org, full-disclosure(a)lists.grok.org.uk, bugtraq(a)securityfocus.com, David Jorm <djorm(a)redhat.com> > > CVE-2012-2098: Apache Commons Compress and Apache Ant denial of service > vulnerability > > Severity: Low > > Vendor: > The Apache Software Foundation > > Versions Affected: > Apache Commons Compress 1.0 to 1.4 > Apache Ant 1.5 to 1.8.3 > > Description: > The bzip2 compressing streams in Apache Commons Compress and Apache Ant > internally use sorting algorithms with unacceptable worst-case > performance on very repetitive inputs. A specially crafted input to > Compress' BZip2CompressorOutputStream or Ant's <bzip2> task can be used > to make the process spend a very long time while using up all available > processing time effectively leading to a denial of service. > > Mitigation: > Commons Compress users should upgrade to 1.4.1 > Ant users should upgrade to 1.8.4 > > Credit: > This issue was discovered by David Jorm of the Red Hat Security Response > Team. > > References: > http://commons.apache.org/compress/security.html > http://ant.apache.org/security.html > > Stefan Bodewig

13 years, 3 months

2
1
0 0

[xwiki-devs] [VOTE] Stop bundling legacy .jar files in enterprise and manager.

by Caleb James DeLisle

Hi, I understand we agreed in http://lists.xwiki.org/pipermail/devs/2012-March/050172.html to stop bundling legacy modules by default. What was not so clear is how we should do this. I want to remove the modules from XE and Manager, and document the method of downloading them from maven.xwiki.org and replacing the existing .jar files with them. Why: #1. Not removing API is obviously unsustainable in the long term. #2. Replacing core .jar files has been judged to be beyond the scope of the extension manager. Whether we want to support overriding classes using extensions as a "function hooking" mechanism is a possible topic for future discussion. #3. Replacing .jar files in the .war is not an excessively complex task, we ask users to open the war file for configuring a database or adding JDBC connectors, cases where there is much less technical need to require opening the .war file. Here's my +1 to remove it ASAP, for 4.1M2 if we can get the tests passing. Caleb

13 years, 3 months

5
8
0 0

[xwiki-devs] Read-only DB and XWiki.getUserClass()

by Alexander Pokahr

Dear XWiki developers, the last couple of days I tried setting up two redundant XWiki servers using MySQL master/slave replication. Unfortunately MySQL replication produced errors, because the slave wiki also wrote on the DB. Thus, I revoked update privileges from the xwiki DB user on the slave. Now replication worked, but the slave XWiki failed to start and instead always threw an exception in XWiki.getUserClass(). Unlike mentioned in previous findings by others (http://lists.xwiki.org/pipermail/devs/2011-January/045992.html), currently XWiki seems to be unable to operate on a read-only DB. I think I tracked the issue to the following code in XWiki.getUserClass() (lines 3000ff, shown below). As you can see, the if block only operates on a local string builder, but does not change the page. Nevertheless, needsUpdate is set to true, thus forcing XWiki to save the document, which doesn't work on a read-only DB. This happens every time XWiki starts. // Email field custom display (email obfuscation). PropertyClass emailProperty = (PropertyClass) bclass.get("email"); if (!emailProperty.isCustomDisplayed(context)) { StringBuilder builder = new StringBuilder(); builder.append("{{velocity}}\n"); builder.append("#if ($xcontext.action == 'edit' || $xcontext.action == 'inline')\n"); // Line broken in 2 because it was too long. builder.append(" {{html}}<input id='$prefix$name' type='text'"); builder.append(" name='$prefix$name' value='$value' />{{/html}}\n"); builder.append("#else\n"); builder.append(" ## Allow $obfuscateEmail to be set in some other place.\n"); builder.append(" #if(\"$obfuscateEmail\" == 'false')\n"); builder.append(" $value\n"); builder.append(" #else\n"); builder.append(" $value.replaceAll('@.*', '@ xxxxxx')\n"); builder.append(" #end\n"); builder.append("#end\n"); builder.append("{{/velocity}}"); needsUpdate = true; } ... if (needsUpdate) { saveDocument(doc, context); } Without the 'needsUpdate = true;' the slave xwiki now starts fine and seems to work properly. Note, that i tried setting 'xwiki.readonly=yes' in xwiki.cfg as also recommended in the previous thread, but that had no effect on the above issue. I would prefer being able to use the official xwiki distribution instead of my own fixed build. Is there any chance that a fix to the above issue (given my evaluation is indeed correct) will make it into some upcoming release/milestone? Unfortunately, I do not understand the intention of the email obfuscation code above, otherwise I maybe would have been able to supply a patch myself. Kind regards and thanks in advance, Alex

13 years, 3 months

3
2
0 0

[xwiki-devs] [Proposal] Move location of HSQLDB database files to the XWiki Permanent Directory

by Vincent Massol

13 years, 3 months

8
7
0 0

[xwiki-devs] [proposal] New way to make sure temp files are deleted.

by Caleb James DeLisle

Hi, In order to fix XWIKI-7748 and XWIKI-7749, we need a plan for deleting temporary file. XWikiAttachmentContent uses File.deleteOnExit(), but in Sun's implementation, deleteOnExit() only deletes on a *clean* exit, in a crash it can't delete the files but it doesn't tag them so they can be deleted in the next run either. Since temp files are usually pseudo-randomly named, they are impossible to find and delete later. I propose that we create a subdirectory, `java.io.tmpdir`/xwiki/ which will be removed on application exit. If the jvm crashes, the files will be removed next time around. Then alter ApplicationContext.getTemporaryDirectory() to yield this directory. WDYT? Caleb

13 years, 3 months

4
11
0 0

[xwiki-devs] [GSOC] First coding period started

by Eduard Moraru

Hello students, As you all probably know, the community bonding period is over and the first coding period has just started. I hope you enjoyed the bonding period and had the chance to get up to speed with XWiki's way of doing things and the code. According to the timeline [1], you have 7 weeks of work available until the mid-term evaluation. Please make sure you have the conditions for success [2] in mind throughout all of the 12 total weeks of GSoC coding. As a reminder: For the ones that filled in the 'Progress' field on your project's page, please remember to update it periodically, as instructed [3] and, for the ones that did not fill it, please do so ASAP. Happy coding! - Eduard ---------- [1] http://www.google-melange.com/gsoc/events/google/gsoc2012 [2] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HConditionsf… [3] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr…

13 years, 3 months

1
0
0 0

[xwiki-devs] [Discussion] Should we re-think the way we determine what is user-public code ?

by Jerome Velociter

Hi devs, Following a thread on github, here's a mail to start a discussion about the way we determine what is API or not. Our current rule is : 1) "Non user-public code must be located in an internal package just after the module name." c.f. [1] (implied that what is not in internal is public) 2) What is public has to go through the deprecation strategy described at [2]). I think the rule is good but there is a problem in its enforcement right now, mainly because : * There is some legacy code where 1) does not make much sense because it "arrived too late at the party" (for example in oldcore) * There is some "new code" where some classes/interfaces hasn't been made internal when they likely should have been. For example I've been playing around with the WYSIWYG recently and in the client module, there are *only* user-public classes [3]. I'm sure we can find a lot of examples of such practice and I'm OK to work and list some if needed. The problem I see coming is that the cost of refactoring will increase for a lot of modules/classes/etc., while at the same time those modules should not have been API to begin with, and are probably not even being used as such by anybody. The risk is our progress being bogged down for no good reason. So what can we do to enforce a solid backward-compatibility policy for API code, while keeping flexibility in XWiki internals ? We could : A) Not do anything :) Maybe it's just me that sees this as a potential problem. B) Do the work to move everything that ought to be in an internal package to an internal package. But I don't believe we're reading to make that effort, so that's not going to happen IMHO C) Do the work to move what ought to be in an internal package "on the fly", when refactoring code. That would be on a case-by-case case, probably requiring a mail to announce it ; or more coercive, a VOTE. C) We change the rule. We could decide that instead of having everything be an API and enforce the "internal" status in a special package, we take it the other way around and Day everything is internal, and APIs needs to be in a special package (or be annotated with a special annotation). This could also be the opportunity to introduce another rule that says that such APIs should be referenced in their own module documentation on extensions.xwiki.org. What do you think ? Jerome. [1] http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HPackagenames [2] http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwar…) [3] https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi… -- Jérôme Velociter Winesquare http://www.winesquare.net/

13 years, 3 months

3
5
0 0

Re: [xwiki-devs] [xwiki-notifications] [Issue] (XWIKI-7841) XWiki.DatePickerExtension does not work anymore

by Marius Dumitru Florea

Hi Guillaume, On Mon, May 21, 2012 at 6:47 PM, Guillaume Delhumeau (Deleted) (JIRA) <jira(a)xwiki.org> wrote: > > [ http://jira.xwiki.org/browse/XWIKI-7841?page=com.atlassian.jira.plugin.syst… ] > > Guillaume Delhumeau deleted XWIKI-7841: We have a rule of not deleting any JIRA issue. You should have closed it as Cannot Reproduce, Won't Fix or Duplicate instead. Thanks, Marius > --------------------------------------- > > >> XWiki.DatePickerExtension does not work anymore >> ----------------------------------------------- >> >> Key: XWIKI-7841 >> URL: http://jira.xwiki.org/browse/XWIKI-7841 >> Project: XWiki Platform >> Issue Type: Bug >> Reporter: Guillaume Delhumeau >> Labels: regression >> >> Create a new page and paste this code: >> { {velocity} } >> $xwiki.jsfx.use("js/scriptaculous/scriptaculous.js") >> $xwiki.jsx.use("XWiki.DatePickerExtension") >> $xwiki.ssx.use("XWiki.DatePickerExtension") >> { {html clean="false"} } >> <input type="text" name="mydate" id="mydate_id" /> >> <script type="text/javascript"> >> var dpicker = new DatePicker({ >> relative : 'mydate_id', >> language: "$context.language" >> }); >> </script> >> { {/html} } >> { {/velocity} } >> Note that if you click on the input, there is no DatePicker. >> Checked with Firefox 12 and Chromium 18 >> Documentation: http://extensions.xwiki.org/xwiki/bin/view/Extension/Date+Picker+Application > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA administrators: http://jira.xwiki.org/secure/ContactAdministrators!default.jspa > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > _______________________________________________ > notifications mailing list > notifications(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/notifications

13 years, 3 months

2
1
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends! > This kind of progressive disclosure mechanism that you've used for the > Desktop version is good for the mobile versions, when the space is > limited. > But on desktops I think is gonna be very disruptive for the user to > hide/show such large portions of UI, especially on hover events (which can > be triggered by accident). On desktop you have lots of space to use and > the > navigation/tools elements should be visible and accessible. So your > desktop > version would work better as a mobile version, but on landscape. Yea, I was debating that as well. Maybe a delayed response would serve better, or would the community rather have everything visible all the time? On the 'content is the king' note, I just wanted to state that XWiki is an > application wiki. So you need to have in mind that 'content' means not > just > text, but application content: forms, links, text, attachments, etc. The > 'content' thing is the hard part in representing it in a responsive > manner. Thank you for the link, it will definitely help when fleshing out the content. For a truly responsive skin, might be interesting to consider some > design alternatives to the traditional -- such as "windows metro" : > http://en.wikipedia.org/wiki/Metro_(design_language) Interestingly, that was the original inspiration for the project. That's why you have all those hidden mouse over events aha. It also takes some aspect of the charm bar as well (from windows 8)--where all the page navigation buttons are on the right. Also the huge fonts aha. Alternatley, the technique could also be used to break up a > traditional wiki document of linear sections, into a "metro style > panel" of horizontal pages. So in order to read within the section, > you'd swipe downward till you hit bottom of the section. But there'd > be a hint of the section header following and preceding to the right > and left. To go to the new section of a document, you'd therefore > sweep rightward; to go to previous you'd sweep left. I thought this was a great solution for mobile where gestures can be made. However, I think in a traditional desktop/mouse combo this would become an issue since if we account for the lowest common denominator (no do everything mouse), only one method of navigation is available--the scroll wheel. This means that only up and down or left to right can be chosen. I do agree that it is a very unique problem solution that they came up with though. If you have any idea on how to go about the limitation of the scroll wheel, i'd be interested! The following document talks about going from "website to metro-styled > app" but the same concept could be used to use a skin to transform > existing Wiki/Website layout to a mobile-friendly metro-styled design: > http://msdn.microsoft.com/en-us/library/windows/apps/hh868264.aspx Thank you for all the links, they are definitely very insightful. On a side note, I do like the explorations microsoft is doing (using windows phone myself atm). For mobiles, I think we need to test at least on WebKit and opera mini > on the devices we have (and IE if we can get hold on a windows phone). > For desktops, the usual bag. Yes, i think opera mini (with its limitation) is a good starting point. And webkit because of its pervasiveness. I do have a windows phone to test--this is the one that i'm worried about the most since they do some weird proprietary stuff. For example, fonts are changed by the browser itself to make it readable (i think) and some scripts do not work (even those that work on desktop ie). - The top menu/navigation is wrong IMO (c.f. Desktop4) Why not forget > about it and integrate its feature with the tools on the right ? (just > a suggestion) Originally I wanted to separate the two because the top navigation is a "global" navigation and serves as a bread crumb, where as the right is more page specific navigation. Do you think this is irrelevant? I will take this into account, and think about how to best integrate the two if any. - IMO you don't have to have "everything" on mobile. There are actions > that does not make much sense doing on a mobile, like print preview, > etc. "Responsive" or "Adaptive" should also be interpreted in terms of > feature I think. What do you think ? > BTW the GSoC title says "Responsive skin" ; but in terms of > implementation I have nothing against what LukeW calls "RESS" > (http://www.lukew.com/ff/entry.asp?1392) which basically says it's OK > to have some part of templates be device specific. I briefly touched upon this, iirc, in the proposal (not the RESS implementation specifically). You are right, some actions like print are unnecessary for mobile. In this specific instance, I should have used the more open term "export" for that oops. But in any regards, i myself am not very sure of how much should be specifically hidden and its value. Since unless we use RESS, the browser already have downloaded the files, it serves no advantage for data reasons or other to hide something downloaded. It might clean things up, but it doesn't add much beyond that. I was attempting to try and give the "full experience" as much as possible (unless it does hinder the experience). I know in most circumstance printing would not be available, but who knows someone out there may be able to (eg. google cloud print) and I don't want them to feel like this is a gimped down version of XWIKI. But I definitely do see your point, what does the community think about this? - What's the purpose of the combo boxes on your mobile design ? If > it's navigation, it's wrong, it won't scale with a lot of entries. I'm not exactly sure what you mean by combo boxes? If it's the drop down, it is to natively use the drop down chooser available on mobile devices to allow for more finger friendly interaction. implementation [1], examples [2] [3]. - You're missing the search box which I think is very central. I'd go > as far as saying the search box should be the one stop shop for > navigation when you're on a mobile. oops, i forgot about this. I am now making a check list of things needed to make sure this doesn't happen again. Finally, a revised timeline [4]. What does the community think? Thanks all! Such a learning experience, thanks again for having me. Jonathan Solichin [1] http://css-tricks.com/convert-menu-to-dropdown/ [2] http://open.blogs.nytimes.com/tag/ipad/ [3] http://qph.cf.quoracdn.net/main-qimg-047773f000eeb9037febd55aff32d10c [4] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin

13 years, 3 months

1
0
0 0

Re: [xwiki-devs] [GSoC] Responsive Skin

by Jonathan Solichin

Hello friends New quick mock up at the very end. > The main problem with this proposal is that you don't consider and maybe > you are not aware of XWiki's states and that the content in a wiki is > mostly dynamic: The main problem with this proposal is that you don't consider and maybe > you are not aware of XWiki's states and that the content in a wiki is > mostly dynamic: > - logged-in vs. logged-out content: The menus have many entries and the > way > you represented them does not scale. Check out the menus structure > > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal… > was the initial proposal, but some menu entries have changed since > then, but the mockups are ok to give you the impression of the entries). This is true, I knew the mock up had a lot of static element that would need some more thinking to make it dynamic. I just wanted to get a feel for this kind of skin since I still wasn't sure how much creativity I had--thought I have that answered now ahaha. - empty vs. populated entries: This concerns 'Tags' and 'Comments' section. > You're put 'Tags' and the 'Welcome' message on the same level because they > both have 3 rows of content, but this is not the case when 'Tags' are used > and populated (you will not have this consistency any more). When you are > logged-in, the 'Comments' section has another structure and would be > interesting to see how you want to display a comment too. Also you've > removed the 'Activity Stream' which is an important part. > Have a look at > http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHomewhich > shows a wiki instance used: there are lots of spaces, lots of > activity entries, some tags, some comments. Thank you for this link! I had a copy of XWIKI installed, but there was nothing in it, so it did not help much. (eg. activity streams and so forth) There is a Forum view of the mails > http://dev.xwiki.org/xwiki/bin/view/Community/Forum but I don't find it > very useful. Alternatives to see the mailinglists: > http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HForums Thank you, this has been very helpful in seeing the thread, And yes, i need to get used to it aha. - I think you underestimate time for both design and implementation. > Remember that in addition to the work it represents by itself, which > in my opinion is already underestimated, you will have to present it > and discuss it with the community, refine accordingly, etc. This takes > more time that you imagine. > An improvement would be instead of having > just the numbers to put 'Week x.x:' in your timeline. > > Also please add the calendar week number as Caty suggests so that we > have a better view of when things happen. Yes, this is what I needed, I really was not sure at all how the timeline was working out. Thank you. I haven't yet updated the timeline, because I think I need to think on it a bit more, since it seems I have done a lot of underestimation. > - I don't know what you exactly mean under "typography check", but a > priori one week sounds way too much for this > - what do you mean by "bumper" ? Typography check is to check the text, actually the whole skin, on multiple devices since some superphones have screens that are close to desktop in resolution (eg. gNEX). So It was more to check whether the skin is translating well given this circumstance. I thought this might take slightly longer because of the need to hunt down these phones to check. Bumper is to make sure everything can still follow the timeline--sort of--in case I underestimated (which I did a lot aha) > - I think what you have as refinements in week 10 "color variations, > inverse for night time" etc. you can just forget about that. That's > not really important, and it's not likely we can go this far during > the time of the GSoC. Ok. Thank you for the info. How much creativity ? A lot :) As much as you can afford ! > While there are some good ideas in your skin proposal, to be honest it > still does feel too much as "dressing up [the] product with a > last-minute garment" as Dieter Rams put it in this great text "Good > Design As A Key Business Advantage" [1]. > What we want you to do is to take ownership of the product. Caty is > definitely right when she says you don't consider enough how XWiki > works. You should download XWiki on your computer, install it, plays > with it, get to know its feature, its *purpose*, and then start afresh > on a white (I mean transparent) sheet. > Right now your design has "colibri" written all over it. We can tell > from the links at the top and from the block in the footer. We can > tell from the way you've placed the "annotations" feature, etc. you > get the point. I hope you can make it as if you would never had seen > colibri. Ok sorry, still testing out the waters. I thought the last proposal was crazy enough--oops. And getting rid of Colibri in my head is harder than I thought! As afforementioned I do have XWIKI installed, but it is pretty barren and I still haven't gotten used to it. Caty's (should I be calling her that) link with a populated XWIKI will help me with this. Also still need to finish building from sources as well (doing that on ubuntu to pull from git, but i'm new to that as well). In any regards, here is another iteration, quick un-complete mock up (Content space is white for now, just demoing menu/layout idea) since I just fleshed some of the ideas in my head and haven't had the time to completely flesh it out. I was wondering what you guys were thinking of it though, before I invest more time. http://jssolichin.com/public/3/desktop.jpg http://jssolichin.com/public/3/desktop2.jpg http://jssolichin.com/public/3/desktop3.jpg http://jssolichin.com/public/3/desktop4.jpg http://jssolichin.com/public/3/mobille.jpg http://jssolichin.com/public/3/mobille2.jpg http://jssolichin.com/public/3/mobille2.jpg<http://jssolichin.com/public/3/mobille3.jpg> This design divides navigation into 3, corresponding with borders. As the user hovers nears the edge, it would reveal the whole link/more info. The overflowed text serves to give them the idea there is more. By putting the navigation in the borders, it becomes more static in a way--that is on each new page, the "navigation links" placement will always be the same area. Also, by detaching the links from the content, its size has more flexibility allowing it to be bigger without interrupting the flow of text-- allowing for bigger size clickable area. In the mobile version, instead of hovering, the user would click. So it's a bit similar to the Mobile Patterns[1] link Caty sent a while back since it is like a sidebar to be revealed kind of thing. Furthermore, this skin will really put the content front and center. And again, this mockup is incomplete, i just wanted to give you a heads up on this current exploration and was wondering your thoughts. Again sorry, I'm still trying to get used to everything. Thank you for all the inputs. I hope to be able to ramp up communication once school is out--nearing critical point atm so a little bit busy. Thanks all!, Jonathan Solichin [1] http://mobile-patterns.com/

13 years, 3 months

5
5
0 0

Re: [xwiki-devs] [GSOC] Welcoming our GSoC students

by Jonathan Solichin

Hello friends, I wanted to revisit this thread from a while back. One of the things we were supposed to do (as GSOC students) was to fix an issue listed on JIRA. Coming from a run-time development background, I was very much struggling with this. I've been trying to get at this but have been for the most part unsuccessful. I finally tried, though as a last resort (which was probably a bad idea and I should have asked sooner instead of continually struggling with it myself with no communication, sorry--definitely learning from this), the IRC. Though @cjd was super helpful, and helping me a lot, I was still unable to build xwiki-platform and xwiki-rendering (though I was able to build xwiki-commons). Since I could not do this, I tried to find a really simple JIRA issue that could hopefully be changed without building. Out of all the available issues, I though this seems to be the best suited [1] since it was mainly just deleting text and adding a class (probably the most relevant as well since my project is mostly front-end) so I did it and sent a pull request. Though as @cjd advised me, even this may have not been the best idea since it is on the front end and would probably need a lot more discussing--since I could have made an error in my deletions. In short, I apologize that I am not able to contribute much more to the JIRA issues, it was definitely a learning experience. I take from this the importance of communication and to not be afraid to ask the community since they are super helpful. I will continue to work with this as I can in the coming weeks. As a side note, my school ends on June 8 and finals season is coming so while I will try my best to not let that get in the way of xwiki, i am afraid at the chance that it will. So I guess, in the spirit of communicating, I thought I would let the community know. I apologize for the inconvenience and my shortcomings and I hope that the community can continue to help me! Best, Jonathan Solichin [1] http://jira.xwiki.org/browse/XWIKI-7678?page=com.xiplink.jira.git.jira-git-…

13 years, 3 months

1
0
0 0

[xwiki-devs] Diff module

by Thomas Mortagne

Hi devs, Since there is not official standard for diff/merge API I started to write a simple one. Yo can find it on https://github.com/xwiki/xwiki-commons/tree/feature-diff/xwiki-commons-core…. The first use case for it is to provide a diff/merge API for the Extension Manager XAR merging conflict resolution UI. It is mostly inspired from JRCS/java-diff-utils APIs and implemented using java-diff-utils (http://code.google.com/p/java-diff-utils/) for the diff and JDiff (http://www.qarks.com/web/en/products_jdiff.html) for the multiline String merge. Theses are the most active independent libraries I could find so far and it's not really what I would call active library usually... Would be nice to get some comments/suggestions on the API. For the implementation side if you know some good diff/merge tool I would be glad to get some other suggestions. I took a quick look at various EDIs which obviously have this kind of tools but what I could find is not really designed to be used easily outside of the EDI for which they have been designed. Either its very tied to the EDI itself or it's generic enough but trigger a whole bunch of dependencies while we would use like 1% of the total. Here are the various features I'm looking for in an ideal library: * good 3 ways merge ("good" is not a detail, applying a patch on the third version does not always give very good results) * diff/patch API * support of single line in 3 ways merge and diff Thanks, -- Thomas Mortagne

13 years, 3 months

3
6
0 0

[xwiki-devs] [VOTE] Improving documentation and automating our Release Notes when doing releases

by Vincent Massol

Hi devs, Sergiu has started a script to fully automate a release (more to come - Sergiu will document what it does soon). The only part not automated are the Release Notes. IMO we can "automate" it by a process which I propose to be: * An issue can only be closed if it's documented on xwiki.org and on the release notes page for the upcoming release. * We collectively enforce this by reopening issues if someone doesn't do the first point, asking him/her to do it This will have some nice effects: * xwiki.org will be more up to date than it is now * it's up to the developer to document what they do (I don't think it's good to push this to someone else) which is good since they have the most knowledge (side note: it doesn't mean we don't need a technical writer to improve on the documentation done by developers but it would be about style and not about content) * the release notes will be ready for the release, as we progress and the burden of writing the release notes will not fall on the shoulders of the Release Manager (there's no reason it should) * the whole release process will almost be a joy to do * with a fully automated release process it means we'll be able to perform a lot more bugfix releases which is good for our users Here's my +1 Thanks -Vincent

13 years, 3 months

6
19
0 0

[xwiki-devs] New Component Script Service

by Vincent Massol

FYI, I've added a new Script Service to get access to the CM and to get component instances. See http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterpris… I've taken the liberty to deprecate the old Utils.getComponent*() methods. Thanks -Vincent

13 years, 3 months

1
0
0 0

[xwiki-devs] Questions concerning the development of XWiki, Round 2

by Martin Schönberger

Hello again! First of all, let me express my thanks to all of you who joined in on this thread (started at http://lists.xwiki.org/pipermail/devs/2012-April/050416.html) to support me in my quest to better understand the way open source development works in XWiki. :) As I've mentioned in my last email, I have some more questions I would like to ask. Last time I focused on general aspects of the process, today's topics revolve around the project's architecture, roles and governance, and knowledge management. So my first question this time concerns the architectural design, and how it has evolved over time. Did the basic structure change / grow significantly since the early days of XWiki? Vincent mentioned the change from a monolithic code to small modules. Were these and other changes made in some major refactorings, or rather through steady refinement? To what degree is it an issue to keep backwards compatibility between releases? Also I am interested more closely how the functions and responsibilities are divided in the team. Caty wrote about 'very clear departments' in her last answer, and the teampage on XWiki.com lists a multitude of different and specific roles. Both of your descriptions of the testing process, however, suggests a less strict separation of tasks. So what role do the roles play? How specialized or cross-functional are the teams and people working therein? Is there a difference between XWiki.org and XWiki SAS? In a related matter, many of the role descriptions of the core developers contain manager and leadership titles. What, in practice, are the main tasks of the people managing the development? Many meritocracies have safety nets, some rules to follow or people to go to when no consensus can be reached on important topics. Did this ever occur in XWiki? What would be done in such a situation? Have either the formal roles or the informal merit people earned in a special field some kind of influence on the weight of their voice in a dispute? And last but not least some questions about the access and distribution of knowledge: XWiki features an extensive written documentation of itself and the process used in its development. What is the role then of additional, personal communication, of the proverbial informal talk at the water cooler? Is the necessary time and ceremony of written documentation always justified by making the knowledge permanently available to everyone, or can you think of exceptions? Again, every answer or comment is greatly appreciated, Martin

13 years, 3 months

3
4
0 0

[xwiki-devs] [Proposal] Filtering of events fired by hidden documents in the activity stream

by Jean-Vincent Drean

Hi, Following the "hiding technical content" it seems logical to hide events fired by hidden documents in the activity stream. Since the activity stream uses its own store for performance I don't see any other solution than to duplicate the "hidden" information in it. I'd like to commit the following implementation: - no change to the ActivityStream / ActivityEvent APIs - additions of ActivityEventImpl#isHidden() and ActivityEventImpl#setHidden(boolean) - modification of ActivityStreamImpl#addDocumentActivityEvent() so that it sets the event as hidden when it's been fired by a hidden doc - modification of ActivityStreamImpl#searchEvents() so that it tweaks the hibernate query when the user doesn't want hidden docs to be displayed (same principle as in the query manager) - addition of a ase_hidden column in the activity stream DB table This way events can be filtered without any modification to the existing APIs. WDYT ? Note: naming this new property "hidden" and not something like "hiddenpage" allow us to extend the concept in the future. We could put the setHidden / isHidden methods at the API level and any extension would be able to mark an event as hidden. But it's not part of the current proposal. Thanks, JV.

13 years, 3 months

4
5
0 0

[xwiki-devs] [Rendering] CTS Day #1

by Vincent Massol

Hi devs, As you may know I've created a Compatibility Test Suite for the Rendering module. The idea is to have a suite of tests executed for all syntaxes. The reason this is important is because we need to tell our users what is the level of support for all the syntaxes we support. And it's only useful if the CTS suite is complete. Now we had some integration tests before, located in xwiki-rendering-integration-tests and the goal is to move these tests in 2 places: * the CTS (in xwiki-rendering-test) * tests specific to a given syntax and not part of the CTS because they're really syntax-specific (for example the current bold3, 4, 5, 6, 7 and 9 for bold tests - bold1, 2 and 8 have been moved to CTS already) I've started doing the work and… it's a lot of work… This is what I have now: http://rendering.xwiki.org/xwiki/bin/view/Main/SyntaxReport I need help and thus I'd like to propose a CTS Day for everyone interested in helping out. I'm proposing Monday the 4th of June (since before that we have the 4.1M2 release and we should have the max time for it). So who can join in for this necessary work? Thanks -Vincent

13 years, 3 months

5
5
0 0

[xwiki-devs] To involve another wiki page in one wiki page

by jinlong liu

Hello ,can I involve another wiki page in a wiki page. I mean something like #template("global.vm") ,not a link to another page. Thank you.

13 years, 3 months

2
1
0 0

[xwiki-devs] [Release] XWiki Enterprise and XWiki Manager 4.1 Milestone 1 Released

by Caleb James DeLisle

The XWiki development team is proud to announce the release of XWiki Enterprise 4.1 Milestone 1, the first milestone along the 4.1 road map. This release brings new 3D graphs made with pure XWiki syntax, safer Groovy scripting, and better hiding of internal application related documents. As always, it includes plenty of important bug fixes and improvements. See: http://www.xwiki.org/xwiki/bin/ReleaseNotes/ReleaseNotesXWikiEnterprise41M1 for more details. Or grab the fresh downloads at: http://enterprise.xwiki.org/xwiki/bin/view/Main/Download Thanks to everyone in the community for making this release great! Caleb

13 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs